You can test in both ends if AES-NI is enabled by using openssl like in the following link.

https://calomel.org/aesni_ssl_performance.html

You also needs to enable AES-NI in pfsense in the system->advanced "cryptographic hardware acceleration" settings somewhere and reboot the unit.

Maybe the hyper-v isn't passing the AES-NI feature to its host so you can also check that. We had some issues getting hyper-v to work with AES-NI both after some updates and random luck we got it working but i can't guide you on what we did :D.

IKeV2 AES128-GCM or AES256-GCM for both P1 and P2 should be fine (until they mistakenly removes GCM option in P1 in pfsense 2.3 again :/ )

If you could post up your configs, it should make it a bit easier to troubleshoot.

Cheers.

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.