Custom DNS is not working with a VPN Client

[raffaeledp]

Hello everybody, 

I'm working on a 60F Fortigate.

I have an internal domain called vpn.xxx.com. I set some custom DNS records to redirect the request to vpn.xxx.com to a specific machine. The interface we are working on is the Wi-Fi interface.

 

From the picture, 192.168.1.1 is the router. So far, so good. Everything is working. My network settings are:

 

 If I ping vpn.xxx.com:

 10.1.0.1 replies correctly

Now I connect to a VPN Client. The network settings I showed before remain the same. The difference, now is that 10.1.0.1 is not the one ho replies to the ping. Now, 79.x.x.x replies to the ping:

and vpn.xxx.com is not reacheable anymore. Who is 79.x.x. x? Is the WAN interface of the Fortigate:

Now, you cou ld say that the problem is the VPN, that probably changes some DNS stuff. It could be right, but there is only one problem. If I disconnect from the Wi-Fi (on wich are set DNS custom records) and connect to my phone hotspot and to the VPN Client, vpn.xxx.com is reacheable again.

To the ping, 79.x.x.x replies correctly and vpn.xxx.com is correctly functioning.

What's happening? Thank you very much for your support!

 

[raffaeledp]

Just to be clear:

the only time that vpn.xxx.com is not reacheable is when I'm on the Wi-Fi and I have the VPN client turned on.

[ebilcari]

Indeed it seems like a DNS resolving issue, most probably after the VPN is connected, a public DNS server is used to resolve domains that's why you get the public A record. You can verify with nslookup command in the end host which DNS server is responding.

Is the VPN connected with the same FGT or to another device?

[raffaeledp]

this are the nslookup (the VPN client is on the device which is pinging vpn.xxx.com):

Wi-Fi network without VPN (functioning):

raffaeledipascale@MacBook-Pro-DiPascale ~ % nslookup vpn.xxx.com

Server:    10.1.10.1

Address:  10.1.10.1#53

Name:  vpn.xxx.com

Address: 10.1.0.1

Hotspot (or any other network) network with VPN (functioning):

raffaeledipascale@MacBook-Pro-DiPascale ~ % nslookup vpn.xxx.com

Server: 10.20.10.115

Address: 10.20.10.115#53

Non-authoritative answer:

Name: vpn.xxx.com

Address: 79.9.x.x

Hotspot (or any other network) without VPN (functioning):

raffaeledipascale@MacBook-Pro-DiPascale ~ % nslookup vpn.xxx.com

Server: 96.45.45.45

Address: 96.45.45.45#53

Non-authoritative answer:

Name: vpn.xxx.com

Address: 79.9.x.x

Wi-Fi network with VPN (not functioning):

raffaeledipascale@MacBook-Pro-DiPascale ~ % nslookup vpn.xxx.com

Server:    10.20.10.115

Address:  10.20.10.115#53

Non-authoritative answer:

Name:  vpn.xxx.com

Address: 79.9.x.x

[ebilcari]

It appear that after the VPN is connected, the client is forced to use this DNS server: 10.20.10.115, that most probably forward the requests to a public DNS server that's why it responds with a public IP.
Do you manage the network device that offer the VPN to this client?
What is the final goal in this case, do you need the name resolution of 'vpn.xxx.com' to connect to a second VPN while still connected in the first VPN?

[raffaeledp]

Thanks for your reply,

the goal is to obtain the same behavior from the Wi-Fi network and from the Hotspot network. 

The problem is that the VPN is causing problem only on the Wi-Fi network.

If I look at the two dnslookup, they look the same:

Hotspot (or any other network) network with VPN (functioning):

raffaeledipascale@MacBook-Pro-DiPascale ~ % nslookup vpn.xxx.com

Server: 10.20.10.115

Address: 10.20.10.115#53

Non-authoritative answer:

Name: vpn.xxx.com

Address: 79.9.x.x

Wi-Fi network with VPN (not functioning):

raffaeledipascale@MacBook-Pro-DiPascale ~ % nslookup vpn.xxx.com

Server:    10.20.10.115

Address:  10.20.10.115#53

Non-authoritative answer:

Name:  vpn.xxx.com

Address: 79.9.x.x

I cannot manage the device that is offering VPN access service. The client is Cisco Secure Connect.

How is that possibile that the same dnslookup works in the first case but not in the second case?

[ebilcari]

After the VPN is connected, verify the routing table of the end host on how the public IP is reachable 79.9.x.x (full or split tunnel).
In case the VPN is in split tunnel mode and the host is connected to the WiFi provided by the same FGT, FGT may drop the packets that are coming from the WiFi interface (internal) towards its WAN interface.

[bakriwa5]

Usually with clients connecting to SSL VPN, they use whatever DNS servers your VPN gateway tells them to use. These servers should be specified somewhere in your client VPN configuration. The ISP cannot magically hijack your VPN clients' configuration and inject their own DNS server into your IP, you are giving this out to your clients somewhere along the chain

[raffaeledp]

Thanks for your reply. What I don't undestand is that in both cases, the dnslookup gives the same result, but if the vpn is on wifi, vpn.xxx.com is not reacheable.