Subject: [IPsec] nat traversal and transport mode

From: Michał Zegan <[email-masked]>
Date: Tue, 16 Jun 2015 13:34:33 +0200

Hello.

I have heard that transport mode should not be used if the initiator
is behind a NAT, even with nat traversal protocols, because this does
have some issues.
However, I am not quite sure if I understand what issues are that?
Also, does it mean that l2tp over ipsec suffers the same issues but
you have no choice in this case?

---

From: Yoav Nir <[email-masked]>
Date: Tue, 16 Jun 2015 15:01:03 +0300

Hi.

Transport mode works fine behind NAT devices. For example, L2TP clients connect to VPN gateways using transport mode and they work behind NAT devices.

It is AH that cannot work behind NAT.  

HTH

Yoav

> On Jun 16, 2015, at 2:34 PM, Michał Zegan <[email-masked]> wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello.
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
> 
> iQIcBAEBAgAGBQJVgAnHAAoJEHb1CzgxXKwYEmkP+gOyeNY+JjLJW78mIUb6WPaW
> DKQ8TyrnWsB3rTjWeNlO0eADKlj5XfpXRhf257XDkZgDxlNNhcJxol23nx7tRRqB
> 8kZimQqgpSA+WE4vQ6odZeSEIzfXElv4viPeIZgOcftDMhsgfqhpkqn7gfH+Kg8J
> SRy9JWxdPQ2oJHiurjRIjZ4/KoLqGgU+ncl9wj68FJrKjs2uM2NIncHQAlW9AEUD
> KFy/+QbIo5/UFkHzwXKzw/I5Z4Fic2YfELW6H5JmQEl77zQywKknM+OgDL58VpXW
> cQTPKvJaQLlJ7PbJi7N3t/SupQsUmQBQsPfit/q0+H3il+i+Yijkz8d/Ofy0lssB
> DUnIxr+o6R3qGx5XHNtA1F2fJ3gGFCLd5mQHOs40+Bl3Xlhyx0PcGChHGrne7INl
> vIqnLOQWyJxEUzIdTkzUbFo7UlYYJh6wUq2MViMDGrV6TbaPuhj+FewQvylpeyqH
> Bjfumhj5ShhMNeXqv0isEQz/V7KWWO47GvL8jveUcaOK7udzSwjHETK9H+Rp8S29
> BZTCFXs2TMMPEppJoSljVz/xue22aV6eCB0cT1VOtZUn3+2pZybq2Qlkzu7mAFtl
> LYYMdV/XS9ZEyYUf5KDQWIiK5+Q3dK5gFUSb6eiiWb5COToY247DsPR9yrHDDCpT
> 1SfJd/Dcg4mg6i1aKB75
> =14QR
> -----END PGP SIGNATURE-----
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Michael Richardson <[email-masked]>
Date: Tue, 16 Jun 2015 09:41:06 -0400

> is behind a NAT, even with nat traversal protocols, because this does

Yes, the issue is that on the gateway system, you wind up with zillions
of transport sockets that are connected to 192.168.1.101 on the remote
end, and you have to distinguish them by the IPsec state.
(If you use tunnel mode through NAT, one usually assigns an IP address
to the end system to use, and one can make that address unique)

So, it's not a security or protocol problem, but on a generic operating system
(Linux, *BSD, probably windows), it's a problem to get the right bookeeping
in place.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Paul Wouters <[email-masked]>
Date: Tue, 16 Jun 2015 09:44:16 -0400 (EDT)

> It is AH that cannot work behind NAT.

It's a lot more complicated. Since transport mode crypto binds to
the outer IP address, you will end up with multiple clients using
the same remote IP on their security policy. Eg multiple clients can
have 192.168.1.1. Now you have to keep track of these (Linux: SAref or
conntrack) and you still cannot initiate a new connection to a specific
remote endpoint from the server without additional hacking to ensure
you are going to the right 192.168.1.1 client.

When using tunnel mode, you can give each connecting client their own IP
address to avoid all conflicts.

Paul

---

From: Yoav Nir <[email-masked]>
Date: Tue, 16 Jun 2015 16:50:08 +0300

> On Jun 16, 2015, at 4:44 PM, Paul Wouters <[email-masked]> wrote:
> 

If you’re using transport mode, you never get to see 192.168.1.1 - that’s converted by the NAT device to its own external IP address.  But it’s true that you have to be stateful about flows to be able to return the right packet to the right source. 

Which is why VPNs need tunnels (either IPsec or GRE or L2TP, but preferably IPsec)