[Bug 244514] "reply-to" function in pf breaks RFC 1122 section 3.3.1.1 Local/Remote Decision

[bugzilla-noreply at freebsd.org]

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244514

--- Comment #3 from ctminime at yahoo.com ---
(In reply to Kristof Provost from comment #2)
As far as I can tell, you are wrong about dropping packets violates RFC. I
couldn't find anything of the sorts in RFC 793 or RFC 1122. What I did find, is
some commentary in RFC 3360 under "The history of TCP resets". Go ahead and
read it yourself. However, if you you can find that in an RFC, I would be
interested to read it.

I can't think of a single way that making "reply-to" RFC compliant (by default)
would break any setup. It would only fix the couple of use case that it breaks. 

It is my personal opinion that the default behavior of a function should be RFC
compliant. Then it could be up to the administrator if he chooses to violate
RFC to accomplish whatever he wants.

It could be done like this: "reply-to" sends all traffic, except local subnet
traffic, to the gateway. (FYI, this is how pfSense behaves.) But if an
administrator wanted to, for some unfathomable reason, there could be an option
like "reply-to absolute" that would be specifically for violating RFC and send
all traffic to the gateway.

Just because this is the way it has worked for a decade+, doesn't mean it is
right or should stay that way.

-- 
You are receiving this mail because:
You are the assignee for the bug.