@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?

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.