Bug 244514
| Summary: | "reply-to" function in pf breaks RFC 1122 section 3.3.1.1 Local/Remote Decision | ||
|---|---|---|---|
| Product: | Base System | Reporter: | ctminime |
| Component: | kern | Assignee: | freebsd-bugs (Nobody) <bugs> |
| Status: | Closed Works As Intended | ||
| Severity: | Affects Some People | CC: | kp, pvz |
| Priority: | --- | ||
| Version: | Unspecified | ||
| Hardware: | amd64 | ||
| OS: | Any | ||
|
Description
ctminime
2020-02-29 03:36:58 UTC
(In reply to ctminime from comment #0) I forgot to mention that switch the commenting out between the 2 SSH rules. I don't have them both enabled at the same time. I'm sorry, but this is pf behaving exactly as documented and expected. pf has been configured to send replies via gateway 192.168.169.254 on vtnet0, and that's what it does. The administrator has defined policy for those packets, and that's that pf is for: enforcing network administrator policy. One could similarly argue that every block drop rule also violates RFCs (in that we don't send an error message for closed ports). Administrator policy trumps the RFC. If you don't want pf to send certain reply packets via gateway 192.168.169.254 on vtnet0 that can be configured. (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. (In reply to Kristof Provost from comment #2) I am re-opening this for a couple of reasons: 1. I don't think my previous reply was seen by Kristof (who closed this). 2. It was closed so fast it left NO room for others in the community to comment 3. One person should not be able to dictate weather something gets looked at. I ask that this be left open for at least a week for commenters. While, the feature may currently work as intended and documented, this could still be an improvement on the reply-to feature. And it is my personal opinion (and backed by RFC) the the behavior I outlined is wrong. If others think this should be addressed, great. Then it should stay open. If others think nothing needs/should be done. I will accept the "closed - works as intended". I have indeed seen your response. There was no need to reopen the issue for that. As I'm currently the only maintainer of pf in FreeBSD I don't expect much follow-up, but I'm happy to leave this open for another week. I will not work on it. (In reply to Kristof Provost from comment #5) I did not know there was only 1 maintainer of pf. So, thank you for entertaining my impertinence. Would you mind pointing out where the reply-to feature is in the source code? I am not a developer, but just in case someone else feels inclined to take a look. (In reply to ctminime from comment #6) There is no one place to look for this. Rules are parsed (at configuration time) by the code in sbin/pfctl, then passed to the kernel. The code in sys/netpfil/pf parses packets and decides what actions to take based on those rules. Relevant functions are pf_test() and pf_route(), PF_REPLYTO is a useful constant to look at. This is nontrivial code with subtle edge cases. I agree with the earlier comment by Kristof Provost. This is not a FreeBSD bug. pf is being told to route all reply packets back through a certain gateway, and that is in fact what it's doing. If the way the administrator configures FreeBSD violates an RFC, that's on the administrator. There are many ways to configure firewall rules that go counter to what's written in an RFC, if that's what you want to do. It is also conversely possible to configure PF rules that do not cause this behaviour, if that's what you want to do. If a project or system administrator that uses pf generates pf rules that end up violating an RFC, it's on whoever's or whatever writing the rules to write them differently. In this case the firewall rule is working exactly as intended. You might be able to argue that it would be useful for pf to have a feature that would route packets down a certain interface, as opposed to specifically through a specific gateway, but that would mean talking about introducing a new feature, rather than changing behaviour of an old one. I think it might be a good idea, but if you really want pf to do that, you can already do that by writing rules that handle same-subnet traffic differently to cross-subnet traffic, although it'd end up a bit messy. Incidentally, I agree with ctminime's core problem description. The way OPNsense and pfSense use this feature is bogus. But it has nothing to do with FreeBSD or pf. It's doing what it's being told, and pf should not second guess what the administrator is telling it to do. There may be good reasons to configure your firewall in that way. |
