Date: Fri, 30 Jul 2004 07:02:26 +0000 (UTC) From: "Bjoern A. Zeeb" <bzeeb-lists@lists.zabbadoz.net> To: "Nickolay A. Kritsky" <nkritsky@star-sw.com> Cc: freebsd-net@freebsd.org Subject: Re[2]: ipsec packet filtering Message-ID: <Pine.BSF.4.53.0407300640090.41939@e0-0.zab2.int.zabbadoz.net> In-Reply-To: <12410155296.20040730100443@star-sw.com> References: <652582171.20040730075831@star-sw.com> <Pine.BSF.4.53.0407300457460.41939@e0-0.zab2.int.zabbadoz.net> <12410155296.20040730100443@star-sw.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.53.0407300640090.41939>