IETF Logo Mail Archive

Re: [IPsec] nat traversal and transport mode

Yoav Nir <ynir.ietf@gmail.com> Tue, 16 June 2015 13:50 UTC

Return-Path: <ynir.ietf@gmail.com>
X-Original-To: ipsec@ietfa.amsl.com
Delivered-To: ipsec@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D9261B35A8 for <ipsec@ietfa.amsl.com>; Tue, 16 Jun 2015 06:50:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1ZeHZtnNwwG for <ipsec@ietfa.amsl.com>; Tue, 16 Jun 2015 06:50:14 -0700 (PDT)
Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32FC41B35AD for <ipsec@ietf.org>; Tue, 16 Jun 2015 06:50:12 -0700 (PDT)
Received: by wiga1 with SMTP id a1so109647201wig.0 for <ipsec@ietf.org>; Tue, 16 Jun 2015 06:50:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=vTH+XKk2IOm/QJo8wFl1A4g+0NRipXGXuvcZtsuYFrI=; b=a+TtSZuSwQsVMW1gXhtA9TQltyWlRMrbGvBgoDNmJ+4dhoCJiO2D+phkc2S3f86Ot1 7Z/fONMxjztqITMFMuEcVgxIYcP+B1zufC951IwUPPnR167sszP92iiYRFgfnEqXpmtU wwEK6Z8PjUn9qzMxadhx26izOcgkbx0f+oo0y9p2gSEa+AltUMDvSCBt24XWXUMr8V32 ZsJ+JAG0U6Y1j78MOTWMRK+rbWhHx5mQWazGfbUO39iyPiqGPHfA7pcOXh3aXOWUuOIp 7XI5NqJco9XY790MXB3AZBo4u57KNkku9GgWTYwPtD8P4cHslpIQQIYcu5AE6CPbhiLF eX9g==
X-Received: by 10.180.90.209 with SMTP id by17mr43405251wib.2.1434462610927; Tue, 16 Jun 2015 06:50:10 -0700 (PDT)
Received: from [172.24.251.11] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id bg6sm1765698wjc.13.2015.06.16.06.50.09 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 16 Jun 2015 06:50:10 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
From: Yoav Nir <ynir.ietf@gmail.com>
In-Reply-To: <alpine.LFD.2.11.1506160940010.24386@bofh.nohats.ca>
Date: Tue, 16 Jun 2015 16:50:08 +0300
Content-Transfer-Encoding: quoted-printable
Message-Id: <8FEC8628-D892-4171-86F5-6BE58F580432@gmail.com>
References: <558009C9.8040509@poczta.onet.pl> <5B5045FC-A79A-45D1-B051-7B82A546D01F@gmail.com> <alpine.LFD.2.11.1506160940010.24386@bofh.nohats.ca>
To: Paul Wouters <paul@nohats.ca>
X-Mailer: Apple Mail (2.2098)
Archived-At: <http://mailarchive.ietf.org/arch/msg/ipsec/piGVMlG1e9deR9IxaedXfbLIaII>
Cc: "ipsec@ietf.org WG" <ipsec@ietf.org>, Michał Zegan <webczat_200@poczta.onet.pl>
Subject: Re: [IPsec] nat traversal and transport mode
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discussion of IPsec protocols <ipsec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipsec>, <mailto:ipsec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipsec/>
List-Post: <mailto:ipsec@ietf.org>
List-Help: <mailto:ipsec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipsec>, <mailto:ipsec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jun 2015 13:50:18 -0000

> On Jun 16, 2015, at 4:44 PM, Paul Wouters <paul@nohats.ca> wrote:
> 
> On Tue, 16 Jun 2015, Yoav Nir wrote:
> 
>> 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.
> 
> 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.

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)

v2.23.0 | Report a Bug | By Email