IPsec with NAT-T in transport mode dropping all packets?

[Bob McConnell]

-----Original Message-----
From: owner-freebsd-questions at freebsd.org
[mailto:owner-freebsd-questions at freebsd.org] On Behalf Of David Murray
Sent: Tuesday, August 19, 2008 7:45 AM
To: freebsd-questions at freebsd.org
Subject: Re: IPsec with NAT-T in transport mode dropping all packets?

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!
-----End Original Message-----

It has been a long time since I looked at IPSEC, but my understanding
was that it was designed so that it could not work through either NAT or
proxy firewalls. Both schemes change header fields that are considered
immutable by IPSEC. So it breaks a checksum.

Wouldn't it be better to set up SSH tunnels or a secure VPN?

Bob McConnell