Syed Ajim Hussain writes: > > > 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,
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. > 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?? 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. > If RFC is not clear about such Solution, then we can have one RFC > To solve this scenario. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
