ipnat.conf - map and rdr won't work!
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
More information about the freebsd-questions