Subject: [IPsec] Some IPSEC/IKE NAT Issues

From: Syed Ajim Hussain <[email-masked]>
Date: Mon, 28 Dec 2009 17:51:49 +0530

Hi All 
    I have some doubt about NAT With IPSEC/IKE , 
     
  Example Take a Topology : 

  IKE_PEER1  ----------- NAT1 ----------------NAT2 Server---IKE_PEER3  
  (1.1.1.1)   |  (1.1.1.10)  (2.1.1.1)  (2.1.1.2)           (3.1.1.1)    
              |
  IKE_PEER2   |
  (1.1.1.2)                       

  IKE_PEER1 and  IKE_PEER2 ,  behind Same NAT Device NAT1 ,  Want to 
  Establish IPSEC Tunnel with   IKE_PEER3, which is Behind a NAT Server ( 
  Service Running Behind a NAT). 

  For IKE_PEER1, IKE_PEER2, NAT2 Server Address (2.1.1.2) is the Peer 
  Address, Since IKE_PEE3 running behind a NAT Server. 

Questions1:   

 1. For IKE_PEER3, 2.1.1.1   is the Peer Address for both IKE_PEER1 & 
    IKE_PEER2. If IKE ID Type is IP Address then, how IKE SA can be 
    Established, between IKE_PEER1& IKE_PEER3 and IKE_PEER2 & IKE_PEER3,  

2.   If ID Type is based on Name (FQDN), Say IPSEC Tunnel is 
     Established Between IKE_PEER1 & IKE_PEER3.  If IPSEC SA Mode is 
     Tunnel,  Now Inner IP Header may have Destination IP Address as NAT2 
     Server's Address that is (2.1.1.2).  This Original IP Packet will be a 
     payload of IPSEC Encapsulated  packet.  

     Since NAT2 Server, will Change only Outer IP Header Destination 
     Address, to Forward the packet to IKE_PEER3.  

     Now in   IKE_PEER3 after IPSEC Decapsulation, original Packet will  
     Have 2.1.1.2 (NAT Server's Address) as Destination Address.  Now How 
     This packet can be processed in IKE_PEER3.  

     Does tunnel Mode Can not be supported in such Topology??   

     If RFC is not clear about such Solution, then we can have one RFC  
     To solve this scenario.  

With Regards
Syed Ajim    

****************************************************************************
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient's) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

***************************************************************************

---

From: Raj Singh <[email-masked]>
Date: Mon, 28 Dec 2009 18:29:27 +0530

Hi Syed,

On Mon, Dec 28, 2009 at 5:51 PM, Syed Ajim Hussain <[email-masked]>wrote:

> Even though IKE_PEER3 sees same IP address for IKE_PEER1 and IKE_PEER2, the
source port will be different to distinguish the connections.

> The IKE_PEER3 can forward these packets to NAT device as they are not
destined to it.

> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
>

Regards,
Raj

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 29 Dec 2009 13:26:38 +0200

>   IKE_PEER1  ----------- NAT1 ----------------NAT2 Server---IKE_PEER3  

ID type does not matter, as it is used for authentication purposes,
not for verifying that the source address of IKE packets match. If IP
addresses are used in the ID payload, then the IKE_PEER1 and IKE_PEER2
will be using their own internal IP-address (1.1.1.1 and 1.1.1.2) not
the IP address of the NAT box. 

On the other hand the IKE SPIs are used by the IKE_PEER3 to find the
correct IKE SA, and when it is sending reply back it will reply to the
same IP-address and port where the request came from, so that way the
NAT1 can forward IKE packet back to the IKE_PEER1 or IKE_PEER2.

>      Does tunnel Mode Can not be supported in such Topology??   

Tunel mode can be supported, but he IKE_PEER3 needs to get packets
which are meaningful for it. For example normal setup would be so that
IKE_PEER1 and IKE_PEER2 will request IP address from IKE_PEER3, and
then they will assign that address to virtual interface and use that
address to talk to the IKE_PEER3 (using real address of IKE_PEER3, not
the address of NAT2), or to the hosts behind IKE_PEER3 (i.e. where
IKE_PEER3 can forward packets to).

The RFC3948 has some text about these issues, and even more about the
problems with multiple clients behind same NAT in its section 5 and
Appendix A. 

-- 
[email-masked]