WAN Reply-To... Still causing headaches 4 years later...

Started by davidsenk, April 23, 2024, 10:28:53 PM

Previous topic - Next topic
This is a continuation of this thread https://forum.opnsense.org/index.php?topic=15900 started in February 2020


This reply brings up RFC 1122, specifically this section: https://forum.opnsense.org/index.php?topic=15900.msg73251#msg73251


   3.3  SPECIFIC ISSUES

      3.3.1  Routing Outbound Datagrams

         The IP layer chooses the correct next hop for each datagram it
         sends.  If the destination is on a connected network, the
         datagram is sent directly to the destination host; otherwise,
         it has to be routed to a gateway on a connected network.

         3.3.1.1  Local/Remote Decision

            To decide if the destination is on a connected network, the
            following algorithm MUST be used [see IP:3]:

            (a)  The address mask (particular to a local IP address for
                 a multihomed host) is a 32-bit mask that selects the
                 network number and subnet number fields of the
                 corresponding IP address.

            (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).


It appears that opnsense / pfsense / FreeBSD all want to default to sending packets only replying to the upstream gateway on all packets received by interfaces with a defined upstream gateway.

Good, bad, or indifferent on your feelings about how opnsense handles this... it appears that opnsense does not follow the RFC correctly.

Instead of trying to argue over the fact that "this is how x does it," that's completely irrelevant to me.

I would like to propose a compromise solution that does not involve changing default settings and possibly upsetting anyone that relies on this "reply-to" default in opnsense.

Would it be possible to add something to the WebGUI help text, maybe in the WAN firewall rules? Maybe on the WAN interface? My only opinion on it is that it should be somewhere obvious on a page commonly used, and not buried somewhere in... Firewall -> Settings -> Advanced (which, yes, of course, was the "last place I looked," and only happened to find it, because of the original thread from 2020!)

This is extremely unintuitive from my (and seemingly others) understanding of how networks work. I totally understand that this is a default in opnsense and has been for many years. I get it. I'm not trying to change that.

I just want to make "future me's" life easier, and a little "Hey, it looks like you're trying to allow connections in on the WAN? Might they happen to be from the WAN subnet? You may need to change your reply-to settings!" - Clippy might be helpful in saving time, for those, who like me, spend hours of troubleshooting... just to find out it's this setting.

I'll even put the whole PR together myself if I can get *someone* from opnsense to agree that adding the help text to the UI is acceptable!

Edit: This thread also calls out the issue: https://forum.opnsense.org/index.php?topic=8833.0

Long story short pfSense made a custom FreeBSD patch many many years ago but it was never added to FreeBSD.

I don't want to argue the ups and downs of sticking to a vanilla FreeBSD behaviour here.

If anyone has a better idea PRs are open even after 4 years. The lack of proposed solutions speaks for itself IMHO.


Cheers,
Franco

Hi Franco,

I'm not suggesting a change to the default.

I would like to add help-text to the web GUI in a few places, and maybe even update the online documentation to better clarify the default behavior, and why it may need to be turned off.

I totally understand that this is how FreeBSD, pfSense, and opnsense have behaved for years.

Ok, no problem.

Best to start with the docs then before we discuss help text nuances for individual options.


Cheers,
Franco