Another possible scenario is one in which we want to create an IPsec tunnel so that remote users can connect to the tunnel using an IPsec client on their computer. This is the scenario that would exist if we are a company that has to support workers who are not at one of the company's sites, but still need to access the company's network. This might be the case if they are on site at a client's workplace, if they are on a business trip, or perhaps working at home. Fortunately, there are IPsec clients for all the major desktop operating systems.
One of the more popular IPsec VPN clients for Windows is the ShrewSoft VPN Client. Although it hasn't been updated in a while (the last stable release of the client is 2.2.2, released in July 2013), it is a stable client with many options. You can download the client at https://www.shrew.net/download/vpn.
To show the ShrewSoft VPN Client in action, we will step through the process of setting up an IPsec tunnel, which we will then connect to as a mobile client using ShrewSoft's VPN Access Manager. We begin by navigating to VPN | IPsec and clicking on the Mobile Clients tab. To enable mobile clients, check the Enable IPsec Mobile Client Support checkbox.
The Extended Authentication (Xauth) section has two settings: User Authentication and Group Authentication. User Authentication has one option, Local Database, so we won't make any changes here. For Group Authentication, we will select system.
In the Client Configuration (mode-cfg) section, we will configure a virtual address pool for the remote client. Thus, we check the Provide a virtual IP address to clients checkbox, and enter a subnet and CIDR below the checkbox. For purposes of this exercise, we will set the network to 172.25.0.0/16.
The next setting that we will alter is Save Xauth Password. We will check this checkbox. We will also check the DNS Default Domain checkbox, and enter localdomain as the default domain name. We will also check the Provide a DNS server list to clients checkbox. For Server #1, we will enter 8.8.8.8, and for Server #2, we will enter 8.8.4.4. We will also check the Login banner checkbox and enter a login banner to clients. We then click on the Save button at the bottom of the page.
As you can see, pfSense is prompting us to create a corresponding Phase 1 entry for the mobile client configuration. The Phase 1 and Phase 2 entry we create in this manner will be designated as the mobile client IPsec tunnel, which is why you want to complete mobile client configuration before creating an IPsec tunnel – it will make the process much easier. We click on the Create Phase 1 button to begin IPsec tunnel configuration.
In the Key Exchange version drop-down box, we want to select V1, as the ShrewSoft Client will not work with V2; I was unsuccessful in getting it to work on the Auto setting as well. We will leave Internet Protocol, Interface, and Description unchanged. Since we are going to require mobile user authentication, we set the Authentication Mode drop-down to Mutual PSK + Xauth. We will leave the Negotiation mode set to Aggressive and My identifier set to My IP address. We will change Peer identifier to User distinguished name and enter vpnuser@ipsectest. duckdns.org in the corresponding edit box. In the Pre-Shared Key box, we will enter betterthannothing.
In the Phase 1 Proposal (Algorithms) section, the default values are acceptable, so we will not change them. In the Advanced Options section, we will change one setting: we will change the NAT Traversal setting to Force to force the use of NAT-T on port 4500. Once we are done, we will press the Save button, which will take us back to the main IPsec page.
From the main IPsec page, we click on Show Phase 2 Entries in the mobile client entry. Then we click on the Add P2 button to add a Phase 2 entry for this tunnel. In the General Information section, we will keep the default settings. In Phase 2 Proposal (SA/Key Exchange), we will keep Encryption Algorithms as AES, but we will change the value in the drop-down box from Auto to 256. 3600 is a bit short for Lifetime, so we will change this value to 28800. When done, we will click on the Save button; then we will click on the Apply Changes button on the main IPsec page.
We still haven't created a user group and users for the VPN tunnel, so we will next navigate to System | User Manager and click on the Groups tab. Then we click on the Add button below the table to the right to add a new group. We enter a group name of vpnusers, and in the Scope drop-down box, we set the scope to Remote. Then we click on the Save button.
We must assign privileges to vpnusers, so we click on the Edit icon for vpnusers in the table. On the configuration page for the group, there will now be a section called Assigned Privileges, and we click on the Add button. In the Assigned Privileges listbox, we select User – VPN: IPsecxauthDialin and click on Save. From the main configuration page, we click on Save again. The group is now configured.
Now all we have to do on the local side is to create at least one user for the newly created group. We click on the Users tab and click on the Add button to create a new user. We set the Username to remoteuser and the Password to suPerseCret01.
Under Group Memberships, we make remoteuser a member of vpnusers. For the IPsec Pre-Shared Key, we re-enter the key we entered earlier (betterthannothing). Then we click on the Save button.
We are now done with configuration on the local side, and only need to configure the remote client. We launch the ShrewSoft VPN Access Manager, and then click on the Add button on the toolbar to add a new configuration profile. The General tab has two sections: Remote Host and Local Host. Keep in mind that the remote host and local host are now the reverse of what they were when we were configuring the other end of the connection. For Host Name or IP Address, we generally want the WAN IP of the router on which the IPsec tunnel was set up in the previous step, unless this router is behind another router, in which case you would enter the internet IP address of your network. If you set up dynamic DNS, you can enter the DDNS hostname here. In this case, we created the domain name ipsectest. duckdns.org, which provides a domain name for the pfSense router. For Auto Configuration, we want to select ikeconfig pull from the drop-down box. Finally, since the remote peer will be assigning virtual IP addresses to clients, we select Use a virtual adapter and assigned address in the Adapter Mode drop-down box. The Obtain Automatically checkbox should be checked, since the remote peer will be assigning the IP addresses. MTU can be kept at 1380.
The next tab is the Client tab. Here, we want to set NAT Traversal to enable to match the setting on the remote end; NAT Traversal Port should be set to 4500, which is the default value. The default values for Keep-alive packet rate, Ike Fragmentation, and Maximum packet size should be fine. We will check the Enable Dead Peer Detection, Enable ISAKMP Failure Notifications, and the Enable Client Login Banner checkboxes.
The next tab is called Name Resolution. It has two tabs of its own: one is called DNS and the other is WINS. Since we are not dealing with WINS servers, we will focus only on the DNS tab and check the Enable DNS checkbox. We also check the Obtain Automatically checkbox for DNS, and the Obtain Automatically checkbox for DNS Suffix.
Next, we move to the Authentication tab, which has three of its own tabs: Local Identity, Remote Identity, and Credentials. The method selected in the Authentication Method drop-down box must match what we set during Phase 1 configuration of the IPsec tunnel in pfSense, so we set it to Mutual PSK + XAuth. Local Identity must match Peer Identifier in Phase 1, so we select User Fully Qualified Domain Name (meaning user + FQDN).
For UFQDN String, we enter [email protected], just as we did for Peer Identifier in pfSense. On the Remote Identity tab, we can keep the default Identification Type of IP Address and move on to the Credentials tab. We are using a PSK, and the PSK must match the one we entered during Phase 1, so in the Pre Shared Key edit box, we enter betterthannothing.
The last two tabs we must configure are Phase 1 and Phase 2. Moving to Phase 1, we must match the settings with those entered during Phase 1 configuration on the other end, so we set Exchange Type to aggressive and DH Exchange to group 2 (1024 bits). The next three options you could set as auto, but the software seems to work better if you match the settings on the other end of the tunnel exactly. Therefore, we set Cipher Algorithm to aes, Cipher Key Length to 256, and Hash Algorithm to sha1. We set Key Life Time limit to 28800 secs, and we leave Key Life Data Limit at 0 Kbytes.
Moving on to the Phase 2 tab, we set Transform Algorithm to esp-aes and Transform Key Length to 256. HMAC Algorithm should be set to sha1, and PFS Exchange and Compress Algorithm should be kept at their default values of disabled. We set Key Life Time limit to 28800 secs and Key Life Data limit is kept at 0 Kbytes. On the Policy tab, we do not need to make any changes, so we click on the Save button at the bottom.
Our client configuration is complete, so we can now click on Connect on the menu bar to try it out. We will be presented with a dialog box that states config loaded for site <this_site>. Click on the Connect button to start connecting. The VPN Access Manager will prompt us for a username/password combination, so we enter the username and password for the user we created in the previous step (remoteuser, suPerseCret01). We click on Connect again. The client should take a minute or less to connect to the tunnel. Once we are connected, we will be able to access the LAN subnet on the remote end as if LAN is a local resource.