On Wed, 2 Jul 2003, Michael Sierchio wrote:
> No, no, honor is due, no need to forget it. I'm trying to grasp
> how to put it into practice. For example, you still use ipfw
> for traffic shaping. Have you done benchmarks with ipfilter+ipnat+ipfw?
Well yes; ipfilter + ipnat with a simple ruleset (like m0n0wall "factory
defaults") on a net4501 performed at about 17 Mbps last time I checked. If
you also load ipfw (i.e. enable the traffic shaper but without any rules),
it's 16 Mbps.
> And I'm a little unclear on processing order here -- can you help?
It's No Good [tm] - I already complained about this in a FreeBSD bug
report. ipfilter is always processed before ipfw, no matter if inbound or
outbound. That's the problem; I think it should be symmetric; the way it
is now, you always see already NATed packets in ipfw if you use ipnat.
That's of course OK for inbound packets, as you're probably after the
real/internal destination address, but for outbound packets, you can't
properly use ipfw to filter for the internal source address anymore - all
you see is the external IP on all packets.
I tried modifying the order in sys/netinet/ip_output.c, but then I had
problems with packets that escaped from a dummynet pipe - they weren't
passed to ipnat anymore. However, I now suspect it was because I moved the
"IpHack" (ipfilter) section after the IPFW but before the "pass:" label,
so it was skipped. Might be worth trying to move the IpHack section right
after the pass: label. That would make the order more sensible if you're
trying to traffic shape packets on WAN. If you do that, let me know if it
works with dummynet pipes on the interface where NAT is done.
> Just for grins, if I used ipfilter just for ipnat, and had my
> ruleset in ipfw??????
Then you'd probably have to reverse the processing order in ip_output.c as
described above, or you would have problems again with NAT. ipfilter
internally works in that way too (NAT before filtering for inbound
packets, and vice versa for outbound packets - that makes the most sense,