Date: Tue, 19 Aug 2008 12:44:36 +0100 From: David Murray <freebsd-questions@davidmurray.name> To: freebsd-questions@freebsd.org Subject: Re: IPsec with NAT-T in transport mode dropping all packets? Message-ID: <48AAB224.9000208@davidmurray.name> In-Reply-To: <489AE41C.1070504@davidmurray.name> References: <489AE41C.1070504@davidmurray.name>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello again all, On Thu 7/8/08 1:01 pm, David Murray wrote: > I'm having a bit of trouble getting IPsec working in transport mode > with NAT-T. > > Briefly, the background is that I'm trying to configure a FreeBSD box > to provide to remote Windows clients with VPN access to the network it > sits on. To that end, I've been trying to construct a solution with > the following: > > 1) FreeBSD (RELENG_7_0), kernel built with options IPSEC and > IPSEC_NAT_T, and patched with > 2) the NAT-T patch at > http://vanhu.free.fr/FreeBSD/patch-natt-freebsd7-2008-03-11.diff, > 3) ipsec-tools (0.7.0) for racoon for key exchange, and > 4) mpd (5.1) for L2TP. > > I have two security policy entries in ipsec.conf, intended to encrypt > L2TP traffic: > > spdadd 82.16.99.99[1701] 0.0.0.0/0 udp -P out ipsec > esp/transport//require; > spdadd 0.0.0.0/0 82.16.99.99[1701] udp -P in ipsec > esp/transport//require; > > The tricky key negotiation all seems to be working; when I initiate a > connection from a Windows client, racoon negotiates security > associations (I'm using certificates): > > racoon: INFO: IPsec-SA established: ESP/Transport > 195.248.102.183[4500]->82.16.99.99[4500] spi=73448711(0x460bd07) > racoon: INFO: IPsec-SA established: ESP/Transport > 82.16.99.99[4500]->195.248.102.183[4500] spi=2159874738(0x80bd12b2) > > However, mpd's log doesn't show any evidence of a single packet > arriving (and the client eventually gives up). No takers, so I guess this is either a stupid question or a tricky question! Perhaps I should have asked over on freebsd-net@, but I presumed to ask here first, since I've got no reason to suspect anything other than operator error at the moment. Perhaps I could try a simpler question: has anyone got a L2TP/IPSec roadwarrior-style VPN working where the clients (initiators) are behind NAT? Since my first post, I've tried initiating a connection from a client directly connected to the network I'm trying to VPN in to (so pointless, but a way of testing without NAT) and that works just fine, so I can provide differences between the logs of a failed and working connection. Thanks for any hints! -- David Murray
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48AAB224.9000208>