Professionally Now Otherwise Engaged - E_FEWTIME

Christopher J. Ruwe

Configuring pfSense for IPsec VPN to Use with Android

March 13, 2015. 881 words.

tl:dr

Having recently patched my firewall running pfSense from 2.1.5 to 2.2 and having become a tad suspicious after some years experience with IT, I found out my VPN setup stopped working. (To be honest, I do not know exactly when it stopped working. I only learned about it when testing my patching procedures.)

Solution

Rolling back the corresponding ZFS dataset (my pfSense instance runs as a KVM-virtualized host inside a SmartOS hypervisor) would have been a quick option. I opted to revisit my IPsec configuration instead, though.

It appears that somehow, my earlier configuration tolerated some sloppiness the more recent does not. The reasons do not interest me much, professional experience has left me less tolerant of supposedly quick shortcuts. My favored method now is to push the custo cat into the puddle until it desists and promises to never do it again.

Revisiting my configuration and examining those of others’ (quod googlet) has left me with the impression that most do not know what they are doing have very tolerant setups from which generalization is not permissible. I walk through a slightly more general setup of IPsec VPN networking.

Debugging and Logging

First, visit the “Advanced Settings” tab under VPN: IPsec. Set all logging to “Diag”. (We will later set it to “Audit”. I reason that the default “Silent” is a … very trusting option in a firewall setup.)

Mobile Client

Then, visit the “Mobile Clients” tab and enable IPsec mobile client support. Use the “Local Database” for user authenticating and use “system” as source for group authentication.

Provide a virtual IP address to clients, any /24 network sounds like a good idea as long it is not the network the firewall/gateway resides on, i.e. it is a different network.

It also might be a good idea to allow routing of network traffic through the IPsec VPN tunnel only for a restricted set of networks. Some mobile phone VPN clients allow to specify routing, others do not.

On saving, you will be presented with the suggestion to create settings for the first phase of tunnel negotiation for mobile clients. Kindly do so.

You will be presented with a page “VPN: IPsec: Edit Phase 1: Mobile Client”.

Authentication Phase 1

Do not disable this phase 1 entry. Set key exchange to auto. Many claim that it must be V1 for IKEv1. I does not need to. (You might try IKEv1 if auto-negotiation fails. For me, it does not.) Configure the Internet Protocol to IPv4 and use the WAN interface.

Set the Authentication Method to Mutual PSK (viz. pre-shared key) and Xauth (viz. extended authentication), meaning a two-stage passphrase dialogue, first a “group password” (the PSK), then the user password as in a UNIX user password on that system. (You will need to create that user on that system and grant VPN via IPsec privileges to that user.)

In my setup, contrary to most blog entries I found, it is necessary to select the Negotiation Mode “Main”.

Set any identifier as “My identifier”, it is just a string. Use “User distinguished name” as “Peer Identifier”, which corresponds to the group we will set a pre-shared key later. A sufficiently descriptive string should suffice. Then, set a pre-shared key, make that sufficiently long for entropy, and, no, 1234567890 is long, yes, but not what I meant.

The encryption algorithm should be something sensible. I will not discuss parameters favouring the one over the other algorithm. It is not true, however, that only AES128 will work, I successfully use AES256. What my setup has in common with many blogs is that only SHA1 as hash algorithm works, though. I advise against generalization, it might be necessary to try them out. I use the DH key group 2 (1024 bit). Again, none as claimed in some setups, does not work for me. As lifetime, I set 86400 seconds, which equals a standard day.

I do not disable anything under the advanced section, I do not force NAT traversal use 10 seconds between consecutive dead peer detection retries and allow for 5 retries, so that after 50 seconds, I assume the connection has died.

Authentication Phase 2

I have set as Mode a “Tunnel IPv4” and tunnel to my local network of Type network and address x.x.x.0/24. I leave the rest unset.

For Phase 2 proposal (SA/Key Exchange), I use the protocol ESP and allow for AES256 and Blowfish Described in the Bruce Schneier childhood classic “Onefish, Twofish, Blowfish”. encryption algorithms. The statement repeated from multiple sources that only AES128 will work is at least in my setup not true.

As Hash algorithms, I allow SHA1, SHA256 and SHA512. As PFS key group I again set 2 (1024 bit). The lifetime in my setup must be set to the same value as in phase 1, i.e., 86400 seconds.

Clients

This setup works for me using

I hereby declare this bazaar opened.

Configuring pfSense for IPsec VPN to Use with Android - March 13, 2015 - Christopher J. Ruwe