Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

Hi,

our Windows 10 users use Connect Client 2.2.90 with the infamous .pro file to tonnect to XG 19.5.2 Firewall with SSL VPN TCP and access internal resources. The SSL VPN clients use the XG firewall as DNS resolver. The XG uses DNS forward rule for our internal Domain to the internal DNS servers.

Unfortunately it is a quite common issue, that the SSL VPN users bother our 1st Level with connectivity issues to some, not all, internal resources.

The workaround is usually to reinstall Connect Client and all is fine then.

Just a few minutes ago, 1st level spent half an hour diagnosing a client issue that could not connect to a single internal server while others were working. User was authenticated, had heartbeat etc. VPN profiles and Group membership were all fine. The client could neither ping or access the single server by other means. It is then like a DNS issue, the ping response is could not find host while other hosts of our internal domain are working also with FQDN, not only IP.

If you ping the IP, it is also working.

My suggestion was again to reinstall the CC client because no other issue was obvious.

After it worked fine.

I suspect the Windows adapter order is at some point messed up and some name resolution is happening on the wrong interface.

Is this a known issue (probably not) and is there a better workaround or fix for the problem?



This thread was automatically locked due to age.
Parents
  • Hey  ,

    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 ?

    Thanks & Regards,
    _______________________________________________________________

    Vivek Jagad | Team Lead, Global Support & Services 

    Log a Support Case | Sophos Service Guide
    Best Practices – Support Case


    Sophos Community | Product Documentation | Sophos Techvids | SMS
    If a post solves your question please use the 'Verify Answer' button.

  • Our problem was that the local LAN interface had Metric 1. The VPN client seems to try to get Metric 2. So if someone else has the problem and wants to automate it, you could see if it fits for you if you use this one:

    Get-NetIPInterface | where {($_.InterfaceMetric -eq '1') -and ($_.AddressFamily -eq 'IPv4')} | Set-NetIPInterface -AutomaticMetric Enabled

    It is looking for the interface with Metric 1 on protocol IPv4 and then sets this interface to Automatic which metric should be higher than 2.

    We have a client automation tool where we can put this one into a kiosk and the users can help their self with it.

Reply
  • Our problem was that the local LAN interface had Metric 1. The VPN client seems to try to get Metric 2. So if someone else has the problem and wants to automate it, you could see if it fits for you if you use this one:

    Get-NetIPInterface | where {($_.InterfaceMetric -eq '1') -and ($_.AddressFamily -eq 'IPv4')} | Set-NetIPInterface -AutomaticMetric Enabled

    It is looking for the interface with Metric 1 on protocol IPv4 and then sets this interface to Automatic which metric should be higher than 2.

    We have a client automation tool where we can put this one into a kiosk and the users can help their self with it.

Children