Dear community Hello,
So i get reaaly hard stuck at joining the internal DNS servers with my fortigates.
In the setup that follows i have a simple 60F, with a flat subnet behind it, no vlans,no subnets, evertyhing coming through a vswitch in FGT and the out tou the wan link.
The goal is for my endpoints from the ssl vpn tunnel to be able to resolve internal devices DNS names.
These endpoints are not domain joined.Neither the internal are
Also ssl vpn simple set up with Domain users and local ones(not a web mode one).Split tunneling is disabled
Problem is i cant resolve DNS names neither from the clients side when connected through the ssl vpn tunnel,nor from the command line of the FGTs. Internal resolvment of FQDNs between PCs(witch are not domain joined,works fine)
As you can see in the print screens provided, i have for the FGT targeted, the Fortinet DNS server as option 1 and
the internal DNS VM Server's Local IP as option 2
And my local domain name.
Also the same for my ssl vpn settings
Local DNS Server's IP
and Google's.
Any ideas?
Thanks in advance
Solved! Go to Solution.
Nominating a forum post submits a request to create a new Knowledge Article based on the forum post topic. Please ensure your nomination includes a solution within the reply.
Hi,
Since split tunnel is disabled, you need to make sure that u have fw rules in place for DNS traffic towards the internal DNS and Ggl, with source usergrp and sslvpn range.
Also, if your endpoints are not domain joined, they might also not be able to resolve short hostnames, w/o the dns suffix, try the setting below
config vpn ssl settings
set dns-suffix example.com
end
Created on 05-02-2023 12:56 PM Edited on 05-02-2023 12:57 PM
Well, it depends on what you want to achieve and what you have to work with.
full-tunnel: If you want to protect your users and make sure that while connected to SSLVPN they dont access shady or unallowed resources, you can make different security profiles to filter them, if you also have the licenses for it; the wan link of the fw will also be an important factor since all internet traffic will be using it.
split-tunnel: If you dont have licenses for UTP/ATP and dont require to limit access to only certain destinations/resources on the INET while connected to it, then this is your best choice.
My best bet is that when you try to resolve internal dns names, it tries using the first DNS server in the list. An idea would be to switch their places as the internal one to be primary.
Hi,
Since split tunnel is disabled, you need to make sure that u have fw rules in place for DNS traffic towards the internal DNS and Ggl, with source usergrp and sslvpn range.
Also, if your endpoints are not domain joined, they might also not be able to resolve short hostnames, w/o the dns suffix, try the setting below
config vpn ssl settings
set dns-suffix example.com
end
@funkylicious Thanks m8!
The command worked as a charm.
Still the question arises, in a simple conf like this, should i have dns split tunnel enabled or not? In more complex set ups i can see why, but i try to find the more safe and managble solution is small enviroments like this
Created on 05-02-2023 12:56 PM Edited on 05-02-2023 12:57 PM
Well, it depends on what you want to achieve and what you have to work with.
full-tunnel: If you want to protect your users and make sure that while connected to SSLVPN they dont access shady or unallowed resources, you can make different security profiles to filter them, if you also have the licenses for it; the wan link of the fw will also be an important factor since all internet traffic will be using it.
split-tunnel: If you dont have licenses for UTP/ATP and dont require to limit access to only certain destinations/resources on the INET while connected to it, then this is your best choice.
Hi @chrispng ,
As I have understand you are unable to resolved internal hosted device with domain names with webmode and native application forticlient.
Since you have disabled split tunnel,
- make sure you have default route towards forticlient gateway in your client PC (while using forticlient). Verify by running command in PC (Windows) : route print
- Firewall policy to allow DNS traffic towards respective internal port from source interface ssl.root
- Is ping enable for DNS server? If yes, please check ping connectivity through fortilclient
If any issue verify on firewall by running below sniffer packet command to verify packet is receiving to firewall and is firewall sending to dns server or not.
#dia sniffer packet any "host x.x.x.x" 4 0 a <<<<where x.x.x.x dns server ip address.
If you are not receiving any response back , it might issue with dns server or downstream device (probably not responding to different subnet hosts. In this case you can verify by enabling NAT on firewall policy with outgoing interface.)
@msanjaypadma Hello and thanks for your responce.
I have managed to resolve the dns resolvment with the set dns suffix command as provided above.
I have a plane ssl vpn set up and not web mode.
The problem is, that the FGT wont also resolve internal DNS names from the cli.
I will investigate more with sniffer traffic command as you provided.
My best bet is that when you try to resolve internal dns names, it tries using the first DNS server in the list. An idea would be to switch their places as the internal one to be primary.
Don't know if it is the same with ssl vpn but I had an issue with DNS and IPSec VPN. The issue is that at least for IPSec VPN the gui is missing one option here: the DNS mode option.
Per default that is set to "auto" or similar and with that tunnel clients did not use the given DNS even if I entered them in the settings like the thread starter did in ssl vpn.
It only worked as it should wenn dns mode is set to "manual" on cli.
--
"It is a mistake to think you can solve any major problems just with potatoes." - Douglas Adams
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
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.