|Main Archive Page > Month Archives > ipsec archives|
> Your design (which is similar to the one in Solaris/OpenSolaris) WOULD
> initiation to a behind-a-NAT peer if (and only if) the NAT was smart
> 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
> 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.
Dan McDonald <email@example.com>
Scott C Moonen/Raleigh/IBM@IBMUS
09/22/2009 01:20 PM
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
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. :)