Requesting comments for FreeBSD pf bug report for "reply-to"



  • I hope this is OK posting here. If not, I'm sorry.

    I recently opened up a bug with FreeBSD regarding how the "reply-to" feature violates RFC. It was immediately closed as "works as intended". I re-opened it requesting that it be left open for a week or more for commenters. How pfSense implements the "reply-to" feature in pf, does it correctly and doesn't violate RFC. FYI, reply-to is enabled by default.

    Anyway, I am really just hoping to get some backing for something that has been wrong for a long time and is currently being refused to be addressed. It is a little bit of a rabbit hole.

    Bug report is here:
    https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244514

    More info here:
    https://forum.opnsense.org/index.php?topic=15900.0
    and here:
    https://github.com/opnsense/core/issues/3952


  • Rebel Alliance Developer Netgate

    The rules do as they're told, like the FreeBSD team member stated. reply-to is an optional behavior that must be explicitly enabled, so it doesn't affect the behavior of pf on its own with regular rules. It's working as it was designed to work with rules which enable the feature.

    Trying to add more logic in there would slow things down for pf. It would have to do several extra operations per match to compare the source to the interface subnet(s) and it could still get it wrong. pf doesn't really know about host routing, so it doesn't necessarily know or care what is locally attached or directly reachable on an interface. So it's up to the admin to form rules which don't break their own routing. It would add a ton of overhead for little benefit, so I can understand why the maintainer is reluctant to take on that work.

    The best fix is to set rules for the interface subnet(s) or any locally attached networks and in those rules, check the box to disable reply-to. Then allow reply-to to work naturally on the other rules that follow.

    We have experimented with code to setup rules automatically in that manner in the past, but it was never quite viable to handle in that way, since it would have to automatically setup rules for the interface subnet, VIP subnets, static routed subnets that don't use the default gateway, etc. Lots of room for error compared to the admin managing their exact needs.

    For the vast majority of pfSense users, WAN type interfaces have no other hosts directly connected in that segment, so the behavior is optimal as-is. There is also a global option to disable reply-to if you don't ever want the behavior. The only thing we're really missing is an option to manually force reply-to on with a specific gateway, but that's not related to this issue really.


Log in to reply