It *should* only affect NAT, not any rules using connection tracking (aka "keep state"). So, if done right, you can filter in the exact same way as before, if you like. It should only change the behavior if all you have is a NAT rule.
Jose &
mickey, does this answer satisfy your objections? For sure I'm not in the mood to spend any thoughts & work into s/th that's not worth it.
Assuming it's worth going on: so this assertion would result in an external test, i.e. that goes into the CI
devel/kyua framework? E.g. create (clone) the necessary network interfaces, and use
netcat (
nc(1)) or such to test/verify/asure that packets pass (block, resp.) on a reasonable simple
pf.conf(5)? (& clean up after the test) Right? I don't see this could/should be tested/asserted internally in the code. Correct? Are there more appropriate tools to use other than
netcat? Preferably in
base?
Of course, with a simple configuration like from the handbook
Code:
block in all
pass out all keep state
you *expect* your firewall to block anything incoming except for direct answers to what's outgoing. If the patch would change this, it would be broken, no matter whether you use NAT or not.
But it's reasonable to expect something like
Code:
nat on tun0 from $internal_net to any -> (tun0)
to do a "best effort" approach of routing (by rewriting) as many packets as possible.
Dito. External tests?
Just had a look at the "goto"s introduced by the patch. They're fine, following your typical "goto cleanup"/"goto failed" idiom. A lot of C code needs this kind of goto for a clean and readable structure, possible alternatives are much worse.
Yes, I know. Nevertheless, I'll try harder to understand & verify that it's ok to leave out the skipped code.
I don't think it's that simple. My understanding is that the filtering rules are evaluated only if there is no matching state entry. And from what
pf.conf(5) tells, such states are created automatically from translation aka NAT rules:
Code:
TRANSLATION
Translation rules modify either the source or destination address of the
packets associated with a stateful connection. A stateful connection is
automatically created to track packets matching such a rule as long as
they are not blocked by the filtering section of pf.conf.
The interesting question is what does that mean with regard to
RFC4787 section 5 - Filtering behaviour? In particular the passage that states:
"Having the filtering behavior being an option configurable by the administrator of the NAT ensures that a NAT can be used in the widest variety of deployment scenarios."
So how would one go about - in the context of a
pf.conf(5) file - actually configuring the required filtering behaviour of the NAT? As I sure as hell want an
Address and Port-dependent Filtering for all intents and purposes.
IIUC the manpage
pf.conf(5) is unambiguous here:
"A stateful connection is automatically created [...] as long as [the packets] are not blocked by the filtering section of pf.conf." I.e., the
blocking filtering rules overrule NAT's packet translation. Again, we could/should create an external test (or set of tests) to ensure this? EDIT Yes, and additionally this could go into an code-internal assertion. My understanding is that the filters are applied 1st, then the NAT rules, then maybe additional filter rules? Are there such? In
ipfw(4), the rules are numbered. How is the ordering handled in
pf(4)? Or does the admin have to use
netgraph(4) to apply stacking of rules?/EDIT
Do you agree we should start with tests & assertions on the existing NAT? For sure we'll run into greenhorn traps; this would help to correct these, and we'll have an initial set of tests that will asure that the patch does not break the existing code. We can flag the tests that we think should be changed or disabled for the patch.