From owner-freebsd-questions@FreeBSD.ORG Sun Jul 24 16:09:09 2005 Return-Path: X-Original-To: questions@freebsd.org Delivered-To: freebsd-questions@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 527EE16A420 for ; Sun, 24 Jul 2005 16:09:09 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from pi.codefab.com (pi.codefab.com [199.103.21.227]) by mx1.FreeBSD.org (Postfix) with ESMTP id D020043D46 for ; Sun, 24 Jul 2005 16:09:08 +0000 (GMT) (envelope-from cswiger@mac.com) Received: from localhost (localhost [127.0.0.1]) by pi.codefab.com (Postfix) with ESMTP id 00A615E23; Sun, 24 Jul 2005 12:09:07 -0400 (EDT) Received: from pi.codefab.com ([127.0.0.1]) by localhost (pi.codefab.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29176-02; Sun, 24 Jul 2005 12:08:58 -0400 (EDT) Received: from [192.168.1.3] (pool-68-161-54-113.ny325.east.verizon.net [68.161.54.113]) by pi.codefab.com (Postfix) with ESMTP id D54D05C45; Sun, 24 Jul 2005 12:08:57 -0400 (EDT) Message-ID: <42E3BD1D.4020301@mac.com> Date: Sun, 24 Jul 2005 12:09:01 -0400 From: Chuck Swiger Organization: The Courts of Chaos User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Dirk GOUDERS References: <200507241112.j6OBCdVx095354@karga.hank.home> In-Reply-To: <200507241112.j6OBCdVx095354@karga.hank.home> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: amavisd-new at codefab.com Cc: questions@freebsd.org Subject: Re: ipfw and tun0 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Jul 2005 16:09:09 -0000 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 68.161.54.113.2145 > 199.103.21.225.321: S 610825795:610825795(0) win 57344 (DF) 68.161.54.113.2145 > 199.103.21.225.321: S 610825795:610825795(0) win 57344 (DF) ^C 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). -- -Chuck