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:
- 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).
- 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.
- 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!
- 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.
There are lots of GUIs, but the command-line method is extremely simple when you need it quick and ad-hoc. This works with Fireware version 11.8 and after. First web-browse to here:
where 18.104.22.168 is the IP of your Watchguard. Then login and pull in client.ovpn from the lowermost link. Then just run:
openvpn --config client.ovpn
login in, and you’re in. If the Watchguard has multiple SSL VPN configs and the default is the wrong IP, just change the IP in the .ovpn file and it will work fine.
This is specifically for Watchguard IPSec mobile user VPN, but is probably applicable in other IPSec situations also.
When setting up IPSec VPN, at least in some paradigms, the server side is set up without DNS/WINS settings, and then in the client profile, after the import, one does this in “IPsec Address Assignment”:
Local IP address (takes the IP from the local LAN)
DNS Server: <destination LAN DNS or general>
WINS Server: <destination LAN WINS or none>
Domain Name: <destination LAN-local domain>
Some notes on the destination side.
- In the Watchguard IPSec VPN configuration, the “virtual IP range” under resources, has to be a range (a) included in the DHCP distribution but (b) excluded on the DHCP server (if any) at the destination; it has to be part of the destination subnet. It is reportedly also possible to set the router up to use a new subnet for this, but this requires adding a rule in the router and is more complex.
- If there is a Windows domain controller at the destination, recommended is to set the Watchguard IPSec VPN for Active Directory authentication. In such a case, the “Group Name” has to be a Security Group in the AD of exactly the same name, case significant, as exists on the server, and any user has to be a member of that group. If a user attempts to connect who is not a member of that group, connection will occur, but RX will remain at zero bytes.