DNS for SSL VPN

[systemgeek]

I have split tunnel and split dns set up.  When I vpn in I can see that my dns servers are set to what is defined in the split tunnel configuration.  However, when I try to do a dns lookup the response shows me the dns server from the split tunnel but then gives me "Request timed out".  

If I change the Firewall rule to do NATing of the SSL VPN connection DNS lookups work fine.

Does this mean I need a firewall rule allowing ssl.root to access the dns servers?

[hbac]

@systemgeek,

You can run debug flow as below. Replace x.x.x.x with the destination IP and try to ping. 

di deb disable
di deb res
diagnose debug flow filter clear
di deb flow filter addr x.x.x.x
di deb flow filter proto 1
diagnose debug flow show function-name enable
di deb flow show iprope en
diagnose debug console timestamp enable
diagnose debug flow trace start 9999
diagnose debug enable

Regards, 

[systemgeek]

Before I do that.  I clicked on Log&Report->Forward Traffic.  In the search bar I removed everything then refreshed.  I now see the pings going from the vpn cliient to the DNS servers and they are marked as accepted.  I do not yet set the reverse though.  So probably need do the debug as you listed above.

[hbac]

Hi @systemgeek,

You need to add a user group in the source of the policy. Otherwise, its not gonna work. 

Regards, 

[Toshi_Esumi]

I forgot to tell this. When you test ping from the DNS server to the VPN client IP, you need to have a policy form the interface for the server to ssl.root. Otherwise, they would be dropped at the FGT. You should sniff at the FGT to see at least ping request is reaching the FGT.

Toshi

[systemgeek]

I have created a very simple firewall rule like so:

set name "Allow_DNS_to_VPN"
set uuid 08ab3986-0c80-51ef-b56e-3d43771381d0
set srcintf "ssl.root"
set dstintf "port2"
set action accept
set srcaddr "VPN_ALL"
set dstaddr "us1-dc01a.example.com" "us1-dc02.example.com"
set schedule "always"
set service "DNS" "ALL_ICMP"
set logtraffic all

Then I had the fortigate create the reverse policy.  Did not improve the pings.

Ran the debug as requested but put in 2 filter lines.  One for the vpn client and one for the dns server.

Pinging from the DNS server I get nothing showing up in the debug.  Pinging from the vpn client I see the traffic going from ssl.root to port2.  I do not see the return traffic but what I do see is this message:

2024-05-07 11:07:01 id=65308 trace_id=170 func=__iprope_check line=2415 msg="gnum-4e20 check result: ret-no-match, act-accept, flag-00000000, flag2-00000000"

[Toshi_Esumi]

srcintf and dstintf are reversed.

Toshi

[systemgeek]

I have one rule where like the above then I have another rule where the srcintf and dstintf are reversed.

[Toshi_Esumi]

You might need to put "set auto-asic-offload disable" in the policy to show up in the flow debugging. But if it still doesn't show up, the packets from the DNS server toward the client IP is not reaching the FGT.
Is the FGT's port2 IP the default GW at the DNS server?

Toshi

[systemgeek]

The fortigate is in one AWS account and the DNS server is in another account. So no.  They need to reach each other via AWS TransitGateway.  There is a rule on the Transit Gateway attachment point the direction to the VPN Client IP range.

[Toshi_Esumi]

I'm not familiar with AWS especially with two different accounts. But there needs to be a route from the GW, which must be acting as a router, to the VPN client IP subnet. Otherwise, none outside of the FGT domain can reach the client IPs.
So it's a question to AWS.

By the way, you should have mentioned about this is in the AWS environment at the beginning. Nobody who commented so far couldn't even imagine that.

Toshi