Guest User!

You are not Sophos Staff.

Thread Info
  • State Suggested Answer
  • Locked Locked
  • Replies 3 replies
  • Answers 1 answer
  • Subscribers 28 subscribers
  • Views 11178 views
  • Users 0 members are here
Options
Suggested
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

Unable to resolve host names using SSL-VPN

Mike Lennox

We are experiencing issues when users connect to the SSL-VPN with OpenVPN where they are not able to access resources by host name. We can ping internal IP's, but name resolution does not always work. We have verified that we have specified our internal DNS server and domain in the vpn settings.

The problem seems to be intermittent, and doesn't apply to all users, however it does not seem to be related to users in any specific security groups, so it's not a rights issue.

Typically, after a user connects to the VPN, they will run a login script to map drives. When they are experiencing the issue, the login script will fail as it cannot resolve the host names. If they wait several minutes and run the script again, it will work. Same goes with terminal server access.

 

Thoughts?



This thread was automatically locked due to age.
  • 0

    I was seeing similar issues and will be talking with a support tech today about this. I can't confirm yet if we know what the issue, but we suspect it has something to do with the LAN subnets that are involved.

    If you company LAN is using the same subnet as your remote LAN, the VPN wouldn't know when to route through the VPN vs local resources. Ex: your company LAN is 192.168.1.0/24 and the home network of your remote user is also 192.168.1.0/24. The VPN could be established, but even if it does correctly resolve server01.company.com, it might resolve it to 192.168.1.5, which could also be the IP address of the users SmartTV at home.

    For at least one user, I was able to verify that was the issue.

    I'll be talking with support today about enabling Full NAT for the VPN to avoid that type of issue. If I have success, I'll be able to share that here, but not likely until next week.

  • 0 in reply to GaryLobermier

    Gary,

     

    I have seen that type of issue before, and in the cases that I have been able to see first hand, they do share the 192.168.1.0/24 subnet, but in this case, the XG is located on our primary subnet with all of the servers  192.168.3.0/24. It seems that most router manufactures use the 192.168.1.0/24 subnet as the default, causing these kind of workplace issues (or opportunities, as we like to call them).

    I found a workaround for one user where I went into his Sophos SSL-VPN adapter in Windows and configured his default Gateway to that of the XG firewall 192.168.3.9, and it seems to have resolved the name resolution issue. This is just a band aid to allow him to work for now.

  • 0

    Just taking a stab in the dark here.  Are the remote workstations joined to your AD domain?  If not, you may need to use fully qualified domain names when accessing anything from the remote workstation.  Try pinging from a problem remote workstation using a fqdn.  If that works, there is a configuration in the Windows networking properties that you can make that will append the domain suffix to all host names.  I believe you can also play around with the vpn config file that gets installed to all remote workstations that will do the same thing.