Date: Fri, 25 Sep 2009 09:36:01 +0200 From: VANHULLEBUS Yvan <vanhu@FreeBSD.org> To: Riaan Kruger <riaank@gmail.com> Cc: Riaan nanoteq <rk@nanoteq.co.za>, freebsd-net@freebsd.org Subject: Re: IPsec NATT: Multiple initiators behind NAT Message-ID: <20090925073600.GA16224@zeninc.net> In-Reply-To: <85c4b1850909242348o312a0015vf0bf52a141c09f42@mail.gmail.com> References: <85c4b1850909242348o312a0015vf0bf52a141c09f42@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi. On Fri, Sep 25, 2009 at 08:48:50AM +0200, Riaan Kruger wrote: > I have a problem with multiple IPsec Gateways behind a single NAT > communicating to one responder (on the other side of the NAT). > > The diagram shows a typical set up. (FreeBSD 8 and ipsec-tools 0.7.2) FreeBSD 8 ans ipsec-tools 0.7.x are NOT expected to work together when using NAT-T (actually, I'm just not sure ipsec-tools will detect kernel NAT-T support and compile correctly....). Please try again with a recent ipsec-tools HEAD snapshot. > GW (Initiator) ----| > | --- NAT ----- GW (responder) > GW (Initiator) ----| > > On the responder the SADs get "mixed up" when a second set of SAs are > written to the SAD for the second GW. > The port numbers of the second set of SAs are set to that of the first set > of SAs even though different ones are provided. > > I tried to isolate and illustrate the problem using only setkey from the > command line (taken from ipsec-tools) > > THE STEPS: > ------------------- > setkey.conf: > flush; > add 10.0.0.20[4500] 10.0.0.10[50000] esp-udp 0x2010 -E 3des-cbc > 0x123456781234567812345678123456781234567812345000; > add 10.0.0.10[50000] 10.0.0.20[4500] esp-udp 0x1020 -E 3des-cbc > 0x123456781234567812345678123456781234567812345000; > add 10.0.0.20[4500] 10.0.0.10[60000] esp-udp 0x2011 -E 3des-cbc > 0x123456781234567812345678123456781234567812345111; > add 10.0.0.10[60000] 10.0.0.20[4500] esp-udp 0x1120 -E 3des-cbc > 0x123456781234567812345678123456781234567812345111; Do you have enough control on NAT device to ensure those will be the correct source ports ? Usually, on such setups, source ports for initiators can't be predicted, so weuse generate_policy feature on responder's side. Yvan.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090925073600.GA16224>