@Piter-0 Hello! I have the same problem! If WAN 1 fails, I still can't connect to WAN 2! If I deactivate ipsec for a short time and then activate it again, it works over WAN 2 until next time!

@frog Not that I know. But if your subnets are successive you can state a larger subnet, which includes all or multiple at least. E.g. your subnets are 10.66.20.0/24 10.66.21.0/24 ... 10.66.29.0/24 10.66.30.0/24 So set you local network to 10.66.25.0/20, which includes 10.66.16.0 - 10.66.31.255. However, you will also have to configure the remote site accordingly.

Ok, I believe I've found the root cause and it was a misconfiguration. I have "Manual Outbound NAT" configured. This is to use a 4 address pool instead of the firewall's WAN address for NAT. So even though there was an wildcard "Auto Created Rule" for TCP port 500 (ISAKMP) using the WAN address, there wasn't a rule for the ESP protocol. I added a wildcard rule for ESP that used the WAN address last night, and haven't had any issues since. In retrospect, this makes sense, since each time I lost connection, the source address was one of the addresses in the pool. What doesn't make sense to me is that it ever used the WAN IP address. Like so many things, it would have been a lot easier to diagnose than a connection that always failed than one that sometimes worked. I think an argument could be made that if pfsense is going to add an Auto Created Outbound NAT rule for ISAKMP, it should probably create an Auto Created rule for ESP at the same time.

@keyser That worked perfectly! Thank you guys!

@CodingCharlie said in A valid remote gateway address or host name must be specified: Am trying to setup an IPSec VPN but get this error. I am putting in a remote gateway address so am confused. Is this a bug? Pretty many people here did this. So why should there be a bug? How did you configure the phase 1 exactly?

To answer my own question: https://forum.netgate.com/topic/148452/virtual-address-pool-in-pre-shared-keys-is-not-used-for-ipsec/9

@theshao in my case, maybe is also more complex: I'm simulating my tunnel future need, running one pfsense in an hypervisor, and the other one on a VM hosted on Azure. So a lot of things that maybe I haven't considered, like the NAT of my internet provider. I'll give a shot reproducing the setup with physical devices.

@viragomann It is set for the firewall to configure the rules automatically. Both links connect, as long as it is set as the default gateway. I have two gateway groups, where each link is primary and the other secondary and vice versa. At the other end I configured the connection via DDNS.

@fcostars Resolvido! Estava clonando configuração ipsec para não digitar tudo novamente e dessa forma o firewall se perde! Segue a dica! Nunca clone uma regra e sim reescreva novamente!

@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