Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
sistemastda
New Contributor II

DNS lookup failed.

Hello friends,

 

I am configuring an access to smb/cifs via portal. But it gives me DNS error. I added the DNS point to the server IP but still I am not able to access the resource. someone could help me.

 

https://community.fortinet.com/t5/FortiGate/Technical-Tip-SSL-VPN-bookmarks-for-SMB-protocol/ta-p/19...

 

I followed this process but it does not work I have a shared resource.

 

//server/common/important

 

Could someone help me to debug if necessary?

Regards

 

9 REPLIES 9
Anonymous
Not applicable

Hi,


Thank you for using the Community. 
As per the query, I understand that the SSL VPN connection works just fine, but you observed the 'DNS lookup failed' on the browser, am I correct?

Best,
Irfan

 

 

Debbie_FTNT
Staff
Staff

Hey sistemastda,

can you clarify what kind of error message you get? DNS error is a bit broad.

Can you perhaps share a screenshot of your bookmark configuration as well?

If you set the bookmark with an FQDN (server/test), can FortiGate resolve this?

 

 

 

+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++
sistemastda
New Contributor II

Hello,

The problem is that when I try to access a shared resource or a shared directory it does not let me access either with the user or domain user. It gives a DNS Lookup Failed error. I also tried to put the IP of the server and also gives the same error. How can I debug to resolve the issue.

 

sistemastda_0-1645434456837.png

Thanks

 

Anonymous
Not applicable

Hi, 


Can you please confirm the following: 
- firewall policy allows the traffic to reach the DNS

- the DNS server is listed in the output when connected to VPN by typing 

      ipconfig

     nslookup internal-name

 

For example: 

nslookup internal-name

Server: your-DNS-server

Address: 10.20.30.213

 

ipconfig

DNS Servers . . . . . . . . . . . : 10.20.30.213

sistemastda

Hi @Anonymous 

 

This is through the SSL-PORTAL not through the Client. I mean I access the URL. https://xxxx.xxxx.xx.:10443 I enter my username and password and I see the bookmarks that I have among them I have one that is shared resource. That is where I get the error.

 

Greetings

 

 

Debbie_FTNT

Try configuring your bookmark with 'set folder <path>' or 'set folder <ip/folder>', NOT with 'smb:' in front.

FortiGate should know that the link is smb from 'apptype smb' automatically, no need to specify this in the actual path.

+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++
sistemastda

Hi @Debbie_FTNT 


I keep getting the same thing DNS LOOKUP FAILED, tried smb://gort/comun$/Testing, //gort/comun$/Testing gort/comun$/Testing //10.10.20.2/comun$/Testing same problem.

 

 

sistemastda_0-1645448472802.png

Regards

 

Debbie_FTNT

Have you tried just "10.10.20.2/comun$/Testing"?

+++ Divide by Cucumber Error. Please Reinstall Universe and Reboot +++
fcb
Contributor

Just cut to the chase and use the built in packet capture utility or even better use the flow debug application to quickly see what the traffic is doing. Learn how to do this and you Fortigate troubleshooting just went into overdrive, guarantee it!

 

diag debug reset
diag debug flow filter clear
diag debug flow filter saddr {Your.IP} but do not include the {}
diag debug flow filter port 80
diag debug flow show console enable
diag debug flow show iprope enable
diag debug flow show function-name enable
diag debug console timestamp enable
diag debug enable
diag debug flow trace start 1000

  • (You can also use the resource or destination address with the command: diag debug flow filter daddr IP.of.Remote.Resource)
  • (You can also look for only the address (not SRC or DST) with: diag debug flow filter addr {Whatever.IP.You.Want} Leave off {}
  • (You can also look for only DNS queries: {diag debug flow filter port 443} Again - no {})

Once you capture the flows be sure and run:

diag debug reset

diag debug disable

 

Look through the data for the problem. If it were me and the system was not too busy I'd probably just look at the port 53 traffic but it will take some tweaking to get it just right for your application. It will tell you the issue but if you're not sure post back here and someone will decipher for you.

 

This could also prove helpful

diag sniffer packet any 'port 53' 4 999 l

OR

diag sniffer packet any 'ip.of.ssl.client' 4 999 l

OR

diag sniffer packet any 'ip.of.remote.resource' 4 999 l

 

(note that you DO need the ' and ' in the packet capture application but the 999 and l (that's an L to show the local time) are not required but it's the way I run PCAP's and I run about 10 to 15 a week, easily that many.)