Date: Fri, 10 Jan 2003 12:29:29 +0100 From: jeremie le-hen <le-hen_j@epita.fr> To: freebsd-net@freebsd.org Subject: ipnat and ipf interaction precisions Message-ID: <20030110112929.GB1130@carpediem.epita.fr>
next in thread | raw e-mail | index | archive | help
Hi,
I'm trying to block a single IP address which belongs to my private nated
network. Here is my ipnat.rules:
---
map tun0 192.168.0.0/24 -> 0/32 proxy port ftp ftp/tcp
map tun0 192.168.0.0/24 -> 0/32
---
and a summary of my ipf.rules:
---
# Allow loopback traffic
pass in quick on lo0 all
pass out quick on lo0 all
# Allow LAN traffic
pass in quick on ep0 all
pass out quick on ep0 all
pass in quick on ep2 all
pass out quick on ep2 all
# Default to allow outcoming packets keeping state
pass out quick proto tcp/udp all keep state
pass out quick proto icmp all keep state
# Allow ping requests
pass in log first quick on proto icmp all icmp-type echo
# Block everything else
block in log first quick proto tcp all
block in log first quick proto udp all
block in log first quick proto icmp all
---
As you can see, my private network is 192.168.0.0/24, and I would like to
block all traffic to Internet from host 192.168.0.3.
As far as I know, ipf and ipnat interact this way:
interface -> ipnat -> ipf -> os -> ipf -> ipnat -> interface
Any outgoing packets from the internal network to the Internet will see their
source address modified by ipnat just before passing through the public
interface. Conversely, incoming packets from Internet will see their
destination address changed when they just passed through the public interface.
So I tried to add this kind of rule in the beginning of the ruleset, but
it does not seems to work (note that ep0 is the interface connected to my
internal network):
---
# Block all Internet traffic from host 192.168.0.3
block in quick on ep0 from 192.168.0.3/32 to ! 192.168.0.0/24
---
Theoretically, since ipnat will modify the source address of the IP packet
once it reached the public interface, the packets should be blocked. And they
are. Then I tried to block all traffic from host 192.168.0.3 to Internet by
replacing the previous rule with this one:
---
# Block all Internet traffic from host 192.168.0.3
block out quick on tun0 from 192.168.0.3/32 to any
---
With this rule, the traffic is also blocked, but there is one major difference.
Indeed my FreeBSD box running ipnat/ipf sends an ICMP host unreachable for each
packet. I think that the OS IPv4 stack cannot route the packet to my public
interface since ipfilter forbids the stack it to send the packet, and so
the stacks notifies host 192.168.0.3 that it cannot contact the remote host,
using an ICMP host unreachable. Am I right ?
My second question concerns RDR mecanism. I have added the following line in
my ipnat.rules:
---
rdr tun0 0.0.0.0/0 port 2202 -> 192.168.0.2 port ssh
---
And then I wished to block these packets with ipf (that's quite useless, but
it's for my curiosity). Since this kind of redirection involve modifying
destination address of the incoming packets when they just have been received
by the public interface, ipf rules should take care of this.
First, I tried the following rules, which seems to work perfectly (tun0 is my
public interface):
---
block in quick on tun0 from any to 192.168.0.2/32
---
TCP SYN packets to port 2202 are never sent to host 192.168.0.2.
Then I tried to set up an equivalent rule on my internal interface ep0:
---
block out quick on ep0 from ! 192.168.0.0/24 to 192.168.0.2/32
---
With this rule, the TCP SYN packets are not forwarded to host 192.168.0.2, but
this time, my FreeBSD box sends back an RST packet to the remote host.
I think this behaviour can be explained with the same reason as above, ipfilter
simply prevents the OS IPv4 stack to forward the packet through ep0. Therefore,
the OS notifies the remote host that the connection is impossible, following
TCP RFC recommandations.
Am I right there ?
I'm pretty sure that these ICMP host unreachable and TCP RST packets are
generated by the operating system itself, not by ipfilter.
Thanks in advance for all replies that my confirm or refute my explanation.
Finally, excuse me for my poor english, I'm working hard to improve it.
Regards,
--
Jeremie aka T{ata,t}Z
le-hen_j@epita.fr
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-net" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030110112929.GB1130>