AnsweredAssumed Answered

Endpoint VPN DNS Headbender

Question asked by Vladimir Yakovlev on Mar 28, 2018
Latest reply on Mar 29, 2018 by Dameon Welch Abernathy

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

Outcomes