What you actually want is the client on the same broadcast domain, not (just) the same IP subnet. You can use a mobile IPsec tunnel network that's a subset of your LAN, if you add proxy ARP on LAN for that subset, but that won't get the clients on the same broadcast domain. No mobile IPsec clients support that.

Are you using multiple gateways?  What do your rules look like on your interfaces?  Allow all on each?

Issue solved. You do not have to enter user/pass in user manager, but in sahred key section…

With me is fresh install of 2.2.6 - so no upgrade…....
IkeV2 is not an option as V2 is not suppported by  older 2.0.X boxes :( Good you do not have the problems...I guess we will have to upgrade too...Just wanted to avoid it if possible.

OK just limiters.

I would disable the rule you added, turn logging on on the main pass rule, try to open connections across the VPN, and see what they logs say.

Hmm. Limiters. I don't see anything that should do it but you might be hitting the 2.2.X limiter bug. Also disable the rule you added and try it without the limiters set.

Oh sorry last time i did not  realize that you try to connect to a mobile android

For my android 5.1.1 with strongswan app  as a road warrior it looks like
( important part;  leftsub 0.0.0.0)

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 left = xxx.xxx.xxx.xxx right = %any leftid = "C=xxx, ST=xxxx, L=xxxx, O=xxxx, E=postmaster@xxx, CN=xxxxxx" ikelifetime = 28800s lifetime = 3600s rightsourceip = 192.168.123.0/24 ike = aes256-sha512-modp2048! esp = aes256-sha512! eap_identity=%identity leftauth=pubkey rightauth=eap-tls leftcert=/var/etc/ipsec/ipsec.d/certs/cert-3.crt leftsendcert=always rightca="/C=xxx/ST=xxx/L=xxx/O=xxx/emailAddress=postmaster@xxx/CN=xxx-internal-ca/" leftsubnet = 0.0.0.0/0

But maybe just remove all ipsec config and restart pfsense, i had this once wit a hanging ipsec tunnel…

regards max

I need to monitor the ipsec tunnel on Nagios using snmp or SSH.

Hm, might be some edge case there where somehow the SPD isn't populated. If strongswan's running at all, it'll have that populated though. I can't think of any circumstance where that could occur. Definitely would be interested in steps to replicate if you come across something.

If IPsec were disabled for any period of time during troubleshooting, that could explain it.

Not installing NAT reflection rules for a port range > 500

Something is trying to get from the internal LAN through the WAN interface to connect in
the DMZ or LAN homed Servers and there are no rules for NAT reflection (Hairpin NAT)
could this be a problem too?

IPSEC: One or more IPsec tunnel endpoints has changed its IP. Refreshing.

Is there in the other LAN perhaps something likes an enabled DHCP Server that is giving
new IP addresses to servers or other devices that should be sorted more with static IP addresses?

Sounds like that's a completely separate issue so best to start a new thread to avoid confusing two unrelated things.

Sorry my english is too bad for knowing what you want….

I've done some more testing.  I'm super interested to know if other people obtain the same results.

Basically, I can get a connection working with IPCOMP turned on when Nat-T is forced (IKE v.1).  This seems to be a bug because disabling IPCOMP and putting Nat-T back to auto (StrongSwan apparently has no disable option  >:( ) breaks the IPSec connection and I haven't been able to get it back, even with changing all the settings and refreshing the services…so once Nat-T is forced in pfSense, the system somehow remembers it and forces it on even in IKE v.2 in networks where it is not appropriate.  :-*

I'm happy to see IPCOMP working, but in my preliminary tests (no hard data), it has not improved throughput even with compressible data.  I've tested with pfSense boxes running super-duper 3.5GHz Xeons as well as an Atom-based box.

However, im still keen to know why I am not maxxing out the connection speed using IPSEC even with my twin quad core xeon boxes?

If this CPU has AES-NI and you will be trying out IPSec (AES-GCM) it could be that you will be getting other
numbers or it will be even acting faster.

Your clients in 192.168.1.x/24 have the default gateway 192.168.1.1 so they send all traffic outside the lan direct to the comtrend dsl router.

can't work in this way…

I had a similar issue.  I selected the following and it started working.  The article I followed for openvpn stated I do this to very connectivity before locking down.  Change the order of the policies so that pfsense is in the middle.

Enable the other options as marked in red. Download the photo to see changes to the far right.

radius.PNG
radius.PNG_thumb

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

AFAIK, strongswan doesn't support any alternatives for auth for that type at this time.
https://wiki.strongswan.org/projects/strongswan/wiki/Win7EapMultipleConfig

EAP-RADIUS is probably a better choice with AD.