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. [image: radius.PNG] [image: 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.

It's a bug in the windows client that strongSwan won't work around. See https://wiki.strongswan.org/issues/220 for part of it, search around for more context. If you want it fixed, advocate to the strongSwan project that it should be fixed. Though everyone has moved on to IKEv2, which is much better all-around, so few people are still interested in working on L2TP/IPsec.

was wondering if you have had any update on this?

You have a mismatch of some sort on the phase 2. Maybe the PFS key group, but check it all.

The initial connection comes up fine. Just after the 24h disconnect the tunnel will not be reestablished and I get the same log entries. It seems the ISP cut the line all 24h once, like here in Germany and the IPSec connection is not coming up proper again. Confusing but maybe helpful: If I use another IPSec connection from my Smartphone (with VPNCilla, inside LAN) to the Fritz!Box then the pfsense tunnel comes up simultaneously  :o If there will be then a packet flow through the tunnel it will be perhaps revive the older IPSec VPN tunnel also again and its up then. Did you try out to get from your PC a link or data flow through the tunnel by opening the briwser and start connecting some devices on the other side of the VOPN tunnel, or perhaps another program running on a device in the LAN?

@jimp: How many Phase 2 entries do you have? IIRC AWS will only allow so many P2 entries (3, I think) and if you establish another one after that, they will disconnect one of the previous entries in exactly that fashion. Hi, I had since found the issue and that was in fact the problem. These symptoms are buried in this Amazon tech note https://aws.amazon.com/premiumsupport/knowledge-center/vpn-connection-instability/. Really difficult to track down because you don't have access to any logs on the AWS side… Cheerio, Harry.

Basic network config on the hosts in question the next most likely. Missing or wrong default gateway, wrong subnet mask.

You're at least a version or two behind. Upgrade, then if you're still having an issue, post your IPsec logs again and what you're trying to configure.

@Garrett: Just found a workaround by appending another bogus domain name in my split-dns list from: "mydomain.com" to "mydomain.com bogus.com". That seemed to do the trick. That'll work around it. The root issue, which was a client-side problem, was fixed in OS X El Capitan for sure, and I believe a newer iOS version than this thread originally referenced as well.

For local clients and EAP-MSCHAPv2, they go on the PSK tab, with entries set for EAP, as described in the documentation: https://doc.pfsense.org/index.php/IKEv2_with_EAP-MSCHAPv2#Create_Client_Pre-Shared_Keys

Hi, Alternative you Need two ip addresses at colocation, setup transport IPSec connections and gre Tunnels over it. Sorry for spellings Tablet with wrong keyboard Best regards Thomas