ipnat.conf - map and rdr won't work!

Erik Norgaard norgaard at locolomo.org
Tue Jul 20 19:27:10 UTC 2010

On 20/07/10 20.43, alexus wrote:
> On Tue, Jul 20, 2010 at 2:16 PM, Aiza<aiza21 at comclark.com>  wrote:

>> Just because 2 firewalls at same time didn't blow up in your face before,
>> sure don't mean they are working correctly. Thats one bad assumption to base
>> debugging on.
> i never had any problem doing so, not that i'm saying it's a smart thing to do
> i'm well aware of that, and as i mention before both firewall doing
> different purposes
> its not like i'm filtering packets with both firewalls at the same time.

You've never had a problem? Or maybe you didn't know:

Picture this: You've got two competing firewall solutions loaded at the 
same time. How do you know which one handles what? In fact, all 
firewalls comes with a default policy which is in effect if no rules are 

First, they are not consulted in parallel, just how would that work? 
maybe some sort of load balancing?

So, maybe both are consulted, but does that mean that if solution A is 
consulted first, then solution B only see what is passed by A? Or maybe 
it sees both what is passed and blocked with the power to change that? 
What about stateful filtering, if solution A creates a state and B don't?

Maybe only one of the solutions is actually consulted and the other one 
just hangs around without any effect?

Then how would you know which one is A and which one is B? If both are 
consulted you need to keep sure their rulesets are equivalent, or who 
knows what else might happen? And if only one, which one?

OK, so you say you use ipnat for redirect and map and ipfw for packet 
filtering. Even if we assume that ipfilter packet filtering capabilities 
does not alter the anything, then the next question would be does ipfw 
filtering take place before or after ipnat? Because you have to write 
your ruleset taking this into account.

Iirc, ipfilter wraps around the kernel and takes over all packet 
handling. That means that any other firewall solution you have 
"configured" that is more tightly integrated with the kernel just hangs 
around doing nothing. All that traffic shaping you've done have no 
effect at all.

So, you said, "but it worked".. or did it? Well, packets may get passed, 
some may get blocked, that's easy to check, but does it mean that 
everything works according to your "design"? You mentioned traffic 
shaping. Have you actually tested and shown that this takes place and 
works as expected?

Mixing multiple different firewall solutions is a recipe for disaster.

As for choice of firewall, chose one, whichever, but just one. It's five 
years since I switched from ipfilter to packet filter. I don't know if 
ipfilter is still actively developed, last time, last year I tried to 
find the source code for Solaris and only found dead ends. I recommend 
packet filter, it should have the traffic shaping capabilities you 

BR, Erik

More information about the freebsd-questions mailing list