SOLVED: had nothing to do with the VPN configs, but one side pfsense is on KVM and was still offloading some checksum calculations to virtual hardware. Disabling all offloading as even mentioned in the pinned pfsense Xen/KVM FAQ fixed it. Stupid me, not my first pfsense on KVM  :-[

Please let me know what you used for both P1 and P2.  I used the same algorithm for my P1 and I can barely pass more than 30 Mbit across VPN.  My office has 1gbit up/down on C2758 supermicro with 8gb ram with aes-ni enabled on 2.2.6 Remote side is 1gbit in, 500mbit out.  Running 2.2.6 in Hyper-V.

The way IPsec works that isn't a viable option. Create them a second user/cert/etc to use for the mobile device. OpenVPN can work with the "duplicate connections" option enabled but it is still inadvisable. Using separate authentication credentials for each device is more secure.

Please try this setting: IPsec > Advanced Settings > Maximum MSS (Enable it and give the value 1250)

I'm used to have Bytes-In Zero, Bytes-Out OK problem. After enable Maximum MSS in IPsec > Advanced Setting and give the value 1250 solved my problem. Not sure whether the same setting can apply to your case.

And I'll say it. /15 and /16? Really? Hopefully you're subnetting those out to hundreds of sites.

There is no automatic setting to disconnect IPsec users. I've had one connected for quite a while. It's up to the client. The lifetime for Phase 1 and Phase 2 only specifies how often they should renegotiate the keys and such, it doesn't disconnect the user.

My understanding is you need to ad additional phase 2 for the other subnet

Dropping a note here, as I did in your other thread: It's definitely a problem. I put a fix in 2.3 for it. https://redmine.pfsense.org/issues/6010 It's a fairly simple change, it may apply to 2.2.x directly, if not it's still simple to apply by hand if it's a show-stopper for you, though they are processed correctly at boot time as far as I can see, so adjusting them via ifconfig after creation should be OK for the time being. 2.3 will be out before too long. :-)

