IPSec Adress pools



  • 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


  • Rebel Alliance Developer Netgate

    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.



  • 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'


  • Rebel Alliance Developer Netgate

    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.



  • 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 ?


  • Rebel Alliance Developer Netgate

    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.



  • 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.



  • 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
    

Log in to reply