I restarted the unit. The GUI reports "configuring IPSEC VPN.." and it took a lot of MINUTES to complete it... Connected via SSH during boot I see php-fm + php-cgi working a lot

I set the Ike to V2 now. There is no traffic yet. i have to check if this is running before i can proceed fight with the firewall and the routing i think.... but the child SAs tell me always the first 2 available connections that are enabled. and no matter which one. this time it shows only one, maybe the 2nd server on the other side is switched off i cleand the ip address out because its a public IP con1000: #236 192.168.33.61/32 Local: cd989838 Remote: 60c4ba15 xxx.xxx.xxx.xxx/32 Rekey: 2542 seconds (00:42:22) Life: 3472 seconds (00:57:52) Install: 128 seconds (00:02:08) AES_CBC HMAC_SHA1_96 IPComp: none Bytes-In: 0 (0 B) Packets-In: 0 Bytes-Out: 0 (0 B) Packets-Out: 0 when i disable this first two entries it shows me ( again i cleaned addresses out for being public, this time all ) con1000: #238 xxx.xxx.xxx.xxx/32 Local: c144a229 Remote: 549b87ca xxx.xxx.xxx.xxx/32 xxx.xxx.xxx.xxx/32 Rekey: 2892 seconds (00:48:12) Life: 3595 seconds (00:59:55) Install: 5 seconds (00:00:05) AES_CBC HMAC_SHA1_96 IPComp: none Bytes-In: 0 (0 B) Packets-In: 0 Bytes-Out: 0 (0 B) Packets-Out: 0 of course the remote addresses are different ones from the one before

Pfsense settings Internet Protocol: IPv4 Interface: WAN Authentication method: Mutual PSK Negotiation mode: Main My identifier: x.x133.66 Peer identifier: x.x96.242 Pre-Shared Key: Policy Generation: Default Proposal Checking: Default Encryption algorithm :AES 256bits Hash algorithm: SHA DH key group: 5 Lifetime: 28800 NAT Traversal: Disable Dead Peer Detection Enable: 10 seconds, 5 retries

You appear to be editing a mobile IPsec tunnel. That's not the same as what you're reading in the docs. For site-to-site tunnels, yes, Mutual PSK will show that field and button. For mobile IPsec, each user has their own key, so you add them on the Pre-Shared Keys tab.

@gribfk 1 show the phase-2 settings 2 show the output of the command ipsec statusall after the IPSEC connection is established 3 show the firewall rules on the VLAN10 interface 4 show the output of the command tcpdump -netti enc0 when trying to access the 172.16.0.0/16 network

Shameless bump... Any ideas very much welcome. It's odd that the same config works fine elsewhere. It's not the encryption engine as I can do 300Mbit between sites LAN to LAN. It's only when WAN is involved. Thanks, James

@viragomann Actually just did a reboot and it appears to be working now, thank you.

Did you restore a configuration to the second one that was from a different device? Those packages (ipsec-profile-wizard and aws-wizard) should be present in the default installation, but if you restore a configuration that didn't have the packages, they would have been removed.

Hi marcquark, Yes you are right, it is a MTU problem. Upgrading to 2.4.5 and using MTU and MSS clamp, fixed the problem.

still a issue....

It's odd for several reasons: This is a 50 bytes more overhead than your standard 1400 IPSEC payload, meaning this ISP is encapsulating my traffic somewhere along the path to the NIX and didn't increase the MTU on the carrier network to compensate for the loss in payload. When I encapsulate traffic, say I'm using VXLAN, or GRE, I also increase the MTU on the network equipment to keep the 1472 payload clean. The other two ISP providers I use seem to have this right since I can traverse my IPSec tunnel with 1400 bytes packet just fine. So ISP-3 either made a configuration mistake or there is a network equipment limitation along the path. The MTU seems to be set differently for incomming and outgoing traffic, which is not possible. I could access PFSense Site A from a host on site C - at 1400 bytes apparently - yet accessing PFSense Site C from a host on Site A was impossible untill I dropped MSS clamping at 1350. You'll admit this makes no sense, right?