Member Avatar for Member #1123877

We have three Windows Domain Controllers (2012 R2 and 2008 R2 mix), all DNS servers. Split-zone DNS scenario.

DNS resolution is working for all internal subnets except over User VPN. All network connectivity appears to be uninhibited.

Users connected to Cisco AnyConnect IOS SSL VPN are unable to resolve internet-facing DNS queries. Queries to AD Integrated Zones return correct answers.

NSLOOKUP output from working host within network boundary:

> set type=a
> 4.2.2.6
Server:  dc1.domain.com
Address:  192.168.0.1

------------
SendRequest(), len 38
    HEADER:
        opcode = QUERY, id = 7, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        6.2.2.4.in-addr.arpa, type = PTR, class = IN

------------
------------
Got answer (98 bytes):
    HEADER:
        opcode = QUERY, id = 7, rcode = NOERROR
        header flags:  response, want recursion, recursion avail.
        questions = 1,  answers = 2,  authority records = 0,  additional = 0

    QUESTIONS:
        6.2.2.4.in-addr.arpa, type = PTR, class = IN
    ANSWERS:
    ->  6.2.2.4.in-addr.arpa
        type = PTR, class = IN, dlen = 24
        name = f.resolvers.level3.net
        ttl = 74506 (20 hours 41 mins 46 secs)
    ->  6.2.2.4.in-addr.arpa
        type = PTR, class = IN, dlen = 12
        name = resolver8.level3.net
        ttl = 74506 (20 hours 41 mins 46 secs)

------------
Name:    f.resolvers.level3.net
Address:  4.2.2.6

NSLOOKUP output from VPN-connected host:

> set type=a
> 4.2.2.6
Server:  [192.168.0.1]
Address:  192.168.0.1

------------
SendRequest(), len 38
    HEADER:
        opcode = QUERY, id = 7, rcode = NOERROR
        header flags:  query, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        6.2.2.4.in-addr.arpa, type = PTR, class = IN

------------
------------
Got answer (38 bytes):
    HEADER:
        opcode = QUERY, id = 7, rcode = NXDOMAIN
        header flags:  response, want recursion
        questions = 1,  answers = 0,  authority records = 0,  additional = 0

    QUESTIONS:
        6.2.2.4.in-addr.arpa, type = PTR, class = IN

------------
*** [192.168.0.1] can't find 4.2.2.6: Non-existent domain

Notes:

Windows Firewall on the DCs are disabled
All other protocols between VPN and server VLAN are functional
From SSL VPN, NSLOOKUP resolves any records within AD Integrated Zones without issue
All internal network segments have a Reverse Lookup Zone
Cisco AnyConnect Adapter has DNS Suffix the same as domain.com

Any assistance with this will be very much appreciated.

Dani AI

Generated

Brief summary and focused diagnostic steps.

Symptoms: VPN clients on 192.168.3.0/24 can resolve AD‑integrated names but get NXDOMAIN for Internet names. Server debug shows the DC receives queries from the VPN address space and (in at least one PTR case) appears to send a NOERROR reply while the VPN client sees NXDOMAIN. That mismatch strongly points to one of three categories: (A) resolver/suffix/search‑order behavior on the client producing non‑existent lookups (eg. appending the AD suffix to external names), (B) an intermediate device (ASA/AnyConnect DNS proxy, split‑DNS, or NAT/inspection) altering or intercepting DNS traffic, or (C) DNS server configuration (an accidental authoritative zone for a public name or a forwarding/recursion setting) returning NXDOMAIN for those queries.

Suggested, repeatable checks (copy/paste):

# On the VPN client
ipconfig /all
netsh interface ipv4 show dns
nslookup -debug 4.2.2.6 192.168.0.1
nslookup google.com 8.8.8.8

# On a DC (or use PowerShell if available)
dnscmd /enumzones
Get-DnsServerZone | ft Name, ZoneType  # Server 2012R2+ PowerShell

# Packet capture (client or ASA/DC)
tshark -i <iface> -f "udp port 53 and host 192.168.3.111" -w vpn-dns.pcap

Next diagnostic focuses: compare the DNS response seen on the DC to the response seen on the VPN client (packet captures on both sides). If the DC sent NOERROR but the client received NXDOMAIN, inspect ASA/AnyConnect group‑policy for DNS server/suffix, any DNS proxy/inspection rules, and split‑DNS settings. If the DC itself is returning NXDOMAIN, check for accidental public TLD or in‑addr zones, verify Server Properties -> Advanced (recursion not disabled), and review Forwarders/root hints. As suggested, a packet capture across the path will reveal exactly where the response changes.

Recommended Answers

All 3 Replies

even though it looks like the traffic is coming into 192.168.0.1, i am wondering if the users that are having trouble also belong to a 192.168.0.x subnet while connected via ssl-vpn. They are probably sending the packet to their router which is also running DNSPROxy, but are not getting the proper respnose from that DNS service. Have you validated that the packets are actually traversing the ssl-vpn system via packet capture or logs?

Member Avatar for Member #1123877

SSL VPN subnet pool is 192.168.3.0/24 and I am connected to the DC via RDP so routing is good.

Cisco AnyConnect Secure VPN Adapter has DNS servers set to DC1/DC2. Internet is functional because DNS fails over to DNS entries in LAN adapters.

Here is debug logging on the DNS server for two workstations.

