On Tue, 1 Sep 2009 17:12:37 +0200 Henning Brauer <henn...@openbsd.org> wrote:
> I have just committed a monster pf diff that is basically a rewrite of > the entire NAT part. > > seperate rules for nat, rdr etc are gone. > > nat and rdr become actions on regular rules. > > simple rulesets are converted like this: > > nat on $ext_if to ($ext_if) > becomes > match out on $ext-if nat-to ($ext_if) > > more complex rulesets require some thought. since the weird > difference in matching order is gone (nat/rdr were first match) you > might have to reverse things and use your brains :) > > the new NAT code is very very very flexible. every matching "match" > rule changes the adress on the fly (not really, but that is what it > looks like for subsequent rules), and you can nat or rdr multiple > times. for pass rules, only the last matching one matters. > > so given > match out on $ext_if nat-to 1.2.3.4 > match out on $ext_if to 1.2.3.4 nat-to 5.6.7.8 > both rules will match and 5.6.7.8 will be the new src address. > however, with > pass out on $ext_if nat-to 1.2.3.4 > pass out on $ext_if nat-to 5.6.7.8 > ONLY the second one matters for NAT. same semantic that match rules > have for a lot of other stuff (altq, rtable, log, scrub). > > the core logic, that relies on the big state table rewrite ryan and I > (with help from otehr developers of course) did last year, allows for > nat and rdr in any direction, but for now we prevent that in pfctl and > force nat outbound and rdr inbound, there are nontrivial implications > for the routing afterwards - if you rdr outbound, the packet will go > out on the interface it was seen on, even if the route for the address > rdr'd to actually points to a different interface. with NAT there are > similiar implications for the return traffic. since they are useful > nontheless I tend to remove the check in pfctl and document the > implications, but one thing after each other. > > the diff is over 3000 lines, and makes pf about 800 lines smaller > than it was before. more cleanup is possible on top of this, but as > said before, one step at a time. > > to add another data point how important hackathons are... this was > almost entirely written at c2k9 in edmonton and "finished" (minus a > few bugs fixed later) the week thereafter on bob's couch. while the > diff was almost entirely written by me, getting this actually into the > tree was a concerted effort by many developers. claudio adjusted > ftp-proxy, sthen ported that adjustment over to tftp-proxy, reyk > adjusted relayd. many people were testing a lot, I'm sure I forget a > few, but at least krw, sthen, claudio, reyk, dhill and dlg (who was > insane enough to throw this on production firewalls with significant > importance) helped a lot. igor did most of the manpage work. theo > helped getting it in, a lot. thanks guys. > > and now it is your time. test this as much as you can, to avoid > surprises in 4.7, and bugs showing up after release... we really want > to find them beforehands, right? > > henning > Henning and all, Fantastic Work! One question, is this in snaps now? Or should I wait a few days for new snaps? -jon -- J.C. Roberts
