"
For anyone running into something similar in the future, the fix was to check "Disable reply-to on WAN rules" in the firewall advanced settings. I didn't really consider this before, as the only interface on this box is configured as a LAN interface.
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Pages1
#1
General Discussion / Re: OPNsense as single interface VPN concatenator
September 07, 2022, 04:11:40 AM #2
General Discussion / OPNsense as single interface VPN concatenator
August 23, 2022, 08:12:50 PM
I'm trying out a new setup where OPNsense is used as a VPN concatenator as sorts, for a bunch of site to site IPsec tunnels. Due to how the network topology currently is, OPNsense resides within the LAN behind our existing firewalls and routers. It therefore has a single interface, the LAN interface (IPv4 only, 42.243.222.243), with the appropriate ports/protocols forwarded to it for IPsec to function.
This all actually works great (tunnels up, traffic flowing over them fine) minus one issue that I can't seem to figure out yet - outbound traffic (IE: update checks, try pinging anything from the shell, try curl to https://google.com, etc) from OPNsense itself to anything else (even things in the same LAN subnet) doesn't work. If I focus on the simple ping not working, packet captures reveal the following:
1) The ICMP echo request makes it to the proper destination, with all proper headers (source, dst MAC/IP).
2) An ICMP echo reply comes back to OPNsense, with all the proper headers (source, dst MAC/IP).
3) OPNsense then for some reason forwards this packet to the LAN default gateway, even though the packet is destined to its LAN MAC and IP.
4) The TTL eventually expires because the gateway sends the packet back to OPNsense, OPNsense sends back to the gateway, etc.
The routing table on OPNsense looks like this:
I'm at a loss to figure out why OPNsense would be forwarding reply traffic destined to itself to the gateway. I disabled the force gateway option in the firewall advanced settings to no avail. I've also tried various no NAT rules, but similarly no impact.
This all actually works great (tunnels up, traffic flowing over them fine) minus one issue that I can't seem to figure out yet - outbound traffic (IE: update checks, try pinging anything from the shell, try curl to https://google.com, etc) from OPNsense itself to anything else (even things in the same LAN subnet) doesn't work. If I focus on the simple ping not working, packet captures reveal the following:
1) The ICMP echo request makes it to the proper destination, with all proper headers (source, dst MAC/IP).
2) An ICMP echo reply comes back to OPNsense, with all the proper headers (source, dst MAC/IP).
3) OPNsense then for some reason forwards this packet to the LAN default gateway, even though the packet is destined to its LAN MAC and IP.
4) The TTL eventually expires because the gateway sends the packet back to OPNsense, OPNsense sends back to the gateway, etc.
The routing table on OPNsense looks like this:
Code Select
ipv4 default 42.243.222.194 UGS NaN 1500 vmx0 lan
ipv4 42.243.222.192/26 link#1 U NaN 1500 vmx0 lan
ipv4 42.243.222.243 link#1 UHS NaN 16384 lo0 Loopback
ipv4 127.0.0.1 link#3 UH NaN 16384 lo0 LoopbackkI'm at a loss to figure out why OPNsense would be forwarding reply traffic destined to itself to the gateway. I disabled the force gateway option in the firewall advanced settings to no avail. I've also tried various no NAT rules, but similarly no impact.
Pages1
