ipfw and tun0

Chuck Swiger cswiger at mac.com
Sun Jul 24 16:09:09 GMT 2005

Dirk GOUDERS wrote:
[ ... ]
>> If you are using PPPoE, the system de-encapsulates the IP traffic off of the
>> PPP session via the tun0 interface.  tun0 can be treated as your "external 
>> interface" when writing firewall rules, setting up NAT, etc.
> Well, I am a little bit confused, because usually, I run machines with
> "real" NICs and if I activate firewall rules that drop packets from
> that NIC, I can run tcpdump on that NIC and will not see the dropped
> packets.

Are you 100% certain of that?  What you've described does not match how tcpdump 
on a BSD system works here:

nfw1# ipfw add 10 deny ip from any to any 321
00010 deny ip from any to any dst-port 321
nfw1# tcpdump -nt -i fxp0 port 321
tcpdump: listening on fxp0 > S 610825795:610825795(0) win 57344 
<mss 1450,nop,wscale 0,nop,nop,timestamp 410027852 0> (DF) > S 610825795:610825795(0) win 57344 
<mss 1450,nop,wscale 0,nop,nop,timestamp 410030852 0> (DF)
44 packets received by filter
0 packets dropped by kernel

tcpdump sees the incoming SYN packets just fine, even if IPFW denies them in 
the very first rule.

> This is the naive view, I have about this:
> NIC device (e.g. xl0)
>          -----------------------------------------------------
>  packets -> packets ->            ...                     packets -> packets ->
>          -----------------------------------------------------
>                        ^                        ^
>                        |                        |
>               Here, ipfw checks           Here, tcpdump listens
>               the packets against         and doesn't see dropped
>               its rules and probably      packets
>               drops packets

There's a diagram in the IPFW manpage that has a better description of the 
packet flow.  tcpdump runs sooner than you've shown, and traffic through most 
interfaces is bidirectional.

>> Right.  This implies that the firewall rules are working.  If you
>> want to see what the situation looks like to a client machine
>> behind the firewall, either tcpdump on a client machine, or tcpdump
>> on the internal interface of the firewall box...
> Does that mean, that there is no way, to inspect the network
> traffic from tun0 after it has been "cleaned up" by ipfw and that is
> not forwarded to the internal NIC?

You can either add a log rule after your IPFW reject rules, and have the 
firewall itself log the traffic which is permitted through, or you could use 
another divert rule and force that traffic into a daemon which looks at the 
packets (this is how natd works, after all).


More information about the freebsd-questions mailing list