A quick question for ipfilter, pf and ipfw users.
How many of you use one of the firewalls (ipfilter, pf, or ipfw) NAT without firewall rules?
Seems everyone so far uses firewall rules with their NAT rules.
I came across a user who uses NAT rules only.
With ipfw you still should also have a rule that tracks state so that the TCP session remains in the window. Otherwise spoofed and injected packets can cause a DoS.As above, ipfw NAT (or natd(8) - I've used both) requires at least one ipfw rule to install NAT, and if packets don't match the NAT or DIVERT rule, ipfw's default rule (deny or allow) applies.
What was the user you mention using? Link please?
Nothing inherently wrong with that if a firewall indeed isn't needed (for whatever reason, maybe you're doing NAT somewhere inside some already protected network and decide that's sufficient....)I came across a user who uses NAT rules only.
Well, actually there is a problem with using NAT only.Nothing inherently wrong with that if a firewall indeed isn't needed (for whatever reason, maybe you're doing NAT somewhere inside some already protected network and decide that's sufficient....)
Of course that's kind of unlikely and instead just the old fallacy lurking that NAT would "protect" hosts behind it by not allowing connections to them. Which is wrong in general and just a common side-effect of how NAT typically works, that should never be relied on. I've even seen people wanting to have NAT with IPv6 "for security".
Implementation specifics aside, the key lesson should be that the goal of NAT is to route as many packets as possible to their correct destination (which might even include some heuristics), while the goal of packet filtering (what a firewall typically does) is pretty much the opposite: Make very sure only specifically allowed packets are routed.
One needs both. Applying a NAT rule without firewall rules may result in a DoS.cy@ I see no contradiction to what I wrote ...at least, I don't assume you're trying to tell that anything of this is worse with NAT, compared to a scenario without it (assuming it wasn't needed) and still no "firewalling"?
I'd really like to clarify that: Do you mean that NAT causes that issue? Compared to a scenario without any kind of "firewall" active?One needs both. Applying a NAT rule without firewall rules may result in a DoS.
I think he means "NAT without firewall rules allows the DOS".Do you mean that NAT causes that issue?
That's obvious. But would the same attack not work without NAT?I think he means "NAT without firewall rules allows the DOS".
NAT doesn't cause the issue. NAT without firewall rules does not check if TCP sessions are in the window. NAT simply translates IP addresses and port numbers regardless of the state of the TCP session.I'd really like to clarify that: Do you mean that NAT causes that issue? Compared to a scenario without any kind of "firewall" active?
Pretty much so. So there's indeed no contradiction, just a misunderstanding it seems. I tried to express exactly the same thing: NAT is not meant to "protect" anything (but an ugly workaround for having too few addresses available).I think this settles it.
I fall in the opposite category, only rules, no NAT - but it's an internal FW.A quick question for ipfilter, pf and ipfw users.
How many of you use one of the firewalls (ipfilter, pf, or ipfw) NAT without firewall rules?
Seems everyone so far uses firewall rules with their NAT rules.
I came across a user who uses NAT rules only. Seems someone (probably me) needs to write a handbook article or wiki page discussing correct NAT setup. Probably a good education opportunity.
# ipfw show | grep ngnat.locl
01785 166921 12368127 netgraph 2 // lan.locnat[FILTER][ngnat.locl.in]
02325 2711 427420 netgraph 2 // oper.locnat[FILTER][ngnat.locl.in]
04655 785 51536 netgraph 1 // [FILTER][ngnat.locl.out] INFRA.lan[49]
04765 0 0 netgraph 1 // [FILTER][ngnat.locl.out] INFRA.lan[48]
04885 314518 467620621 netgraph 1 // [FILTER][ngnat.locl.out] INFRA.lan[26]
05175 0 0 netgraph 1 // lan.locnat[FILTER][ngnat.locl.out]
05475 2717 254848 netgraph 1 // [FILTER][ngnat.locl.out] INFRA.lan[40]
05615 0 0 netgraph 1 // [FILTER][ngnat.locl.out] INFRA.lan[39]
05725 0 0 netgraph 1 // oper.locnat[FILTER][ngnat.locl.out]