Messages

Did you see my post from last week? https://forum.opnsense.org/index.php?topic=20868.0

Thanks, I hadn't seen that.

My results are different from yours, though.  I already had the gateway and static route setup that you added later, but I didn't have the outbound NAT (because I hadn't needed that when doing this with pfSense).  After adding the outbound NAT, I'm able to ping from the router through the tunnel — even if I disable the gateway and static route!  It seems the NAT is all that's actually needed for that.

So ping works now, but other services still don't.  I'm testing HTTP by running "fetch" on the router like you did, as well as DNS because I have unbound configured to relay queries for the other zone to the other router.  Both of those things time out.  In the firewall live view, I see the outbound request in green, on the WAN interface but with the router's LAN IP as the source (strangely)... but no replies, not even in red.  For pings, I see the WAN-but-LAN-IP request, followed by a pair of loopback packets with 127.0.0.1 as the source and the router's LAN IP as the destination — I guess that's a result of the NAT?  But for HTTP and DNS, those loopback packets don't appear.

(I should add that the remote router has an allow-all firewall rule for traffic from my network, and this stuff worked with my old pfSense router, so I don't think the traffic is being blocked at the remote end.)

I've tried changing that "disable force gateway" setting in the advanced firewall settings, but HTTP and DNS don't work with either setting.  I've noticed that it affects the timing of pings, though:

* With "disable force gateway" turned OFF, ping responses take a full second but the output shows unrealistically short times (around 0.2 milliseconds), and the last packet is always lost.  It seems as if there's a single-packet queue in effect, so response 1 doesn't arrive until request 2 is sent, response 2 doesn't arrive until request 3 is sent, and so on.

* With "disable force gateway" turned ON, ping works normally: responses take a few milliseconds, and none are lost.

I'm wondering about that outbound NAT rule, btw: if it matches packets addressed to the remote network, and NATs them to the router's own LAN IP, doesn't that mean my router is really just pinging itself by mistake?

I recently replaced a pfSense router with one running OPNsense, and I have an IPsec tunnel to another network (whose router still runs pfSense, though I doubt that matters here).  The tunnel is working: from computers on my LAN, I can ping IPs on the remote LAN using their private addresses.

However, I can't ping the other network from the router itself.  Only from other computers on my network that communicate through the router.

I encountered the same problem back when I was running pfSense, and resolved it using the workaround documented here: https://docs.netgate.com/pfsense/en/latest/vpn/ipsec/access-firewall-over-ipsec.html — in short, create an unmonitored gateway on the LAN interface using the router's LAN IP, and add a static route to the remote network through that gateway.

I've set up the same thing in OPNsense, though, but it doesn't seem to work: pings to the other network from the router still don't get any replies.  Looking in the firewall log's live view, the ping attempt shows up with the router's WAN IP as the source and the remote LAN IP as the destination, which is the default behavior that the static route is supposed to change.  (The firewall log shows the traffic as having been passed, which isn't surprising since this is a routing problem, not a firewall problem.)

Has anyone else done this sort of thing?  Is there a configuration step that I'm missing, maybe something that wasn't needed in pfSense?  I'm new to OPNsense so I don't know whether this is an actual difference between the two systems, or if it ought to work and I'm just doing something wrong.

I recently replaced a pfSense router with OPNsense, and had some difficulty setting up an IPsec tunnel that had worked in the past.  The reason turned out to be a difference in how the phase-1 KeyID tags are handled.  I'm posting this in case anyone else has the same problem.

The remote router runs pfSense 2.4.5.  My local router was running pfSense 2.5 until recently, and I had a working IPsec tunnel between the two.  The tunnel's phase 1 was configured to use KeyID tags for both ends: for the sake of example, let's say my local KeyID is "earth" and the remote one is "moon".  (I actually use different tags, but the specific strings aren't what's important.)

I replaced my local pfSense router with one running OPNsense 21.1, and configured the IPsec tunnel with the same settings I'd been using in pfSense, but the tunnel failed to connect.  Looking in the logs, the IPsec log on my end ended with:

Code Select Expand

09[ENC] <con1|17> parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
09[IKE] <con1|17> received AUTHENTICATION_FAILED notify error

And on the remote pfSense router (I have admin access via SSH tunnel), the log said:

Code Select Expand

09[CFG] looking for peer configs matching 192.168.1.127[moon]...203.0.113.1[earth]
09[CFG] no matching peer config found
09[IKE] received ESP_TFC_PADDING_NOT_SUPPORTED, not using ESPv3 TFC padding
09[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]

In the above, I've replaced my actual WAN IP with 203.0.113.1 (an RFC 5737 example address).  The remote router is behind a NAT, which is why its log shows 192.168.1.127 instead of its WAN IP.

Initiating the connection from the remote end had the same result, just in reverse: it was my local router that said "no matching peer config found" instead of the remote one.

Searching the web, I found that when other people have this problem, it's usually because they're using "my IP address" as the identifier, but the router is behind a NAT so the IP it sends doesn't match what the other side sees.  In my case, that's a red herring: the remote router is indeed behind a NAT, but I'm using KeyID strings instead of IPs, specifically to avoid that problem.  The configuration had worked when both sides were running pfSense.

After a lot of searching and trying various things that didn't help, I looked at the underlying config files on both routers and found the problem.  On my local OPNsense router, the IPsec configuration (in /usr/local/etc/ipsec.conf) had the lines:

Code Select Expand

leftid = earth
rightid = moon

But on the remote pfSense router, the configuration (in /var/etc/ipsec/ipsec.conf) said:

Code Select Expand

leftid = "keyid:moon"
rightid = "keyid:earth"

The "keyid:" prefix is not something I'd ever typed.  On both ends, in the web GUI I'd chosen "KeyID tag" from the dropdowns, and typed "earth" and "moon" in the text boxes.  But pfSense prepends "keyid:" to the strings in the ipsec.conf file, and OPNsense doesn't.

Based on that, I went to the tunnel settings in the OPNsense web GUI and added the "keyid:" prefix to the values there.  That doesn't seem like it ought to be necessary — I've already chosen "KeyID tag" from the dropdown, so it's redundant to have to write "keyid:" in the box below it — but it made ipsec.conf values match what pfSense uses.  And with that change, the tunnel worked.

It looks like this behavior is something that's recently changed in pfSense: see https://redmine.pfsense.org/issues/9243 and https://forum.netgate.com/topic/153068/keyid-tag-issue-since-2-4-5.  It sounds like there can be problems in some cases with not having the "keyid:" prefix, but I don't have experience with other IPsec implementations so I don't know whether the prefix is commonly used.

(Footnote #1: Actually, the log messages on the pfSense side originally showed something called "bypasslan" being selected, instead of saying "no matching peer config found", followed by some messages about bypasslan being rejected as unacceptable before sending the AUTH_FAILED response.  I turned off "auto-exclude LAN address" under the IPsec advanced settings to make it stop using bypasslan, to rule that out as a potential cause of the problem.)

(Footnote #2: The IPsec log on the remote pfSense side also includes a line that says "received 1 cert requests for an unknown ca", because OPNsense apparently sends a certificate even when using PSK authentication for the tunnel.  For awhile I'd thought that might be the cause of the problem, since it was the only obvious discrepancy from when my local router used to run pfSense, but it turns out to be harmless.)