IPSec Adress pools

teicee

Hello.
I'm migrating config from a Cisco PIX to pfsense. All site to site tunnels are ok.

But I don't know how to reproduce the following configuration for mobile client.

Auth : Mutual PSK + XAuth
many tunnel-group with for each a key ID + PSK (I can't define many mobile tunnels in pfSense)
for each mobile Tunnel Group : an address-pool and a policy

Example :

If I connect with ID VPN1, I will receive IP 10.10.1.1 and can only acces to Serveur 10.1.1.1
If I connect with ID VPN2, I will receive IP 10.10.1.3 and can only acces to Serveur 10.1.1.28

With Cisco PIX it is working.

Thanks for your answer

jimp

There isn't currently a way to reproduce that. The mobile IPsec config is all common, there isn't a way to have rules per user or group in that fashion.

justauserforaday

How likely will it be for functionality like this to be implemented in the GUI ? -> 'Multiple mobile IKEv2 IPSEC connections, all with different possible configuration options'

jimp

It would first have to be supported in strongSwan. Last I tried with a manually edited config in several different styles, I could not get more than one such profile to work at a time. Though it's entirely possible that was due to the configs I was attempting. It might help to pose that sort of query on a strongSwan forum or list.

justauserforaday

I'm not that experienced yet with strongSwan, considering i'm still using Openswan on a non-pfSense box, but in Openswan it's as simple as adding multiple connection definitions into 'ipsec.conf', each one with 'right=%any'. Authentication is being done using mutual RSA, or SSL certificates. That seems to replicate this functionality, and i'm assuming looking at strongSwan's history, that this should work with strongSwan too ?

jimp

In theory, yes, and when I hacked up the code to allow and output multiple mobile Phase 1 entries that is how it was in the config, but it still only ever matched the first entry and then failed authentication.

justauserforaday

I see. In that case i'll try this setup within a manually edited 'ipsec.conf' on pfSense as a test, as soon as I find a small window; multiple mobile phase 1 connection definitions, authenticated using RSA certificates. When successful, i'll post any necessary feedback here.

justauserforaday

TL;DR: Correct matching of connections when having multiple mobile connections defined within strongSwan works.

After some - very - extensive testing, the following setup is confirmed to work with pfSense 2.2.6:

IKEv2
RSA Authentication (using certificates)
Apple iOS9 clients

Current setup consists of 3, simultaneously running, strongSwan connection definitions:

site-to-site tunnel (con1)
Apple iOS9 client #1 (con2)
Apple iOS9 client #2 (con3)

Great attention has to be paid when creating the necessary SSL certificates (this subject was worth most of the troubleshooting done). Instead of explaining how to get there (out of scope), a snippet of any non-standard options that one has to take care of when creating SSL certificates yourself for the purpose of IKEv2 connections:

Subject: C=JP, ST=Kantō, L=Tokyo, O=Company ORG, OU=VPN Gateways, CN=gtw.vpn.company.org
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:AA:AA:AA:AA:AA:AA:AA:AA:11:11:11:11:11:11:11:11:22:22:CC:CC
            X509v3 Extended Key Usage:
                TLS Web Client Authentication, TLS Web Server Authentication
            X509v3 Subject Alternative Name:
                DNS:gtw.vpn.company.org
Subject: C=JP, ST=Kantō, L=Tokyo, O=Company ORG, OU=VPN Nodes, CN=hellokitty.nov.company.org
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:AA:AA:AA:AA:AA:AA:AA:AA:11:11:11:11:11:11:11:11:22:22:CC:CC
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Subject Alternative Name:
                DNS:hellokitty.nov.company.org
Subject: C=JP, ST=Kantō, L=Tokyo, O=Company ORG, OU=VPN Nodes, CN=kazuhiko.matsumoto@company.org
        X509v3 extensions:
            X509v3 Authority Key Identifier:
                keyid:AA:AA:AA:AA:AA:AA:AA:AA:11:11:11:11:11:11:11:11:22:22:CC:CC
            X509v3 Extended Key Usage:
                TLS Web Client Authentication
            X509v3 Subject Alternative Name:
                email:kazuhiko.matsumoto@company.org

Most important details to pay attention to are the 'Subject Alternative Name' and the 'Extended Key Usage'. All three previously reported x509v3 extensions have been confirmed to work.

Once you got all the certificates up according to specifications, make sure to load the root CA, any possible intermediate CA certificates, and the IKEv2 server certificates ones onto the pfSense node.

On the Apple iOS9 device, import the root CA certificate and all available intermediate CA certificates, seperately, onto the device (save them all seperately in a .crt file, load them on the web somewhere, and open them on the Apple iOS device with Safari, not Chrome. It will ask you to import them, and you're done).

The last step is to create a P12 file containing - only - your IKEv2 client certificate and it's private key. There is no need to incorporate any root / intermediate CA within the P12. I've tried many different combinations, this one works. Import the P12 file onto the Apple iOS9 device either using the web again (not tested) or by using the 'iPhone configuration utility', or 'Apple Configurator' for newer Mac OS X devices.

The last step in configuring the Apple iOS9 device is to manually create a IKEv2 profile.


Add VPN Configuration
Description: Whatever you want
Server: FQDN of IKEv2 gateway
Remote ID: FQDN of IKEv2 Gateway (this one has to match the subject alternative DNS name. If you connect using an IP, specify the IP address in remote ID, and generate an SSL certificate that contains an IP in the subject alternative name, instead of a DNS name. A combination of both should be fine as well)
Local ID: Either the FQDN of the IKEv2 client or the e-mail address of the user. Which one you need to specify depends on IKEv2 SSL client certificate that you have generated. Point is, use the exact same ID as specified in the subject alternative name section of the IKEv2 SSL client certificate

User authentication: None
Use certificate: Checked
Certificate: Pick the earlier generated IKEv2 SSL client certificate

Once all that is setup, the final step is to configure strongSwan accordingly. To make sure that the strongSwan 'ipsec.conf' configuration file will not be overwritten during testing or setting things up, either don't use any IPSEC GUI options within the pfSense web GUI, or change line 1362 of the file '/etc/inc/vpn.inc' to have the pfSense GUI write it's IPSEC configuration elsewhere. Note; a reboot of the pfSense host will restore all settings according to what pfSense knows, so even with a change to that file, a reboot will overwrite any changes. The contents of the 'ipsec.conf' file as it is tested and confirmed to work:

config setup
        uniqueids = yes

conn con1
        fragmentation = yes
        keyexchange = ikev2
        reauth = yes
        forceencaps = no
        mobike = no
        rekey = yes
        installpolicy = yes
        type = tunnel
        dpdaction = clear
        dpddelay = 10s
        dpdtimeout = 60s
        auto = add
        left = 1.2.3.4
        right = gtw.vpn.company.org
        leftid = "C=JP, ST=Kantō, L=Tokyo, O=Company ORG, OU=VPN Gateways, CN=gtw.vpn.company.org"
        ikelifetime = 7200s
        lifetime = 900s
        ike = aes256gcm128-sha512-modp2048!
        esp = aes256gcm128-sha512-modp2048!
        leftauth = pubkey
        rightauth = pubkey
        leftcert=/var/etc/ipsec/ipsec.d/certs/cert-1.crt
        rightca="/C=JP/ST=Kantō/L=Tokyo/O=Company ORG/CN=Company ORG Public Primary Intermediate CA - PRI1/"
        rightid = "C=JP, ST=Kantō, L=Tokyo, O=Company ORG, OU=VPN Gateways, CN=kyoto.branch.vpn.company.org"
        rightsubnet = 10.5.0.0/16
        leftsubnet = 10.250.0.0/16

conn con2
        fragmentation = yes
        keyexchange = ikev2
        reauth = yes
        forceencaps = no
        mobike = yes
        rekey = yes
        installpolicy = yes
        type = tunnel
        dpdaction = clear
        dpddelay = 10s
        dpdtimeout = 60s
        auto = add
        ike = aes128-sha1-modp1024!
        esp = aes256-sha1,aes256-sha256,aes192-sha1,aes192-sha256,aes128-sha1,aes128-sha256!
        ikelifetime = 28800s
        lifetime = 3600s
        left = 1.2.3.4
        leftid = gtw.vpn.company.org
        leftauth = pubkey
        leftcert = /var/etc/ipsec/ipsec.d/certs/cert-2.crt
        leftsendcert = always
        leftsubnet = 0.0.0.0/0
        right = %any
        rightid = hellokitty.nov.company.org
        rightsourceip = 10.250.100.50

conn con3
        fragmentation = yes
        keyexchange = ikev2
        reauth = yes
        forceencaps = no
        mobike = yes
        rekey = yes
        installpolicy = yes
        type = tunnel
        dpdaction = clear
        dpddelay = 10s
        dpdtimeout = 60s
        auto = add
        ike = aes128-sha1-modp1024!
        esp = aes256-sha1,aes256-sha256,aes192-sha1,aes192-sha256,aes128-sha1,aes128-sha256!
        ikelifetime = 28800s
        lifetime = 3600s
        left = 1.2.3.4
        leftid = gtw.vpn.company.org
        leftauth = pubkey
        leftcert = /var/etc/ipsec/ipsec.d/certs/cert-2.crt
        leftsendcert = always
        leftsubnet = 0.0.0.0/0
        right = %any
        rightid = kazuhiko.matsumoto@company.org
        rightsourceip = 10.250.100.60

With previously described setup, I can in fact use strongSwan with multiple mobile IKEv2 clients using solely RSA authentication using SSL certificates. The 1 site-to-site tunnel is up and active, and most importantly, not affected by any of the mobile clients. Besides that, I can connect and disconnect any mobile IKEv2 client as many times i'd like to, at the same time, one after another, it doesn't really matter, they always connect as expected, and most importantly, they match the right strongSwan connections over and over again. Keeping pings open from a terminal while connecting and disconnecting IKEv2 mobile clients, I can see the appropriate behaviour in terms of having a properly setup tunnel and in terms of strongSwan matching the correct connection depending on which mobile IKEv2 client is connecting.

Considering this has been confirmed and tested, surely other's can give it a try themselves. I'll have to implement some ugly hacks within pfSense to have these extra mobile IKEv2 connections configured within strongSwan considering the GUI does not account for multiple mobile connections. See also 'https://forum.pfsense.org/index.php?topic=107139.0'. Any chance of being able to inject your own strongSwan connection definitions in a post 2.3 release ?

For other people to benefit from my testing, i've elaborated greatly on the implemented test setup in order for others to find this thread and apply the appropriate configuration settings for an IKEv2 RSA authentication mobile client setup.

Troubleshooting methods used:

On pfSense, via console:

clog -f /var/log/ipsec.log

On Mac OS X machine, to view console of iPhone (hook up iPhone first with USB. Wireless probably also works, but not tested by myself):

brew install libimobiledevice
idevice_id --list
idevicesyslog -u 2fjk3rkf7f3jk3f37f3ufov8djh3f8fu23fo9j23lifj32