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 (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.
Quote from: Wyzard on March 21, 2021, 04:53:24 PM
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 (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.
Did you see my post from last week? https://forum.opnsense.org/index.php?topic=20868.0
Quote from: miken32 on March 22, 2021, 07:11:35 PM
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 used an other way and - at least - unbound reaches other DNS servers over IPsec.
1. Firewall: Settings: Advanced
check Disable force gateway
2. System: Gateways: Single
setup gateway for LAN interface with LAN IP address
3. System: Routes: Configuration
setup route for remote network using the gateway above
Cheers,
proctor