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?
Solved! Go to Solution.
They must be missing something. Keep pushing them with the fact you couldn't see those packets on the virtual FGT side. Not your problem.
Toshi
From my understanding of split DNS ( havent used it so far, from the link below ), is that the split DNS servers are only used for some domains that you defined in the portal so a firewall rule should be created to permit access to them, the rest should use the client dns servers that it had before connecting ( so unless you are routing everything [ all ] thru the tunnel, a rule for them should not be required ) .
https://community.fortinet.com/t5/FortiGate/Technical-Tip-Split-DNS-support-for-SSL-VPN/ta-p/194766
Usually this means there is a missing route back somewhere, or the DNS server's firewall may block DNS query from SSL-VPN range.
First you may sniff the traffic at DNS server level to see if the DNS query reaches it and if the server sends a response.
I do believe there is a missing route. However, this question is a little more basic than that. Simply put if I have Split Tunnel and Split DNS setup already. Do I need a firewall rule allowing access to the DNS servers provided to the client via Split DNS. Or does the setup of Split DNS already allow that access unless there is a specific Deny rule. (Which there is not.)
You need a firewall policy. But you said that doing NAT allows it, so I think you already have this firewall rule, since NAT doesn't exempt you from adding the rule.
I agree with @AEK. If NAT is not there at the FGT, you should be able to ping your client machine from the DNS server if you drop your local AV software like Windows Defender. Be aware you wouldn't be able to see PING packets at your machines Wireshark because it's encrypted by SSL. They would show as application data. DNS query/response as well.
Toshi
Hi @systemgeek,
I believe your DNS servers don't respond to queries from a different network. Can you try turning off Windows firewall of the server and test without NAT?
Regards,
A couple of things. One, I only have 4 rules in my FW. And none of them are related to DNS. Two, I installed Wireshark on my DNS server (the one handed out by Split DNS). I can see the traffic coming in and going out to my vpn client. But it never makes it to the client.
I have a route already setup for my vpn clients on my transit gateway so I do suspect that I need a DNS Firewall Rule. I have been having issues trying to setup the rule correctly. Here is what I have so far:
Interface IN: ssl.root
Interface Out: Private interface
Source: (This is where I have issues). I know it should be the VPN Pool IPs but when I put them in it says "One user or Group required". So I have tried adding in the VPN users.
Destination: The DNS servers.
Service: DNS and ICMP
Action: Accept.
So what exactly should be in Source?????
Via the CLI was able to get around the problem with source. It was looking for Source Group in the GUI. I just omitted it from the cli.
As for turning off Windows Defender on my client and trying to ping its VPN ip from the DNS server. I tried that and its failing.
I also edited the Deny rule at the bottom and enabled logging on it. Then repeated the pings. Not getting any thing in the logs. Is this the correct way to see failed traffic?
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1737 | |
1107 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.