Setting up a user-to-network VPN
A guide on how to get a VPN up and running between a firewall and an end user using the SonicWall Pro 2040 enterprise firewall as a real-world example.
In a previous How To (see 'Setting up a VPN between firewalls') , we described the fundamentals of setting up a permanent VPN connection between firewalls (in that case two of NetScreen's range) at two separate sites.
The other common use of VPN technology is to allow roving or home users to connect securely into the office network using their non-permanent, dial-up connections. That's what we'll cover in this How To and, in the interests of fairness, we'll use another brand of firewall, this time a SonicWall Pro 2040.
Although the SonicWall supports L2TP VPNs (so you can connect to the VPN features using Windows' built-in VPN software), we're going to concentrate on the VPN facilities provided by the company's own VPN client application. Our review model of the Pro 2040 comes with a 10-user licence, so why not make the most of it?
Setting up the server
As we say, all the time, there are two aspects to the technologies underlying VPNs: encryption and authentication. We'll look after the authentication first. In order for the client user to identify himself or herself to the system, we need to define a username and password, which we do in the Local Users section of the Users option. All we need to do is decide on a username and password, and tick the boxes for VPN client access. In fact, as you'll see from the screenshot, we've actually ticked all the VPN boxes, in case we want to use basic L2TP protocols for this user at some point.
Next, we need to go to VPN->Settings and verify how the firewall is set up. The SonicWall devices come with a pre-configured VPN entry called Group VPN, which is pretty much configured as we need it for our remote VPN connection. If we select Edit this entry, we can make sure everything's switched correctly. First of all, in the general tab of the VPN configuration, we make sure that it's using IKE with pre-shared secret, and we make a note of the shared secret (a non-human-readable string that it's generated automatically for us). If you wish, you can enter your own alternative in here all that matters is that we know what the entry is so we can tell the client when we set it up. The IKE shared secret, by the way is the key to the other part of the VPN protocol the encryption phase.
We can leave the Proposals tab alone, as the various selections for the encryption protocols are perfectly fine for our purposes, and so we'll leap to the Advanced tab. As you'll see from the screenshot, we've chosen to enable Windows/NetBIOS broadcasts (so we can access Windows fileshares from afar) and allow forwarding to remote VPNs (so this unit can act as a VPN "hub" in an organisation with multiple disparate sites). Because our VPN clients will effectively be given IP addresses (albeit virtual ones) that live on the central office subnet, we need to tell the firewall what default gateway to present to the client machines our default route out to the big wide world is 192.168.1.1.
Finally, in the Client tab, we have some more routing information to provide. Because we want the client computer to use our main office for all its traffic, we want it to think that the firewall providing the VPN gateway is in fact its default route so we simply tick Set Default Route as this Gateway. All that's left to do is tell the system to allocate virtual IP addresses (use DHCP to obtain virtual IP) and we're sorted.
Setting up the client
Now the server's configured to allow VPN connections, we need to set up the client software on the remote PC. This is a very straightforward process, as it's largely done for us. Once we've run the installer for the software and started up the program, it throws us straight into the New Connection Wizard.
Step one is to select the "scenario" we need. Because we're connecting from afar into our corporate network, we'll choose Remote Access.
Next, we need to tell the PC where to find the other end of the VPN, by giving its IP address. We can also give this connection a descriptive name, which is useful if we have a number of different remote connections.
The last step is to tell the wizard to enable our new connection when the VPN program is launched. If you have a number of different sites that this client will VPN to, you wouldn't bother with this step, but as this is our default VPN connection, we may as well auto-enable it.
The client setup process then asks us which connection we want to dial before connecting to the VPN. We could choose not to dial automatically, but for this test we've chosen our Tesco.net modem connection.
Now we're into the connection proper. The machine has dialled the modem connection, and has spotted the firewall at the other end. It's now asking us for the pre-shared key the thing we wrote down earlier in the IKE settings and so we need to enter it in the appropriate box.
The last thing the system asks us for is the username and password, for authentication purposes (and in fact the appearance of this box means that the encryption stuff is already working, as we wouldn't be asked for authentication information if the connection wasn't intact).
Now we can test out the connection. In theory, we should now be able to ping things on our office network (192.168.1.*) from the VPN client, which is indeed the case.
And in fact, we can even make connections to Windows fileshares over the VPN.