WAN with DHCP routing not working: always uses gateways's MAC

[Otto Frauchiger]

The WAN IF of my OPNsense is connected to a network using 172.16.20.0/24. The OPNsense gets its WAN IP through DHCP. On the WAN network there are other OPNsense firewalls. I can ping the gateway and the gateway can ping the OPNsense. If I want to ping the OPNsense from another OPNsense, the packet capture on the "pinged" fw records the echo request and the response. The request uses the correct MAC addresses in the ethernet packets but the response uses the gateway's MAC as destination even though there is no routing through the gateway needed.

If I assign the IP address static and set the gateway to Auto-detect it's OK. If I manually select the 172.16.20.0's gateway, I have the same behavior as described above.

To me this looks like a bug because the OPNsense should never use the gateway's MAC within the sub net - especially in DHCP mode where I have no workaround.

It's fairly easy to reproduce and I have seen this already in older releases.

I might find a work-around using extra Virtual IP addresses for the communication between the two OPN sense units but nevertheless this can be rather difficult to find in cases where there are several devices on the WAN.

Does anybody have an idea how to proceed ?

[Maurice]

Bug, or not bug, that is the question:
https://forum.opnsense.org/index.php?topic=15900.0
https://github.com/opnsense/core/issues/3952

(Summary: Disable reply-to on WAN rules in the advanced firewall settings. There is no consensus whether or not this should be made the default.)

[Otto Frauchiger]

Thank you Maurice for the help.

Here is my consideration why I think that at least the default setting for WAN as DHCP client is wrong:
I have worked with security VoIP equipment for quite a while with many cases of firewalls and/or SBC's behind firewalls. One of the rules we always applied, is that the packet filter was only open for replies that came exactly from the destination MAC address. Ergo, even if the gateway is stateless and returning the packet (which in my case is an other firewall), the sender would still discard it.

[Maurice]

I agree. But it seems that a final decision not to change the default has been made.
The only thing we can do now is help out others who encounter the same issue.