FortiSSLVPN Client does set the correct DNS Server on Windows 10

[gschmitt]

I tried installing the 4.0.2317 FortiClient SSLVPN on a Windows 10 client and connected to a device.

When I try to resolve Hostnames it sadly uses my normal DNS instead of the DNS set in the SSLVPN settings.

Trying NSLOOKUP also returns my normal DNS not the internal one offsite.

I installed the same SSLVPN Client version on an 8.1 client and it worked normally.

Sadly trying to install the normal FortiClient (5.2.4.0650 x64) results in an error message during installation (Install Error: The process was stopped unexpectadly).

Anyone got any ideas? Can anyone confirm that the DNS is not set correctly on a Windows 10 client?

[x_member · Accepted solution]

gschmitt wrote:

Can anyone confirm that the DNS is not set correctly on a Windows 10 client?

Yep - confirmed here both with a previously working SSLVPN build 2312 and the current SSLVPN build 2317. 

This is on a Windows 10 Pro in place upgrade from Windows 8.1 Pro (was fully functional).

*EDIT*

It looks like this is not a new issue:

https://social.technet.mi...=WinPreview2014General

[gschmitt]

CodeMonkey wrote:

*EDIT*

It looks like this is not a new issue:

https://social.technet.mi...=WinPreview2014General

Yeah I found this post yesterday aswell. Sadly the "Windows 10 is not out yet" answer isn't helpful :\

I contacted the FortiNet support and got the "We don't support Windows 10 yet" answer.

To which I quoted their 5.2.4 release notes back at them ... 

[AtiT]

Hello,

I do not have WIN10 machine but could you please test the sslvpn 5.2 version?

Download the FortiClient tools and locate the SSLVPNcmdline folder. Copy/rewrite the 4 files (EXE and 3xDLL) to the sslvpn instalation directory and try the VPN connection.

[x_member]

AtiT wrote:

Hello,

I do not have WIN10 machine but could you please test the sslvpn 5.2 version?

<snip>

Same results unfortunately.

[x_member]

deleted - not as resolved as I first thought.

[gschmitt]

Just got a call from the TAC support.

They are opening a bug report.

[x_member]

After some playing around and a lunch break I'm now able to ping servers on my test network by name when connected to the SSLVPN using the SSLVPN client v4.0.2317. 

After upgrading our test FG60D to 5.2.4 to test some outstanding issues that are already open with support I noticed on comparing the before and after configuration backups that the portal's split-tunneling-routing-address went missing during the upgrade. On attempting to reconfigure it it became apparent that an address range (for some servers on our DMZ) was no longer accepted. Removing this address object and replacing it with the DMZ subnet (splitting routing for internal and dmz subnet objects as total) was successful.

nslookup still only lists my standard connection DNS server however the issue seems resolved for me. 

I will be making the same configuration change on our live FG (running 5.2.3) to see if that resolves the issue with our live VPN.

*ADDED*

Change now in on the live FG, issue seems resolved for our configuration.

[gschmitt]

CodeMonkey wrote:

After some playing around and a lunch break I'm now able to ping servers on my test network by name when connected to the SSLVPN using the SSLVPN client v4.0.2317. 

...

nslookup still only lists my standard connection DNS server however the issue seems resolved for me. 

Well this only works if you use a local or not taken domain in your network.

I noticed the issue first when I connected to a network which resolves an internal IP differently than publicly (as an example: public dns server returns 88.77.66.55; internal returns 172.16.1.1)

[x_member]

gschmitt wrote:

CodeMonkey wrote:

After some playing around and a lunch break I'm now able to ping servers on my test network by name when connected to the SSLVPN using the SSLVPN client v4.0.2317. 

...

nslookup still only lists my standard connection DNS server however the issue seems resolved for me. 

Well this only works if you use a local or not taken domain in your network.

I noticed the issue first when I connected to a network which resolves an internal IP differently than publicly (as an example: public dns server returns 88.77.66.55; internal returns 172.16.1.1)

Ah okay - this may well not impact us then. 

On the plus side it has resolved a configuration issue for me..