From owner-freebsd-net@FreeBSD.ORG Tue Feb 8 09:20:39 2011 Return-Path: Delivered-To: net@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 66D981065670 for ; Tue, 8 Feb 2011 09:20:39 +0000 (UTC) (envelope-from emz@norma.perm.ru) Received: from elf.hq.norma.perm.ru (mail.norman-vivat.ru [89.250.210.68]) by mx1.freebsd.org (Postfix) with ESMTP id B26298FC17 for ; Tue, 8 Feb 2011 09:20:36 +0000 (UTC) Received: from bsdrookie.norma.com. (bsdrookie.hq.norma.perm.ru [192.168.7.246]) by elf.hq.norma.perm.ru (8.14.3/8.14.3) with ESMTP id p1895cBk086297 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 8 Feb 2011 14:05:39 +0500 (YEKT) (envelope-from emz@norma.perm.ru) Message-ID: <4D510762.7090304@norma.perm.ru> Date: Tue, 08 Feb 2011 14:05:38 +0500 From: "Eugene M. Zheganin" User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.9.2.8) Gecko/20100917 Thunderbird/3.1.2 MIME-Version: 1.0 To: FreeBSD Net Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.3 (elf.hq.norma.perm.ru [192.168.3.10]); Tue, 08 Feb 2011 14:05:39 +0500 (YEKT) X-Callback: Sender verified by milter-callback 1.5.12 at elf.hq.norma.perm.ru. X-Callback-Status: relay [192.168.7.246] found in white list. X-Callback-Envelope-From: emz@norma.perm.ru X-Spam-Status: No hits=-102.9 bayes=0.0000 testhits ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on elf.hq.norma.perm.ru Cc: Subject: ipfw, ipv6 and gif(4) X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Feb 2011 09:20:39 -0000 Hi. I'm running FreeBSD 8.1-STABLE (I had major issues with em(4) on 8.1-RELEASE, so I had to upgrade this host to more recent STABLE). I'm using ipv6-over-ipv4 tunnel. gif0: flags=8051 metric 0 mtu 1280 tunnel inet 89.250.210.67 --> 216.66.80.26 inet6 2001:470:1f08:14c0::2 --> 2001:470:1f08:14c0::1 prefixlen 128 nd6 options=3 options=1 In order it to work I have to allow ipv4 packets between these two hosts: (and these are two first rules in the filter) 00005 14 1072 allow log ip4 from 89.250.210.67 to 216.66.80.26 out via vlan104 00006 14 1072 allow log ip4 from 216.66.80.26 to 89.250.210.67 in via vlan104 The thing is, normally (at least in ipv4 world) I would have to allow ipencap packets between these hosts (and that's what I did first thing), but this configuraion never worked. I've even added 'allow' strings for every type of encapsulation from /etc/protocols, just to see their counters never changed from zero. Those two rules above were made after 'ok, let's allow everything just to see in log what does it want' decision. I want to ask - why ip4 ? And the log looks even more weird: %ping6 2001:470:1f08:14c0::1 PING6(56=40+8+8 bytes) 2001:470:1f08:14c0::2 --> 2001:470:1f08:14c0::1 16 bytes from 2001:470:1f08:14c0::1, icmp_seq=0 hlim=64 time=93.917 ms 16 bytes from 2001:470:1f08:14c0::1, icmp_seq=1 hlim=64 time=93.307 ms Feb 8 13:56:48 ns kernel: ipfw: 5 Accept P:41 89.250.210.67 216.66.80.26 out via vlan104 Feb 8 13:56:48 ns kernel: ipfw: 6 Accept P:41 216.66.80.26 89.250.210.67 in via vlan104 Feb 8 13:56:49 ns kernel: ipfw: 5 Accept P:41 89.250.210.67 216.66.80.26 out via vlan104 Feb 8 13:56:49 ns kernel: ipfw: 6 Accept P:41 216.66.80.26 89.250.210.67 in via vlan104 As you can see, P:41 is IPv6: %grep 41 /etc/protocols ipv6 41 IPV6 # ipv6 And, of course, ipfw doesn't allow me to create the rules it is actually logging: %ipfw add 7 allow 41 from 216.66.80.26 to 89.250.210.67 in via vlan104 ipfw: bad address "216.66.80.26" Do I misunderstand the concept, or is it how it really should look ? Thanks. Eugene.