Hi Matt. Our implementation works a little differently from Tero's, so I'm replying just to provide a different perspective.
For our implementation, we've decided that foreign network addresses should not generally appear in either our configuration or our primary displays. In your scenario, if IPsec were not in use, a TCP connection through n...@x would appear to have a remote address of X at the responder. For our implementation this would remain true even when IPsec is introduced along the path. Speaking in terms of IKEv1, if our IKE is responder in this scenario, we will note the proposed IDi as the real client address and X as the public client address. We will compare address X against our PAD and SPD for policy decisions, but we will echo the original IDi and IDr in our response. Obviously this means that we need to do address translation within our platform to map 192.168.2.* to 192.168.3.5. This grows a little tricky for ICMP messages with embedded packets. Note that in any case the responder really ought to perform port translation in this configuration. 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. Scott Moonen (smoo...@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: Tero Kivinen <kivi...@iki.fi> To: Matthew Cini Sarreo <mci...@gmail.com> Cc: ipsec@ietf.org Date: 09/22/2009 08:02 AM Subject: [IPsec] IKEv2 NAT-T and Traffic Selectors Matthew Cini Sarreo writes: > Hello all, > > I have a question regarding proper choosing of traffic selectors in the > situation where an initator is behind a NAT device. Let us use the following > scenario: > > [initia...@a]--[nat@x]----------------[respon...@y] > > Say A is 192.168.2.22, X is 192.168.3.5 and Y is 192.168.4.25, and all have > a 24bit mask. The initiator policy requires traffic selectors for the whole > subnet. In the case that A is initiating: > TSi 192.168.2.0 to 192.168.2.255 > TSr 192.168.4.0 to 192.168.4.255 As these are subnets, I assume this is tunnel mode not transport mode. > Y does not know about 192.168.2.* but only about 192.168.3.*. So when it > receives TSi it does not match with anything it knows about. Should the > responder just accept these due to NAT being previously detected, or should > the initiator send selectors with address A (TSi) and Y (TSr) and due to > there being NAT the responder just copy them in the reply? The Y should be configured to accept 192.168.2.0/24 as this is tunnel mode and packets exiting from the tunnel will have those addresses as their source address. NAT does not change this, it only affects the gateway address, i.e only the outer IP address of the ESP packet. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
