Support Support Downloads Knowledge Base Juniper Support Portal Community

Knowledge Base

Search our Knowledge Base sites to find answers to your questions.

Ask All Knowledge Base Sites All Knowledge Base Sites JunosE Defect (KA)Knowledge BaseSecurity AdvisoriesTechnical BulletinsTechnotes Sign in to display secure content and recently viewed articles

[CSO] Understanding controller-based DVPN workflow for a CPE-behind-NAT scenario

0

0

Article ID: KB36876 KB Last Updated: 29 Nov 2021Version: 1.0
Summary:

This article describes the workflow that is used to detect supported NAT scenarios in a CPE-behind-NAT environment while creating a controller-based DVPN. In this case, Contrail Service Orchestration (CSO) acts as a controller to auto-detect NAT and NAT Type, and accordingly push configurations on the peer side to implement DVPN. 

Solution:

When the underlay interfaces for a CPE are behind NAT, then the overlay site-to-site IPsec tunnel can be established over them by using UDP hole punching.

At the nat-router:

  • If the nat-ipaddr and nat-port mapping for an underlay interface remains the same across sessions with different destination IP addresses, then the UDP hole punching will work.   

  • If the nat-ipaddr and nat-port mapping changes for every session based on the destination address, then the UDP hole punching will not work.  

In this case, it is not possible to traverse such underlay interfaces by using direct site-to-site tunnels. 

 

While implementing DVPN, CSO will discover the following NAT-related information per underlay interface:

  • natd-ipaddr

  • natd-port

  • nat-type 

To achieve the above, CSO will set up secure OAM IPsec tunnels from each WAN link that is selected for full-mesh network with the primary and secondary OAM Hubs.

CSO will then compare the information for every underlay connection at the primary and secondary OAM hub, and compute the NAT related information (two OAM Hubs are necessary for this to work).

A sample topology to build the site-to-site tunnel for the CPE-behind-NAT scenario is given below:

When an IPsec tunnel needs to be established from CPE1 to CPE2, CSO checks the NAT type of the underlay WAN interface on CPE2 before pushing the configuration on CPE1.

The following scenarios are possible:

  • If NAT is not detected (that is, a public IP address) on the CPE2 WAN interface, CSO uses the CPE2 WAN interface underlay IP address for creating the IPsec tunnels. 

  • If NAT-type is detected and is supported, CSO uses the natd-ipaddr of CPE2 (public-ip2) to initiate the IPsec session.

  • Destination NAT is performed at CPE1 to translate the network address of the IPsec packet that is destined toward CPE2 to reach port2 on the NAT2 device.

  • After the packet is received on the NAT2 router (public_ip2, port2), it is forwarded to the CPE2 IPsec client.

  • If the NAT- type detected is NOT supported, CSO does not attempt to set up an IPsec tunnel between CPE#1 and CPE#2.

A similar logic is used in the other direction, that is an IPsec tunnel setup from CPE2 to CPE1.

In summary:

NAT-Type detected by CSO 

Actions by CSO 

No NAT, that is, public IP address on WAN interface 

IPsec tunnels continue to be set up in the same way, as was prior to this feature being introduced.

Full-cone NAT or Restricted NAT 

IPsec tunnel configuration pushed by CSO takes into account any underlay NAT parameters (natd-ipaddr and natd-port).

Symmetric NAT 

CSO will not attempt to activate any site-to-site tunnels on these WAN interfaces. 

Site-to-site tunnels are marked as inactive in the UI. 

 

Full cone NAT: This is also known as one-to-one NAT. It is basically simple port forwarding where there is a static binding from the client ip:port to the NAT natd-ipaddr:natd-port, and any Internet user can write to natd-ip:natd-port and it will be forwarded to the client.  

Restricted NAT works in the same way as a full cone NAT but applies additional restrictions based on an IP address. The internal client must first have sent packets to the IP address (X) before it can receive packets from X. In terms of restrictions, the only requirement is that packets come in on the mapped port and from an IP address that the internal client has sent packets to. 

In symmetric NAT, each request from the same internal IP address and port to a specific destination IP address and port is mapped to a unique external source IP address and port; if the same internal host sends a packet even with the same source address and port but to a different destination, a different mapping is used. 

Comment on this article > Affected Products Browse the Knowledge Base for more articles related to these product categories. Select a category to begin.

Getting Up and Running with Junos

Getting Up and Running with Junos Security Alerts and Vulnerabilities Product Alerts and Software Release Notices Problem Report (PR) Search Tool EOL Notices and Bulletins JTAC User Guide Customer Care User Guide Pathfinder SRX High Availability Configurator SRX VPN Configurator Training Courses and Videos End User Licence Agreement Global Search