@cmb: That's 'ipsec statusall', no space in between, but that likely isn't going to be telling in this case. What does the output of "setkey -DP" show when it's not working and when it is? I'm thinking there's an ordering issue of some sort there. ** ipsec statusall (ipsec conected after reboot, no LAN ping from LAN subnet) [root@vpn-gualeguaychu ~]# ipsec statusall Status of IKE charon daemon (weakSwan 5.3.3, FreeBSD 10.1-RELEASE-p24, i386):   uptime: 3 minutes, since Mar 17 14:45:02 2016   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3   loaded plugins: charon unbound aes des blowfish rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock unity Listening IP addresses:   181.xxx.xxx.xxx   10.85.30.1 Connections:   bypasslan:  %any…%any  IKEv1/2   bypasslan:  local:  uses public key authentication   bypasslan:  remote: uses public key authentication   bypasslan:  child:  10.85.0.0/16|/0 === 10.85.0.0/16|/0 PASS     con1000:  181.xxx.xxx.xxx...201.xxx.xxx.xxx  IKEv1 Aggressive, dpddelay=10s     con1000:  local:  [gualeguaychu@osprera.org.ar] uses pre-shared key authentication     con1000:  remote: [201.xxx.xxx.xxx] uses pre-shared key authentication     con1000:  child:  10.85.0.0/16|/0 === 10.0.0.0/8|/0 TUNNEL, dpdaction=restart Shunted Connections:   bypasslan:  10.85.0.0/16|/0 === 10.85.0.0/16|/0 PASS Routed Connections:     con1000{4}:  ROUTED, TUNNEL, reqid 1     con1000{4}:  10.85.0.0/16|/0 === 10.0.0.0/8|/0 Security Associations (1 up, 0 connecting):     con1000[1]: ESTABLISHED 3 minutes ago, 181.xxx.xxx.xxx[gualeguaychu@osprera.org.ar]…201.xxx.xxx.xxx[201.216.208.113]     con1000[1]: IKEv1 SPIs: 51f33f634aae57e2_i* 6761851f86de30b5_r, pre-shared key reauthentication in 7 hours     con1000[1]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024     con1000{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cbfd4079_i 046b1ec2_o     con1000{2}:  AES_CBC_256/HMAC_MD5_96, 273639 bytes_i (1235 pkts, 0s ago), 316104 bytes_o (1283 pkts, 0s ago), rekeying in 19 minutes     con1000{2}:  10.85.0.0/16|/0 === 10.0.0.0/8|/0 [root@vpn-gualeguaychu ~]# ** setkey -DP (ipsec conected after reboot, no LAN ping from LAN subnet) [root@vpn-gualeguaychu ~]# setkey -DP 10.0.0.0/8[any] 10.85.0.0/16[any] any         in ipsec         esp/tunnel/201.xxx.xxx.xxx-181.xxx.xxx.xxx/unique:1         created: Mar 17 14:45:29 2016  lastused: Mar 17 14:52:15 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=6 seq=3 pid=91411         refcnt=1 10.85.0.0/16[any] 10.85.0.0/16[any] any         in none         created: Mar 17 14:45:52 2016  lastused: Mar 17 14:45:52 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=10 seq=2 pid=91411         refcnt=1 10.85.0.0/16[any] 10.0.0.0/8[any] any         out ipsec         esp/tunnel/181.xxx.xxx.xxx-201.xxx.xxx.xxx/unique:1         created: Mar 17 14:45:29 2016  lastused: Mar 17 14:52:16 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=5 seq=1 pid=91411         refcnt=1 10.85.0.0/16[any] 10.85.0.0/16[any] any         out none         created: Mar 17 14:45:52 2016  lastused: Mar 17 14:45:52 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=9 seq=0 pid=91411         refcnt=1 [root@vpn-gualeguaychu ~]# then, ipsec stop, ipsec start: (ipsec conected, PING ok to LAN from LAN subnet) ipsec statusall [root@vpn-gualeguaychu ~]# ipsec statusall Status of IKE charon daemon (weakSwan 5.3.3, FreeBSD 10.1-RELEASE-p24, i386):   uptime: 12 seconds, since Mar 17 14:54:26 2016   worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3   loaded plugins: charon unbound aes des blowfish rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey ipseckey pem openssl fips-prf xcbc cmac hmac curl attr kernel-pfkey kernel-pfroute resolve socket-default stroke vici updown eap-identity eap-sim eap-md5 eap-mschapv2 eap-dynamic eap-radius eap-tls eap-ttls eap-peap xauth-generic xauth-eap whitelist addrblock unity Listening IP addresses:   181.xxx.xxx.xxx   10.85.30.1 Connections:   bypasslan:  %any…%any  IKEv1/2   bypasslan:  local:  uses public key authentication   bypasslan:  remote: uses public key authentication   bypasslan:  child:  10.85.0.0/16|/0 === 10.85.0.0/16|/0 PASS     con1000:  181.xxx.xxx.xxx...201.xxx.xxx.xxx  IKEv1 Aggressive, dpddelay=10s     con1000:  local:  [gualeguaychu@osprera.org.ar] uses pre-shared key authentication     con1000:  remote: [201.xxx.xxx.xxx] uses pre-shared key authentication     con1000:  child:  10.85.0.0/16|/0 === 10.0.0.0/8|/0 TUNNEL, dpdaction=restart Shunted Connections:   bypasslan:  10.85.0.0/16|/0 === 10.85.0.0/16|/0 PASS Routed Connections:     con1000{1}:  ROUTED, TUNNEL, reqid 1     con1000{1}:  10.85.0.0/16|/0 === 10.0.0.0/8|/0 Security Associations (1 up, 0 connecting):     con1000[1]: ESTABLISHED 12 seconds ago, 181.xxx.xxx.xxx[gualeguaychu@osprera.org.ar]…201.xxx.xxx.xxx[201.216.208.113]     con1000[1]: IKEv1 SPIs: 1d1e895fe7c58369_i* 0134c120391e748b_r, pre-shared key reauthentication in 7 hours     con1000[1]: IKE proposal: 3DES_CBC/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_1024     con1000{2}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c8dbde05_i 04d2c445_o     con1000{2}:  AES_CBC_256/HMAC_MD5_96, 17097 bytes_i (124 pkts, 0s ago), 30560 bytes_o (122 pkts, 0s ago), rekeying in 22 minutes     con1000{2}:  10.85.0.0/16|/0 === 10.0.0.0/8|/0 [root@vpn-gualeguaychu ~]# ** setkey -DP [root@vpn-gualeguaychu ~]# setkey -DP 10.85.0.0/16[any] 10.85.0.0/16[any] any         in none         created: Mar 17 14:54:27 2016  lastused: Mar 17 14:56:20 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=14 seq=3 pid=44444         refcnt=1 10.0.0.0/8[any] 10.85.0.0/16[any] any         in ipsec         esp/tunnel/201.xxx.xxx.xxx-181.xxx.xxx.xxx/unique:1         created: Mar 17 14:54:27 2016  lastused: Mar 17 14:56:19 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=18 seq=2 pid=44444         refcnt=1 10.85.0.0/16[any] 10.85.0.0/16[any] any         out none         created: Mar 17 14:54:27 2016  lastused: Mar 17 14:56:20 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=13 seq=1 pid=44444         refcnt=1 10.85.0.0/16[any] 10.0.0.0/8[any] any         out ipsec         esp/tunnel/181.xxx.xxx.xxx-201.xxx.xxx.xxx/unique:1         created: Mar 17 14:54:27 2016  lastused: Mar 17 14:56:20 2016         lifetime: 2147483647(s) validtime: 0(s)         spid=17 seq=0 pid=44444         refcnt=1 [root@vpn-gualeguaychu ~]#

Thanks for your reply. We upgrade from version 2.2.3 -> 2.2.6 Not at all. There is any rule in Firewall->Nat, Outbound tab for IPSEC Interface. As I said in the original post. This configuration was working perfectly BEFORE the upgrade. After that my counterpart at the other side of the tunnel start complain that I wasn't use the right IP Address to access his network. The problem was solved changing the Local Network config at phase 2, changing the subnet /29 just to a single IP address. We have to do it at both sides of the tunnel, ofcourse. The firewall at the other side of the tunnel is a Fortinet, and we had a hard time making the tunnel work in the past (with PFSense 2.2.3), but when it start to work it was rock solid. Looking at: 2.2.3 - release notes 2.2.6 - release notes I notice that StrongSwan upgrade from version 5.3.2 in PFSense 2.2.3 to version 5.3.5 in PFSense 2.2.6. Pheraps there is some change there.

Not really sure, but other thing to try….... CLIENTE IPSEC Phase 2 proposal (SA/Key Exchange) ONLY CHECK Encryption algorithms AES / Blowfish / 3DES / CAST128 / DES Hash algorithms ONLYE CHECK MD5 and SHA1 have to try it some more days...........

Check your outbound NAT and make sure you don't have a rule that might be catching the traffic (e.g. source = any)

Solved by adding multiple P2s, one for LAN, one for OPT.

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…