Endpoint VPN DNS Headbender

[Vladimir]

OK. I am officially crying "uncle" and am asking for your advise.

In the process of setting up a demo lab for the client to demonstrate the various remote access options, I've run into this situation:

Endpoint connects to the gateway in a hub mode and TCP traffic is working fine, (i.e. no problem establishing RDP sessions).

The DNS however, does not.

Latest findings indicate that disabling SecureXL makes this problem go away.

According to the client, dns queries are being send to a correct remote server:

  

This is the DNS server configured in the Office Mode Optional Parameters:

Packet capture on the client seem to suggest that all is well:

But the firewall, after encrypting session claims that the queries are being addressed to another IP (client's WiFi DNS):

Session:

Time: 2018-03-28T16:05:42Z
Interface Direction: inbound
Interface Name: eth1
Connection Direction: Incoming
Id: c0a8071f-2116-0000-5abb-bd5600000000
Sequencenum: 1
Hll Key: 11932664019562776808
Duration: 60
Last Update Time: 2018-03-28T16:06:39Z
Update Count: 2
Connections: 21
Aggregated Log Count: 34
Creation Time: 2018-03-28T16:05:42Z
Source: 172.16.20.2
Destination: 10.101.25.10
Destination Port: 53
IP Protocol: 17
User: ADUser1 (aduser1)
Source User Name: ADUser1 (aduser1)
Src User Dn: CN=ADUser1,CN=Users,DC=higherintelligence,DC=com
Destination Machine Name:dc16@higherintelligence.com
Service ID: domain-udp
Source Zone: External
Destination Zone: Internal
Action: Decrypt
Type: Session
Policy Name: MobileAccess_for_GW8010
Policy Management: SMS8010
Db Tag: {C961B499-D18A-6E48-B9D9-09023460FFBE}
Policy Date: 2018-03-28T13:44:48Z
Blade: Firewall
Origin: GW8010
Service: UDP/53
Product Family: Access
Logid: 288
Marker: @A@@B@1522209601@C@93556
Log Server Origin: 192.168.7.30
Orig Log Server Ip: 192.168.7.30
Lastupdatetime: 1522253202000
Lastupdateseqnum: 1
Severity: Informational
Rounded Sent Bytes: 1600
Confidence Level: N/A
Rounded Bytes: 9968
Stored: true
Rounded Received Bytes: 3568
Packets: 46
Total Bytes: 9981
Client Inbound Packets: 23
Client Outbound Packets: 23
Server Inbound Packets: 23
Server Outbound Packets: 23
Client Inbound Bytes: 3008
Client Outbound Bytes: 6973
Server Inbound Bytes: 3569
Server Outbound Bytes: 1600
Received Bytes: 3569
Sent Bytes: 1600
Access Rule Name: MAB Access to DC
Access Rule Number: 9.3
Rule UID: 69d6915f-7f98-4f28-9bf8-e9338d879611
Layer Name: Inline_FW_MAB
Interface: eth1
Description: domain-udp Traffic Decrypted from ADUser1 (aduser1)(172.16.20.2) to 10.101.25.10
Layer Uuid Rule Uuid: 9457d7fd-104e-494a-bf23-522eae8d2530_b84bc8fb-5623-47d2-9b6a-2fd8d54988a4, 05184d6c-b55e-4fc2-bb2c-8a8b5dd8d213_69d6915f-7f98-4f28-9bf8-e9338d879611
Bytes (sent\received): 9.7 KB (1.6 KB \ 3.5 KB)

Drops:

Id: c0a8071e-2091-a809-5abb-bd6233fb0003
Marker: @A@@B@1522209601@C@93320
Log Server Origin: 192.168.7.30
Time: 2018-03-28T16:05:54Z
Interface Direction: inbound
Interface Name: eth1
Id Generated By Indexer:false
First: true
Sequencenum: 4
Source Zone: External
Destination Zone: Internal
Service ID: domain-udp
Source: 172.16.20.2
Source Port: 55011
Destination: 192.168.7.1
Destination Port: 53
IP Protocol: 17
User: ADUser1 (aduser1)
Source User Name: ADUser1 (aduser1)
Src User Dn: CN=ADUser1,CN=Users,DC=higherintelligence,DC=com
Action: Drop
Type: Connection
Policy Name: MobileAccess_for_GW8010
Policy Management: SMS8010
Db Tag: {C961B499-D18A-6E48-B9D9-09023460FFBE}
Policy Date: 2018-03-28T13:44:48Z
Blade: Firewall
Origin: GW8010
Service: UDP/53
Product Family: Access
Logid: 0
Access Rule Name: MAB Layer Cleanup rule
Access Rule Number: 9.6
Rule UID: 7ec99f73-e125-4ac3-8882-f342d8c518c0
Layer Name: Inline_FW_MAB
Interface: eth1
Description: domain-udp Traffic Dropped from ADUser1 (aduser1)(172.16.20.2) to 192.168.7.1

I am aware of the Windows 10 DNS leakage issues and have addressed those, but this does not look like it, as the queries being actually forwarded to the gateway and not blasted out of Wi-Fi.

I'll collect and attach the trac.log from the Endpoint VPN client later if you want to take a look at it.

Thank you,

Vladimir

[Kaspars_Zibarts]

Looking at timestamps, there's 12 secs between DNS request to the "right" DNS and the "wrong" one I would guess client didn't receive response to the first request so it started trying any DNS it can find on any other interface, resulting in using WiFi DNS. Probably windows behaviour. Check if first request was forwarded to DNS and response arrived to DNS OK. Hope you understood where I'm trying to get to

[Kaspars_Zibarts]

Fairly short thread with some answers

Windows 10 DNS resolution via VPN connection not working - Super User 

[Vladimir]

I've seen this, but it is not a viable solution, as each new Wi-Fi connection resets metric on adapter.

By design, Windows 10 will blast DNS requests to any and all connections that have DNS registered with them simultaneously and use the results that have arrived fastest.

So if you have a non split-brain DNS for your domain and are trying to access internal resources (that are also have public records) via VPN, you are kind-of out of luck.

In my case, it is attempting to query Wi-Fi's DNS, but those requests are encapsulated and shoved through the VPN.

May have something to do with the topology of the lab.

Let me run the wireshark on DC and see what it is seeing in terms of the query origin.

[AlekseiShelepov]

I don't really have much experience with remote clients, but these SKs offer some possibilities to try or at least check:

DNS Query on VPN client with Office Mode IP address takes a very long time to succeed 

Endpoint Security VPN client using local DNS server before using its assigned Office Mode DNS

DNS does not work through VPN tunnels 

But I suspect that you already read all SKs found by search "DNS VPN".

[Vladimir]

Thank you for suggestions.

I have read those and much more on the subject than I care to admit:)

First, the sk103678 is in compliance.

Second, the sk103455 is in compliance.

Third, the sk62483 is in compliance.

But the plot thickens: Disabling SecureXL makes the DNS traversal work as expected.

Does this new revelation ring any bells?

[PhoneBoy]

It's probably worth a TAC case if disabling SecureXL solves the issues.

[Vladimir]

I am having problems opening POC cases with TAC, as the account that I am using with NFR licenses does not have active CP support.

At some point, I may have to ask you to associate my Checkmates account with my own email, since I myself maintain active support contract.

I am just concerned about possible confusion it may cause, since the my current Checkmates account and email is the one that it assigned to a bunch of clients as a technical support contact. 

[PhoneBoy]

Unfortunately, the identifier for CheckMates accounts is based on your UserCenter account and I don't have a way to affect that.

I know who you are, though--no confusion on my end