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
-
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'
-
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 ?
-
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.orgMost 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 certificateOnce 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.60With 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
