From owner-freebsd-net@FreeBSD.ORG Fri Jul 30 07:05:56 2004 Return-Path: Delivered-To: freebsd-net@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C757C16A4CE for ; Fri, 30 Jul 2004 07:05:56 +0000 (GMT) Received: from transport.cksoft.de (transport.cksoft.de [62.111.66.27]) by mx1.FreeBSD.org (Postfix) with ESMTP id E31F243D62 for ; Fri, 30 Jul 2004 07:05:55 +0000 (GMT) (envelope-from bzeeb-lists@lists.zabbadoz.net) Received: from transport.cksoft.de (localhost [127.0.0.1]) by transport.cksoft.de (Postfix) with ESMTP id 54AAD1FFDD4; Fri, 30 Jul 2004 09:05:07 +0200 (CEST) Received: by transport.cksoft.de (Postfix, from userid 66) id 4DA1F1FF9A6; Fri, 30 Jul 2004 09:05:05 +0200 (CEST) Received: by mail.int.zabbadoz.net (Postfix, from userid 1060) id 940551539E; Fri, 30 Jul 2004 07:02:25 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by mail.int.zabbadoz.net (Postfix) with ESMTP id 88DAC15384; Fri, 30 Jul 2004 07:02:26 +0000 (UTC) Date: Fri, 30 Jul 2004 07:02:26 +0000 (UTC) From: "Bjoern A. Zeeb" X-X-Sender: bz@e0-0.zab2.int.zabbadoz.net To: "Nickolay A. Kritsky" In-Reply-To: <12410155296.20040730100443@star-sw.com> Message-ID: References: <652582171.20040730075831@star-sw.com> <12410155296.20040730100443@star-sw.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS cksoft-s20020300-20031204bz on transport.cksoft.de cc: freebsd-net@freebsd.org Subject: Re[2]: ipsec packet filtering X-BeenThere: freebsd-net@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Networking and TCP/IP with FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Jul 2004 07:05:57 -0000 On Fri, 30 Jul 2004, Nickolay A. Kritsky wrote: > OK. let's place a small demonstration. > > 217.195.82.43 <-->VPN_router1 <--> [---INTERNET---] > | > | > 192.168.64.10 <---> VPN_router2 > > Traffic between 217.195.82.43 and 192.168.64.10 is encrypted by ipsec > in esp/tunnel mode. and this is done on the VPN_router{1,2} I guess. > Icmp is enabled, and pings go OK. > Then I do (on VPN_router2): > bash-2.05b# uname -sr > FreeBSD 4.9-RELEASE ok; for the 'ipsec' ipfw option this is too old. It's been functional in 5.x since 2003-12-02, that is 5.2, 5.2.1, HEAD and in RELENG_4 since 2004-01-22 that is 4.10 includes it but 4.9-RELEASE does not. > bash-2.05b# ipfw add 1 count icmp from 192.168.64.10 to 217.195.82.43 in > 00001 count icmp from 192.168.64.10 to 217.195.82.43 in > bash-2.05b# ipfw add 1 count icmp from 192.168.64.10 to 217.195.82.43 out > 00001 count icmp from 192.168.64.10 to 217.195.82.43 out > bash-2.05b# ipfw sh 1 > 00001 0 0 count icmp from 192.168.64.10 to 217.195.82.43 in > 00001 0 0 count icmp from 192.168.64.10 to 217.195.82.43 out ok; not how I would do it but ok. > after 4 pings from 217.195.82.43 to 192.168.64.10: > > bash-2.05b# ipfw sh 1 > 00001 4 240 count icmp from 192.168.64.10 to 217.195.82.43 in > 00001 0 0 count icmp from 192.168.64.10 to 217.195.82.43 out > > while it obviously should be 4 of them in both rules. no. if you ping from 217.195.82.43 to 192.168.64.10 it should be like that on vpn_router2 (not ipsec option yet as you cannot use it): ipfw add 1 count icmp from 217.195.82.43 to 192.168.64.10 in recv $int_outside # expecting 0 matches ipfw add 1 count esp from 217.195.82.43 to 192.168.64.10 in recv $int_outside # expecting 4 amtches ipfw add 1 count icmp from 217.195.82.43 to 192.168.64.10 out xmit $int_inside # in recv $int_outside # expecting 4 matches ipfw add 1 count icmp from 192.168.64.10 to 217.195.82.43 in recv $int_inside # expecting 4 matches ipfw add 1 count icmp from 192.168.64.10 to 217.195.82.43 out xmit $int_outside # in recv $int_inside # expecting 0 matches ipfw add 1 count esp from 192.168.64.10 to 217.195.82.43 out xmit $int_outside # in recv $int_inside # expecting 4 matches > That is the problem that bothers me. > To show that is not pure theoretical, here is the scenario: > We need to establish VPN with our customer. They request us to NAT all > our outgoing traffic, so that all packets will have the same src addr. ok. > natd translates rewrites src addr only on outgoing packets, but the > outgoing packets never reach natd, because they don't make it thru > ipfw rules. Tricky, eh? So I see 3 choices so far: > 1. patch libalias > 2. patch the kernel (ip_output.c ? ip_fw.c? ) > 3. use two separate boxes for nating and ipsekking. no, no, no. filter on your inside interface and divert packets there; this way nat is done before reaching output and thus before ipsec. In the other direction packet are first run through ipsec getting you the IP packet (that then will have an ipsec history you can match with an up-to-date release) and when leaving the machine to your inside network will be natted back. The ruleset gets quite tricky then but it works here (HEAD from about 82 days ago according to uptime ;-) > so when you are saying: > BAZ> - come in unencrypted and go out encrypted > it is quite a surprise for me. > What is your FreeBSD version? Can you confirm that with the test like > above? with a newer version you should be able to do it. Expect to need 2 days to fully understand everything and get it setup. -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT