@viragomann OK this is great news, thanks for testing this, I hadn't had a chance to do that yet, helps a ton!

I figured it wouldn't interrupt anything, or at least not for long at all, but incredibly nice to confirm it.

Netgates official documentation for pfSense is the place to start, they have tons of configuration examples that go over things like this.

However, it's worth noting that it may be easier to setup (and more important easier to setup securely) WireGuard instead of IPsec for this use case, I use WireGuard for remote access and it's been basically perfect.

The big thing with IPsec is that it's really complex, overly so (and this is coming from someone who knows the ins and outs of IPsec very well and has setup an absolute ton of VPNs with it); so it can be hard to get working if you're knew to it and even harder to make properly secure, so if you go the IPsec route make sure you really understand it and be thorough, it's easy to make a big mistake.

But again, I'd first encourage using WireGuard for remote access VPNs, unless you need to manage things at scale or have a reason to use IPsec, it would be my choice, I've even used it in corporate settings and it's been extremely reliable.

This was a self-inflicted wound. Somehow I had inadvertently deleted the ISRG Root X1 CA cert. Importing the cert solved the problem. Obviously I should have paid more attention to what the log message was telling me!

no issuer certificate found for "C=US, O=Let's Encrypt, CN=R3" issuer is "C=US, O=Internet Security Research Group, CN=ISRG Root X1"

--Larry

Hello All,

I am having exactly the same issue but when I enable or disable this check box at VPN IPSec Advanced I am still not able to use ssh or http/https. Any other ideas?

Thank you in advance.

@mcury Thank you, I'll go through that page and see if anything helps.

I appreciate it!

@freddy550
No. Your IPSec configuration has to be aware of the NAT, otherwise it will not connect.

Imagine, the remote site is 192.168.20.0/24 and it is natted to 10.227.56.0/24. So your phase 2 has to use 10.227.56.0/24 as remote network to connect to.

@NOCling Greetings, thank you very much for the tip, I will test it and report it here, thank you very much

Hello,
I found the solution myself.
I went into the configuration of phase 1 of my tunnel and once the configuration was saved I had the button at the top right to launch the service.

So I can ping from the remote side to the local side but return packets don't get back and for some reason are routed normally (ie out to the internet/default route).
Not sure why pfSense is routing packets incorrectly though unless I'm missing some setting.

Laughs! A post from 4 years ago managed to get me out of a problem I was having. Thank you very much! 😊

@jimp OK, thanks, makes sense.

But it might be helpful to do either of these two things:

allow the use of PSKs defined there in regular IPSec configurations rename the tab to something like "Mobile Pre-Shared Keys" or something similar, that makes it clear, that these are not intended to be used for regular IPSec setups

because otherwise, it's a bit confusing...