The IPv4 case also works for us. With IPv4 the charon also creates packets bigger than 1500 bytes, but they get fragmented at the outgoing interface as they should and as seen in a interface dump. With IPv6 a dump on the same interface simply shows nothing for the packet in question…
That's why i suspect that pfSense does not do any fragmentation for IPv6.

No you don't.

10.2.0.0/16 <-> 10.5.0.0/16 is not the same thing as 10.2.0.0/16 <-> 10.1.0.0/16

Solved by removing the RRAS in between so now DHCP and NAT live on the PfSense firewalls. Thanks for the suggestion! Also no more 24.xxx subnets for private IPs!

Thanks for that confirmation that my memory isn't faulty. The issue is consistent and repeatable, so if I get the chance I'll dig around some. I'm going to be away for a few days though so that might take a while. And, if I run out of time, I may end up just building a new VM from scratch - this one has been through the wars while I was figuring out IPSec.

ps. As this is no longer related to IPSec, as such, and is more of a firewall issue, if/when I get around to updating or solving the problem then I'll post in the firewalls topic rather than here.

@Cerberus:

Update: If the windows 10 client has a public IP address it works!

This makes me believe it's a NAT problem. There must be a configuration error on the pfsense router, the win10 client and the pfsense router, does not agree on how NAT-T works.

Remember the same windows 10 client can successfully connect to another router via L2TP/IPsec when the client is behind nat.

This is working for me. I am using Win10 Home version 1709 build 16299.125 (KB4054517, Dec. 2017). There are 12 new builds, but I couldn't test them yet. If nothing got break this year, let's imagine it still works:

For Phase 1 authtentication, Win10 asks for AES-256 bits-SHA1-DH 20. Just added this algorithm and it worked.

For client behind a NAT, it was needed a register tweak:

include REG_DWORD key "AssumeUDPEncapsulationContextOnSendRule", with value "2", at "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\PolicyAgent".
(need reboot)

Hi guys!

I have the same problem. Do you have solution to this?

Thank you,

Peter

I can't comment on your specific case, but here are a few things I did (they may work for you, or they may make things worse!)…

system > advanced > networking > all hardware offloading options: tick (disable)
vpn > ipsec > advanced settings > enable maximum mss: tick
vpn > ipsec > advanced settings > maximum mss: 1400
vpn > ipsec > advanced settings > make before break: tick
vpn > ipsec > tunnels > edit phase 1 > disable rekey: untick
vpn > ipsec > tunnels > edit phase 1 > margintime: 60
vpn > ipsec > tunnels > edit phase 2 > pfs key group: off
vpn > ipsec > tunnels > edit phase 2 > automatically ping host: ip within remote subnet

Good luck, and take a backup first.

OK, thanks for that.

Are you aware of anything that will do what I'm after?

The following works for me after doing step 1

"test-user" Cleartext-Password := "XXXXXXXXXXXXXXX", Simultaneous-Use := "1", Expiration := "Jan 01 2020", NAS-Identifier == strongSwan

Framed-IP-Address = 172.16.9.254,
Framed-IP-Netmask = 255.255.255.0,
Framed-Route = "0.0.0.0/0 172.16.0.1 1",

Remember the Simultaneous-Use := "1" if your giving them a fixed IP.

https://forum.pfsense.org/index.php?topic=130715.0

Thnx for the tip.

For now I can ping to both sides (network devices like AP's).

i am still not able to ping windows hosts on the remote side. it looks like this problem:
https://superuser.com/questions/1087392/windows-firewall-blocking-ssh-to-secondary-subnet?noredirect=1&lq=1

The windows firewall is disabled. To be sure i've added the any to any rule but without success.

The ping is arriving on the remote side (LAN interface) but i think windows is not responding because the traffic comes from an different subnet.

isn't it easier to translate the traffic to the local subnet on both sides?

Of Course you right it is totally my mistake :) it should be in WAN2 ….. thanks a billion.

Well….I'm at a loss.

I'm now testing from hosts behind pfSense (vs between pfSense boxes themselves).

I thought I had a breakthrough when I found aes-ni disabled in Advanced but realized that was a troubleshooting tip here :)

MTU is back to defaults, no MSS clamping, using IKE2....

Both boxes also have OpenVPN tunnels to other boxes but the average load is like 1mbs.

Without the tunnel, I easily get 230-250mbs. With the tunnel (and new since my original post gig wan line) I get 30-50mbs. Xeon on one side* and SH-4860 on the other. Neither CPU spikes above 30-40%.

I tried recreating the P1 and P2 tunnels - no change.

I failed to mention... the Xeon is pfSense running as a VM on Proxmox 5. It's the only VM, the CPU type is host, it has 16gb of ram allocated and direct disk access. So it's basically as close to the bare metal as it can be. But if anyone has any tips related to Prox and aes performance, lay em on me!

I don't think the logs you posted are relevant to your issue, they seem to be discarded packets for expired connections or something else.

What side are you attempting to connect to and from? I didn't get that clear. The rules on your pfSense local side look fine. If you are trying to connect from the local side to the remote and it fails, it may be a misconfig on the Fortinet side

IPsec policies have routing preference over everything on the system (pretty much). If you create a tunnel with destination 0.0.0.0/0, the tunnel goes up and something is misconfigured, I guess you wouldn't get internet access at all instead of getting routed through the regular WAN.

Post your detailed configuration

@PhYrE:

DH group 5 and group 14 was tested as well but is not recommended.
Commentary on the DH groups is provided by:
  https://supportforums.cisco.com/t5/security-documents/diffie-hellman-groups/ta-p/3147010

This chart from strongSwan is a bit more informative and has better info than that post:
https://wiki.strongswan.org/projects/strongswan/wiki/IKEv2CipherSuites#Diffie-Hellman-Groups