Gave up trying to troubleshoot this, took out the branch office pfsense, and connected the same VPN direct from the 4G/5G router. Worked instantly...

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

Last outcome is that the Cisco admin will check every setting.
I told him to check if any ACL has a deny condition for the used subnets (e.g. overlapping) and he also should check if there is any typo in ACL naming.
Additionally I setup the pfSense to responder only to see what traffic selectors is coming from his side. I assume that he is not able to connect phase 2 because of a mistake on his side. We will see...

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!