SSL VPN Connect Client 2.2.90, internal DNS name resolution broken, need to reinstall client

Hey LHerzog ,

Thank you for reaching out to the community, instead of reinstalling the CC client, what if you change the metric of TAP adapter to be lower priority (higher value) than that of the local LAN, does that help too ?

No idea, also not what I want to do regularly. But I must wait for the next time it happens.

we have the same problem but even reinstalling doesn't change this behavior on one client. Tested an older version which we were used to (really old version 2.0) and this one didn't work either. Case is opened 06942862.

Hi K-M,

Thank you for sharing your case ID, will put a note on and further monitor this.

thanks for the fast reply. There is another case which maybe corresponds to it. The changing of the DNS servers seems to be broken, too. If there are already DNS servers in the connection they will not be replaced but cumulated with newer ones: 06942846

Hi K-M  For this other case ID - 06942846 I checked your shared information and that is related to "Connect client appends DNS addresses instead of replacing them". This is known to the Sophos Dev team and is going to be fixed with Sophos Connect 2.3 with ID NCL-1383.

Very bad information, when will this release be?

Because we now have many clients where we have to change the DNS server by hand now. That is nearly impossible...

Maybe you have a beta for us?

And you should tell the supporter because he has no clue about it... Don't know why nobody seems to check the internal database for this.

Hi K-M  I have already added an internal note on the shared case (06942846 ), regarding the release date info we will check with our team and update you on the case. 

Hi K-M  As per the shared information for case ID 06942862 - this is only getting observed for one client, For that machine would it be possible to share the below output from Powershell (with Run as administrator) during an issue time to validate all other interfaces' status and priority in the same machine:

>Get-NetIPInterface

Hi K-M  As per the shared information for case ID 06942862 - this is only getting observed for one client, For that machine would it be possible to share the below output from Powershell (with Run as administrator) during an issue time to validate all other interfaces' status and priority in the same machine:

>Get-NetIPInterface

ifIndex InterfaceAlias                  AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp     ConnectionState PolicyStore
------- --------------                  ------------- ------------ --------------- ----     --------------- -----------
1       Loopback Pseudo-Interface 1     IPv6            4294967295              75 Disabled Connected       ActiveStore
20      Ethernet 2                      IPv4                  1400               2 Enabled  Connected       ActiveStore
4       LAN-Verbindung* 2               IPv4                  1500              25 Disabled Disconnected    ActiveStore
9       Bluetooth-Netzwerkverbindung    IPv4                  1500              65 Enabled  Disconnected    ActiveStore
19      LAN-Verbindung* 1               IPv4                  1500              25 Enabled  Disconnected    ActiveStore
7       Ethernet                        IPv4                  1500               1 Enabled  Connected       ActiveStore
16      WLAN                            IPv4                  1500              25 Enabled  Disconnected    ActiveStore
1       Loopback Pseudo-Interface 1     IPv4            4294967295              75 Disabled Connected       ActiveStore

7 is the local LAN interface to the router/gateway, 20 is the VPN connection

Hi K-M  Thanks for sharing this output, would it be possible to share similar output and information from another system (with a similar OS type) where it works fine to compare both details my side? (Sorry I missed it to request the same from you in my earlier comment)

Not necessary. Compared it already. Somehow on the local LAN interface there was the automatic metric disabled and set to 1. So it was always first. Enabled automatic metric now and it is working. Thanks for pointing it out, will put in the case and close it.

We have to take a look at this device class. Maybe this setting is set while installing the device driver as it is kind of new in our environment. 

Hi K-M  Thanks for the resolution update for community users' reference and I am glad you managed to figure it out with the above command hint and output.

Hey K-M , Thanks for the update, that was the suggested answer earlier on this thread !

Yep, but it was a helpful hint to get a fast overview via powershell. Also read the KB article from Microsoft so that it is now much more clear how this system acts. Didn't get that entirely before.