| Main Archive Page > Month Archives > ipsec archives |
Dan,
> Your design (which is similar to the one in Solaris/OpenSolaris) WOULD
allow
> initiation to a behind-a-NAT peer if (and only if) the NAT was smart
enough
> to redirect 500 and 4500 to a single entity inside its private network.
> (I'll be experimenting with this directly when I move into my new house
this
> weekend, actually. :)
Certainly -- initiating to a peer behind a static NAT is not a problem for our implementation as long as we either use transport mode or elide IDi/IDr (i.e., end-to-end protecting all protocols). Initiating to a gateway behind that NAT is a problem, since you cannot populate IDr without knowing addresses in the foreign network.
Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen
From:
Dan McDonald <danmcd@sun.com>
To:
Scott C Moonen/Raleigh/IBM@IBMUS
Cc:
ipsec@ietf.org
Date:
09/22/2009 01:20 PM
Subject:
Re: [IPsec] IKEv2 NAT-T and Traffic Selectors
On Tue, Sep 22, 2009 at 12:52:51PM -0400, Scott C Moonen wrote:
> Hi Matt. Our implementation works a little differently from Tero's, so
> I'm replying just to provide a different perspective.
<mucho snippage deleted!>
> Our design decision does prevent our implementation from initiating to a
> remote IPsec gateway if that gateway is behind a NAT, since we have
> excluded the possibility of configuring addresses in the network behind
> that NAT. We believe that initiating to a gateway behind a NAT is an
> uncommon configuration, especially for our platform.
Your design (which is similar to the one in Solaris/OpenSolaris) WOULD
allow
initiation to a behind-a-NAT peer if (and only if) the NAT was smart
enough
to redirect 500 and 4500 to a single entity inside its private network.
(I'll be experimenting with this directly when I move into my new house
this
weekend, actually. :)
Dan