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?

I solved the issue. It's available using GUI.

@jauintm said in IPSec Site-to-Site VPN behind ISP modem: SG-2100(Private IP, 192.168.x.x on the WAN) Hi, Why are you using dual-NAT? can you put the modem(ISP) in bridge mode? otherwise it may be a solution: NAT Traversal - IPSec over NAT f.e.: http://www.internet-computer-security.com/VPN-Guide/NAT-T.html

I ran into this and had created my own post https://forum.netgate.com/topic/157561/aws-vpn-to-pfsense-w-cert-based-auth-how-to-configure-peer-identifier-for-cn/2 but I found the answer through testing and think it would work for you too. On the pfSense side, for the Phase 1 peer identifier set the type to ASN.1 distinguished Name and the value to CN=vpn-07633023bf21e2c62.endpoint-1 (just using the example in your post, I assume in reality you haven't left a broken VPN running in AWS all this time and now you would have a different endpoint name) and try connecting the tunnel.

@HF1086 I'm going to try some more packet captures tonight to see what I can find. I also went and bought a Nighthawk R7000 today and got set up to try tonight. I confirmed that on both the old 4000 and the R7000 NAT-transversal is enabled by default, and they don't even have an option to configure it in the VPN settings. Sorry if I repeated some info here from earlier. I've been running around like crazy today and this has been adding a ridiculous amount of stress over the last few days.

@eustachy said in NAT: port forward over Routed IPSEC (VTI): PS> I will disable all config, and try the same config with routed VTI and this setup: https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/accessing-firewall-services-over-ipsec-vpns.html Hi! I'm facing a similar problem on my setup (described here: https://forum.netgate.com/topic/157265/port-forward-through-site-to-site-vpn ). I would like to know if you finally succeeded in passing a port forward via IPsec routed VTI and, in case, if you could share your configuration. Thanks in advance, Edoardo

@Konstanti Thanks for that, yeah currently I am using OpenVPN Tap with interface bridged as I mentioned in my post. However it is not stable. I tried Open VPN client on pfSense but ping can drop a lot so I tried OpenVPN client on Win2016 server and found that Windows client is better but still unstable. That is the main reason why I started looking GIF tunnel option. Since psSense to pfSense IPSec tunnel is very stable I think it is not bandwidth issue. Thanks for your advice. Regards

Unfortunately not. I'm baffled that IPsec Mobile does not have any integration features towards Radius to allow for firewall rules separation. It must truely only be meant for Site-to-Site.... with Mobile User being a "bolt on" that really only has Site-to-Site features.

Found out the cause. ISP was suddenly blocking the connection for no apparent reason.

OK, thanks. As far as I can tell, the suggested settings are: Enable 'Make-before-break' (VPN-->IPSec-->Advanced Settings tab) on both sides OR - Disable reauthentication and enable rekey - Version 2.5.0: Leave reauth blank and put a value in rekey Version 2.4.5: Check 'Disable Reauth'. Leave 'Disable Rekey' unchecked On one side, Check 'Responder Only', and set 'Child SA Close Action' to 'Close/Clear' On the other side, set 'Child SA close action' to 'Restart/Reconnect' This patch would need to be applied to allow VTI tunnels to be set to Responder Only Is this correct? How would I apply these settings to an IPSec tunnel to AWS?

@johnpoz said in PCI Compliance Scans: Ok I see what might be going on... Hmmm I just fired up a ipsec, and ran ike-scan on it.. And yeah so you can see where asking for des. and what gets returned Oct 3 21:11:46 charon 10[CFG] <1> configured proposals: IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/3DES_CBC/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512_256/HMAC_SHA1_96/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048, IKE:AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/PRF_HMAC_SHA1/ECP_256/ECP_384/ECP_521/ECP_256_BP/ECP_384_BP/ECP_512_BP/CURVE_25519/MODP_3072/MODP_4096/MODP_6144/MODP_8192/MODP_2048 Oct 3 21:11:46 charon 10[CFG] <1> received proposals: IKE:3DES_CBC/HMAC_MD5_96/PRF_HMAC_MD5/MODP_768 All of the options are returned, even though not possible to use it... Hmmm That should be simple enough to fix, but don't think you can do it in the gui. I don't really ever do ipsec with pfsense... I don't either, but my client has a vendor that needs to occasionally access some internal systems. The only thing they could get working on their end was IPSec. SMH.

The original link is broken. Here is a new one. https://www.hexnetworks.com/2019/04/24/pfsense-cluster-in-aws/

No, I don't know that anyone has tried it so I can't offer any advice. You'd build it between the VTI addresses on either end of the IPsec tunnel but that's the only advice I can offer.

Yep, tried that too. To solve the problem, I just removed pfSense from site A and replaced it with a CentOS VM running OpenVPN client. From there I have a VLAN on our Cisco LAN SW which has a DHCP scope to configure the LAN default gateway via OpenVPN. Works perfectly.

Well, I finally made it work thanks to @Konstanti . I want to leave it here in case it may help someone else, struggling with the finicky ipsec settings... In my case the key point seems to be setting IKEv2 Algorithms as aes256-sha256-modp1024 in the StrongSwan Android Client. The IPsec/ESP Algorithms may be left empty. I am just not sure what the benefits of specifying it ( @Konstanti , please correct me). There is still another part that seems equally contibutes into the successful establishment of the IPSec tunnel - I also had to specify in StrongSwan Android Client: Server identity: <MY_ORG>.duckdns.org Client identity: ikev2-drew@<MY_ORG>.duckdns.org Note, that setting client identity (at least in my case) MUST be specified in this email style: client1@<SERVER_IDENTITY>. For some reason, changing it to just client1 (ikev2-drew in my case) breaks everything, even though I canged the User distinguished name from ikev2-drew@<MY_ORG>.duckdns.org to Any in pfsense ipsec settings (phase1) in GUI. Again, thank you very much, @Konstanti for your time and help!