Reply-to on WAN by default is bogus

[AdSchellevis]

You're free to find the correct paragraph in the rfc's which describes that you're not allowed to forward same net traffic to a specific host, which is what reply-to allows you todo (you likely are not going to find it in 802.3, which describes the ethernet layer, not the IP part).
By my knowledge reply-to on pf is implemented equally on both OpenBSD as FreeBSD, which likely isn't violating the rfc's, but then again, you're always free to prove otherwise (and ask upstream to fix it).

As stated multiple times, you can disable this behaviour, overwrite it for specific nets or protocols using your own rules, which you can all influence from the web interface. When designing such functionality from scratch, we might have chosen other defaults (which is the only thing we're talking about here).

Since changing this behaviour will influence people depending on the current one or adds a lot of additional complexity to guess which nets one wouldn't like to forward, these things are most likely not going to happen.

To write documentation, one doesn't have to be a developer by the way.

As always, feel free to propose useful additions, write documentation or when able, contribute code which helps all use-cases (not only your own).

Best regards,

Ad

 

[mimugmail]

Maybe it's worth to add a checkbox to interface config, with disabling reply-to for traffic from the same network.

This is the usual rules when WAN has 192.168.99.5 and WANGW is 192.168.99.1:

pass in quick on igb1 reply-to ( igb1 192.168.99.1 ) inet from {(igb1:network)} to {any} keep state label "d13e3b46e38dad18644ef0d12f2cfff7"

And when enabled checkbox change to:

pass in quick on igb1 reply-to ( igb1 192.168.99.1 ) inet from {(igb1:network)} to !{(igb1:network)} keep state label "d13e3b46e38dad18644ef0d12f2cfff7"

No idea if pf allows this syntax

[ctminime]

Ad, you are right it is not 802.3. It is RFC1122 (Requirements for Internet Hosts -- Communication Layers
). Specifically in section 3.3.1.1.

https://tools.ietf.org/html/rfc1122#page-47

My interpretation is that OPNsense's implementation of the "reply-to" feature appears to be overriding the local/remote decision as described in rfc1122 section 3.3.1.1.

"""
            (b)  If the IP destination address bits extracted by the
                 address mask match the IP source address bits extracted
                 by the same mask, then the destination is on the
                 corresponding connected network, and the datagram is to
                 be transmitted directly to the destination host.
            (c)  If not, then the destination is accessible only through
                 a gateway.  Selection of a gateway is described below
                 (3.3.1.2).
"""

In section 3.5  INTERNET LAYER REQUIREMENTS SUMMARY, "Use address mask in local/remote decision" is marked as "MUST".

I will go ahead and open up a bug when I have the time.

[ctminime]

Bug  #3952 has been submitted.

[AdSchellevis]

@ctminime As mentioned earlier, if you believe there would be a bug to report on pf, better do so at FreeBSD, which is where our kernel is derived from. 

[pv2b]

If we want to classify this as a bug, the bug exists in FreeBSD since forever. pfSense merely added a patch and we are no fans of non-standard OS modification unless they serve a higher purpose.

Any sane gateway will bounce the packet back to the destination, otherwise a checkbox to fix it is really not too much to ask from a user perspective especially since talking about the behaviour is proof that the solution has already been found.


Cheers,
Franco

In that case OPNsense itself is not a sane gateway by your own definition. :-)

Consider the scenario where another OPNsense box is your gateway on your WAN. It receives a "reply" to a packet there there's on state. The stateful firewall will drop that packet on the floor rather than route it anywhere.

Also This is not an OS/FreeBSD bug. The OS is doing exactly what the firewall rule says. Any replies are sent back to the gateway on the WAN subnet. OPNsense is the one generating this firewall rule, and FreeBSD is simply doing exactly what the pf rule says to do (even if it doesn't make sense), so if the bug is anywhere, it's in OPNsense, not in FreeBSD.

[franco]

> In that case OPNsense itself is not a sane gateway by your own definition. :-)

Fair enough. I don't mind that much because we only try to curate a decision that was made by nobody who was ever involved in OPNsense.

The way this presents itself over the years is that "please don't break this" and "please change this" are mutually exclusive requirements by the same people loosely related in space and time.


Cheers,
Franco

[5SpeedFun]

I've been beating my head on the wall for 2 hours because a host in my "wan" vlan can't ping the actual pfsense firewall even though FW rules allowed it.  I literally just created an account to say "Thank you!" for posting about this!

Is this "reply-to" only on the "wan" interface & therefore avoidable by using/creating additional "opt" interfaces & ignoring the wan interface? 

[mimugmail]

You can just go to Interfaces : WAN and don't set an upstream gateway.
Easy ...

[Maurice]

I've been beating my head on the wall for 2 hours

Welcome to the club.

Is this "reply-to" only on the "wan" interface & therefore avoidable by using/creating additional "opt" interfaces & ignoring the wan interface? 

No, because if a gateway exists on an interface, this interface is considered a "WAN-type" interface and "reply-to" will be enabled.

You can just go to Interfaces : WAN and don't set an upstream gateway.

Eh?

[mimugmail]

Maurice, sorry, you are wrong
You can have 100 Gateways on LAN and set 200 Routes pointing to 100 different gateways.
The reply-to thing happens due to a auto pf rule set where an incoming packet will be replied via gateway in upstream gateway (DONT MIX THIS WITH UPSTREAM CHECKBOX UNDER SYSTEM:GATEWAYS:SINGLE )

[Maurice]

You're right. For static interfaces, reply-to is not enforced if the upstream gateway is set to auto-detect in the interface settings. Even if a gateway exists on that interface. I learned something today. Thanks!

But for DHCP interfaces, there is no such setting. Reply-to is always enforced (as long as a dynamic gateway exists on the interface).

And it is unrelated to which interface the active default gateway is on. If you have multiple DHCP interfaces with dynamic gateways, reply-to is always enforced on ALL of them. While on a static interface, reply-to is not enforced even if the active default gateway is on that interface. This is... confusing.

(And it doesn't matter whether it's the default "wan" or "opt1" or whatever. There is nothing special about the default "wan" (correct?). I think that was 5SpeedFun's original question. )

[mimugmail]

Maybe we can find a solution for 20.7 .. no promise

[alex.p]

I am in the club too. A lot of time has been wasted due to default reply-to setting.

[AdSchellevis]

https://docs.opnsense.org/manual/firewall_settings.html#disable-reply-to