domain.com.au is the AD domain

1/ 192.168.3.111 = VPN Client
2/ 192.168.0.100 = LAN Client

4/06/2015 6:58:19 PM 133C PACKET 0000004D1C41E0D0 UDP Rcv 192.168.3.111 0001 Q [0001 D NOERROR] PTR (2)1(1)0(2)168(2)192(7)in-addr(4)arpa(0)
4/06/2015 6:58:19 PM 133C PACKET 0000004D1C41E0D0 UDP Snd 192.168.3.111 0001 R Q [8085 A DR NOERROR] PTR (2)1(1)0(2)168(2)192(7)in-addr(4)arpa(0)
4/06/2015 6:58:19 PM 133C PACKET 0000004D1AE9C0A0 UDP Rcv 192.168.3.111 0002 Q [0001 D NOERROR] A (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:19 PM 133C PACKET 0000004D1AE9C0A0 UDP Snd 192.168.3.111 0002 R Q [8385 A DR NXDOMAIN] A (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:19 PM 133C PACKET 0000004D1BB201C0 UDP Rcv 192.168.3.111 0003 Q [0001 D NOERROR] AAAA (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:19 PM 133C PACKET 0000004D1BB201C0 UDP Snd 192.168.3.111 0003 R Q [8385 A DR NXDOMAIN] AAAA (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:20 PM 133C PACKET 0000004D1C41E0D0 UDP Rcv 192.168.3.111 0004 Q [0001 D NOERROR] A (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:20 PM 133C PACKET 0000004D1C41E0D0 UDP Snd 192.168.3.111 0004 R Q [8385 A DR NXDOMAIN] A (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:20 PM 133C PACKET 0000004D1AE9C0A0 UDP Rcv 192.168.3.111 0005 Q [0001 D NOERROR] AAAA (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:20 PM 133C PACKET 0000004D1AE9C0A0 UDP Snd 192.168.3.111 0005 R Q [8385 A DR NXDOMAIN] AAAA (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:20 PM 133C PACKET 0000004D1BB201C0 UDP Rcv 192.168.3.111 0006 Q [0001 D NOERROR] A (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:20 PM 133C PACKET 0000004D1BB201C0 UDP Snd 192.168.3.111 0006 R Q [8385 A DR NXDOMAIN] A (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:20 PM 133C PACKET 0000004D1C41E0D0 UDP Rcv 192.168.3.111 0007 Q [0001 D NOERROR] AAAA (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:20 PM 133C PACKET 0000004D1C41E0D0 UDP Snd 192.168.3.111 0007 R Q [8385 A DR NXDOMAIN] AAAA (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:20 PM 133C PACKET 0000004D1AE9C0A0 UDP Rcv 192.168.3.111 0008 Q [0001 D NOERROR] A (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:20 PM 133C PACKET 0000004D1AE9C0A0 UDP Snd 192.168.3.111 0008 R Q [8385 A DR NXDOMAIN] A (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:20 PM 133C PACKET 0000004D1BB201C0 UDP Rcv 192.168.3.111 0009 Q [0001 D NOERROR] AAAA (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:20 PM 133C PACKET 0000004D1BB201C0 UDP Snd 192.168.3.111 0009 R Q [8385 A DR NXDOMAIN] AAAA (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:23 PM 133C PACKET 0000004D1BB201C0 UDP Rcv 192.168.0.100 0001 Q [0001 D NOERROR] PTR (2)1(1)0(2)168(2)192(7)in-addr(4)arpa(0)
4/06/2015 6:58:23 PM 133C PACKET 0000004D1BB201C0 UDP Snd 192.168.0.100 0001 R Q [8085 A DR NOERROR] PTR (2)1(1)0(2)168(2)192(7)in-addr(4)arpa(0)
4/06/2015 6:58:23 PM 133C PACKET 0000004D1B438240 UDP Rcv 192.168.0.100 0002 Q [0001 D NOERROR] A (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:23 PM 133C PACKET 0000004D1B438240 UDP Snd 192.168.0.100 0002 R Q [8385 A DR NXDOMAIN] A (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:23 PM 133C PACKET 0000004D1C896190 UDP Rcv 192.168.0.100 0003 Q [0001 D NOERROR] AAAA (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:23 PM 133C PACKET 0000004D1C896190 UDP Snd 192.168.0.100 0003 R Q [8385 A DR NXDOMAIN] AAAA (6)google(3)com(8)domain(3)com(2)au(0)
4/06/2015 6:58:23 PM 133C PACKET 0000004D1BB201C0 UDP Rcv 192.168.0.100 0004 Q [0001 D NOERROR] A (6)google(3)com(3)com(2)au(0)
4/06/2015 6:58:23 PM 133C PACKET 0000004D1BB201C0 UDP Snd 192.168.0.100 0004 R Q [8081 DR NOERROR] A (6)google(3)com(3)com(2)au(0)
4/06/2015 6:58:23 PM 133C PACKET 0000004D1B438240 UDP Rcv 192.168.0.100 0005 Q [0001 D NOERROR] AAAA (6)google(3)com(3)com(2)au(0)
4/06/2015 6:58:23 PM 133C PACKET 0000004D1B438240 UDP Snd 192.168.0.100 0005 R Q [8081 DR NOERROR] AAAA (6)google(3)com(3)com(2)au(0)

do not know what to say

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.