Guest User!

You are not Sophos Staff.

Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 1 reply
  • Subscribers 27 subscribers
  • Views 858 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

Problems with SSL VPN on Local Subnet

Don Clayton1

Hello,

I am quite new to some of the Sophos XG configuration practices. We have an XGS116W running SFOS 18.5.1 MR1 Build 326

I took over a server that is on the 192.168.1.x network. This server is the only server at the office and it is also the DNS & DHCP server.

My own home computer is also on a 192.168.1.x subnet.

If I connect to the site using SSL VPN, I cannot browse or connect to anything on the companies local subnet. Do I need to add a DNS server to my SSL VPN configuration? If I need to do this, what do I need to add and where do I add it?

Our main company printer is at 192.168.1.250. I am unable to ping it and get a response. Any insight would be appreciated.



This thread was automatically locked due to age.
Parents
  • 0

    Bottom line: change your local subnet away from 192.168.1.x.

    If your personal printer is at 192.168.1.5 and your company's SQL database server is at 192.168.1.5, how would you expect your computer and the Sophos at the other end to guess which one you're trying to access? DNS simply turns a hostname into an IP address, and has nothing to do with this conflict.

    Ultimately, when your local computer decides that another computer it's trying to contact is on your LAN (based on its IP address being 192.168.1.x), it will ask for the MAC (ethernet) address that corresponds to the given IP address and will use that MAC address to communicate directly. If your local computer decides that another computer is not on your LAN (i.e. its IP address is not in 192.168.1.x), it forwards the packet to its gateway (your local router, probably 192.168.1.1)  figuring that the gateway will know how to get it to the destination. In fact, your local computer, your local router, and the Sophos are all caching local (to them) IP-MAC mappings on a regular basis.

    At the far end of the VPN your machine is known by the IP address from the range you set up in the Sophos' SSL VPN configuration. Let's say that's 192.168.100.5. That's your machine's IP address as far as everything on the corporate network is concerned. And everything on your home network knows your computer as, say, 192.168.1.12.

    The Sophos is also aware of your public IP -- the IP address that your ISP has assigned to your router/modem. And that can't possibly be 192.168.1.x since those addresses are reserved for private use.

    At a very minimum, your local computer has to deal with two local 192.168.1.x addresses: its own and its gateway (router). No getting around that. Your local computer will also see lots of 192.168.1.x traffic flowing around it and to it for various services. I guess it might be possible with a very sophisticated routing setup -- managed by your SSL VPN configuration and SSL VPN software -- on your local computer to individually distinguish 192.168.1.x addresses and ignore everything except your own IP and the Router's IP, but I don't think it's possible.

    If you're using DHCP on your local network, it'd be easier to change away from 192.168.1.x. The better solution is for work to not use that IP range since it's commonly used at home and thus will cause problems like this, but it could be a lot more complex to make a change at work than at home.

Reply
  • 0

    Bottom line: change your local subnet away from 192.168.1.x.

    If your personal printer is at 192.168.1.5 and your company's SQL database server is at 192.168.1.5, how would you expect your computer and the Sophos at the other end to guess which one you're trying to access? DNS simply turns a hostname into an IP address, and has nothing to do with this conflict.

    Ultimately, when your local computer decides that another computer it's trying to contact is on your LAN (based on its IP address being 192.168.1.x), it will ask for the MAC (ethernet) address that corresponds to the given IP address and will use that MAC address to communicate directly. If your local computer decides that another computer is not on your LAN (i.e. its IP address is not in 192.168.1.x), it forwards the packet to its gateway (your local router, probably 192.168.1.1)  figuring that the gateway will know how to get it to the destination. In fact, your local computer, your local router, and the Sophos are all caching local (to them) IP-MAC mappings on a regular basis.

    At the far end of the VPN your machine is known by the IP address from the range you set up in the Sophos' SSL VPN configuration. Let's say that's 192.168.100.5. That's your machine's IP address as far as everything on the corporate network is concerned. And everything on your home network knows your computer as, say, 192.168.1.12.

    The Sophos is also aware of your public IP -- the IP address that your ISP has assigned to your router/modem. And that can't possibly be 192.168.1.x since those addresses are reserved for private use.

    At a very minimum, your local computer has to deal with two local 192.168.1.x addresses: its own and its gateway (router). No getting around that. Your local computer will also see lots of 192.168.1.x traffic flowing around it and to it for various services. I guess it might be possible with a very sophisticated routing setup -- managed by your SSL VPN configuration and SSL VPN software -- on your local computer to individually distinguish 192.168.1.x addresses and ignore everything except your own IP and the Router's IP, but I don't think it's possible.

    If you're using DHCP on your local network, it'd be easier to change away from 192.168.1.x. The better solution is for work to not use that IP range since it's commonly used at home and thus will cause problems like this, but it could be a lot more complex to make a change at work than at home.

Children
No Data