Filter/NAT order
Rick Byers
posted]
Just out of curiosity, what is the motivation for doing NAT before
filtering incoming packets? Its seems a little strange that "block in on
ppp0 from any to 192.168.0.0" blocks all incoming packets for my internal
machines using NAT even though tcpdump shows the packets as having dest.
of my external IP. I.E. I think of NAT as processing of the packet, and
filtering as taking place before the kernel sees the packet...
I guess its not a big deal since the only machine that should be able to
get packets to me with a dest. of 192.168.* is my ISPs router. But still,
shouldn't it be possible to block packets that have an explicit internal
destination seperately from packets that have been translated to
point to an an internal address?
Thanks,
Rick
Mipam
> Just out of curiosity, what is the motivation for doing NAT before
> filtering incoming packets? Its seems a little strange that "block in on
> ppp0 from any to 192.168.0.0" blocks all incoming packets for my internal
> machines using NAT even though tcpdump shows the packets as having dest.
> of my external IP. I.E. I think of NAT as processing of the packet, and
> filtering as taking place before the kernel sees the packet...
Tcpdump looks on bpf, so before ipf is doing anthing and therefore
seeing packets with dest addr as your external ip.
Seen from outside->inside, on incomming packets,
first nat, second filtering takes place. So if you block all packets with
dst address 192.168.0.0/16 and that happens to be the ip range for your
internal nw, all incomming traffic will be dropped.
Ipf handles the packets before the ip stack does, so the ipstack will
only receive the packets only when they're passed by ipf.
From the man page:
Each rule processed by ipf is added to the kernel's internal lists
if there are no parsing problems. Rules are added to the end
of the internal lists.
So the packet filtering lists are affected inside the kernel.
> I guess its not a big deal since the only machine that should be able to
> get packets to me with a dest. of 192.168.* is my ISPs router. But still,
> shouldn't it be possible to block packets that have an explicit internal
> destination seperately from packets that have been translated to
> point to an an internal address?
Hmmm, now how do you expect that packets with destination address
which belong to non routable addresses end up at your router?
Only case i could think of is when you have an ipsec tunnel mode
with another border machine or host and the ipsec process takes
place before ipf (seen from outside-> inside)
in which the packets wont come trough nat
unless you make a rdr if that's gonna work at all?
Regards,
Mipam.
Clayton Fiske
> Just out of curiosity, what is the motivation for doing NAT before
> filtering incoming packets? Its seems a little strange that "block in on
> ppp0 from any to 192.168.0.0" blocks all incoming packets for my internal
> machines using NAT even though tcpdump shows the packets as having dest.
> of my external IP. I.E. I think of NAT as processing of the packet, and
> filtering as taking place before the kernel sees the packet...
I would imagine the motivation is that you can filter on a per-internal-
destination basis, such that you have granular control when you do
things like bimaps and rdrs.
-c
Guido van Rooij
> posted]
>
> filtering incoming packets? Its seems a little strange that "block in on
The motivation is that you can then specify all rules such that it reflects
the way the ipfilter host sees its connected networks.
-Guido
mouss
>Just out of curiosity, what is the motivation for doing NAT before
>filtering incoming packets?
It's not that simple. With a map rule:
- source addresses are mapped at the very last moment (nat_out)
- destination addresses (response packets) are mapped at the first moment
(nat_in).
(situation is different with a rdr rule).
so if you map 192.168.0.0 to 1.2.3.4 on the external interface, then outbound
packets are mapped just before the packet is delivered to the network interface
(and thus after filtering), and their responses are mapped at the moment they
arrive (and thus before filtering).
>Its seems a little strange that "block in on
>ppp0 from any to 192.168.0.0" blocks all incoming packets for my internal
>machines using NAT
I suspect you're not using "keep state" to allow responses to your legitimate
packets (I mean "keep state" in other rules, not in the "block" one).
>even though tcpdump shows the packets as having dest of my external IP.
tcpdump sees what the network interface sees. so, if you tcpdump on the
external interface, you should only see public addresses, and if you tcpdump
on the internal one, you'll see private addresses. use the "-i" flag to specify
the interface.
> I.E. I think of NAT as processing of the packet, and
>filtering as taking place before the kernel sees the packet...
see above (anyway, nat and filtering are inside the ip stack, which is
inside the
kernel:)
>I guess its not a big deal since the only machine that should be able to
>get packets to me with a dest. of 192.168.* is my ISPs router.
normally, no machine should send you a packet with such a dest, even your
ISP router.
If you see such packets, then one of the following things is true:
- you have something misconfigured which sends un-natted packets. these then
pollute/poison some routers, which set you as the route to such addresses.
so you
get such packets (and even if you don't poison routers, you might receive icmp
packets with these dest addresses).
- someone outside has something misconfigured which makes such packets
routed to
you. This requires that all the routers in between accept to route these
packets to you.
so if the source is far, it's not probable.
- someone is attacking you. he has either poisoned routers or is using
source routed packets.
These may come to you, and you should reject them...
> But still,
>shouldn't it be possible to block packets that have an explicit internal
>destination seperately from packets that have been translated to
>point to an an internal address?
It should be this way, but that requires filtering before and after NAT, which
is not an easy decision to take!
Indeed, the current design doesn't allow ipf to distinguish between a packet
that was sent to 192.168.0.0 and a packet that was mapped to have such
destination. In most cases, you just use keep state to allow responses and drop
the rest. if you wanna do more filtering, then you're out of luck...
cheers,
mouss