Subnet Changes Not Needed with OpenVPN-based SSL "VPN"

article #1117, updated 2607 days ago

Definitions and items:

  • VPN stands for Virtual Private Network. A true VPN connects two different networks, using an encrypted “tunnel” through Internet or other non-private connectivity.
  • SSL VPN as defined by OpenVPN (and its wrappers like Watchguard SSL VPN), is not a true VPN. It is an SSL-encryption agreement between devices, building either a TCP tunnel or a UDP dataflow, over which tightly controlled network redirection traffic is distributed.
  • This means that the source and destination subnets, though not IPs, can be the same.

So let’s say that we need to give a PC which is sitting on someone else’s 192.168.1.0/24 network, an encryption-protected connection for RDP and file sharing, to the office Windows machine at 192.168.1.20. If SSL VPN were true VPN, this would require a subnet change at either the remote side or the home LAN, no further option. But it’s not, so we can do this:

  1. Restrict the SSL VPN capability on the office side, to just the domain controller (e.g., 192.168.1.250) and the RDP destination (192.168.1.20).
  2. Make sure that the IP of the device on the remote side, is not a duplicate of either the domain controller or the RDP destination on the office side. So it can’t be either 192.168.1.250 or 192.168.1.20.
  3. We can do this by setting a static IP on the remote device; alternatively, we can change the DHCP subnet of the remote site. Either of these are vastly easier than changing subnets!
  4. The only loose end left, may be network printing on the remote side. Just make sure that the printer’s IP is not any of the vitals at the office, and is IPv4, and it will work just fine. Some printers (generally consumer-grade) are defaulting to semi-proprietary IPv6 modes in their Windows configurations, and at least some SSL VPN configurations will not play ball; in this scenario you’ll want to convert the PC setup(s) to use v4.

Categories: