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

Understanding Contrail Source Network Address Translation (SNAT)

0

0

Article ID: KB34420 KB Last Updated: 28 May 2019Version: 1.0
Summary:

Contrail supports Source Network Address Translation (SNAT) to allow traffic from a private network to go out to a public network using a public source IP. This article provides a detailed description of Contrail SNAT, including a flow analysis.

For an example of SNAT configuration, refer to KB34419 - Contrail Source Network Address Translation (SNAT) configuration and verification.

Solution:

When SNAT is configured in Contrail, VMs launched on a private network can send packets to a public network without exposing its own IP address by going through a gateway service instance. Contrail is able to automatically create a special type of service instance as the SNAT gateway, which is not related to any VM images. The service instance is indeed a linux network namespace created on a vRouter, with rules to SNAT traffic between its two interfaces. One interface is in an automatically generated network with a name starting with snat-si-left_snat_. The other interface is in the public network. 

As seen in the following example, a service instance is automatically created to act as a SNAT gateway between VN-PRIVATE (10.10.1.0/24) and VN-PUBLIC (200.200.0.0/24). A corresponding network with a name starting with snat-si-left_snat_ (100.64.0.0/29) is also created automatically.


There's a default active-standby HA mode for the gateway service instance. Two compute nodes are randomly selected to host the active and backup gateway. In our testbed, there are 3 compute nodes; node14, node15 and node16. Using the 'ip netns' command, we can verify that there's an active gateway and a backup gateway. The active gateway is in node16.

root@node16:~# ip netns
vrouter-c04452b4-eab5-4b52-b775-514205def2c5
root@node15:~# ip netns
vrouter-0a0e8f9f-4a80-4f98-9489-d18ff30a0481

We can also verify the HA mode by looking at the interfaces in the two vrouters. The same IP addresses are assigned to the left and right interfaces to the two gateways: 100.64.0.4 for the left interface and 200.200.0.3 as the public IP address. 


 

The generated active gateway replaces the source IP of the originating packets with its own public side IP (200.200.0.3 in this example). Since there's only one public IP for address translation, the source port is also updated to facilitate multiple connections from different private VMs to the public network. We can verify this by initiating two flows -- one from private-vm1 (10.10.1.4, hosted in node16) to the public-vm (200.200.0.4, hosted in node14)  with 10 packets and the other from private-vm2 (10.10.1.5, hosted in node15) to the public-vm with 8 packets. By examining the flows in node14 which hosts the public-vm, we can see that both traffic are SNATed with different port numbers (45569 and 40961). Both incoming flows come from node16 (10.168.10.16), which hosts the active SNAT gateway, even though the two private vms are hosted in different compute nodes. 
 

root@node14:~# flow -l

Flow table(size 80609280, entries 629760)


Entries: Created 76 Added 76 Deleted 56 Changed 56 Processed 76 Used Overflow entries 0

(Created Flows/CPU: 5 19 3 5 4 2 3 0 0 5 0 3 14 6 1 6)(oflows 0)


Action:F=Forward, D=Drop N=NAT(S=SNAT, D=DNAT, Ps=SPAT, Pd=DPAT, L=Link Local Port)

Other:K(nh)=Key_Nexthop, S(nh)=RPF_Nexthop

Flags:E=Evicted, Ec=Evict Candidate, N=New Flow, M=Modified Dm=Delete Marked

TCP(r=reverse):S=SYN, F=FIN, R=RST, C=HalfClose, E=Established, D=Dead


    Index                Source:Port/Destination:Port                      Proto(V)

-----------------------------------------------------------------------------------

    79908<=>343052       200.200.0.4:45569                                   1 (1)

                         200.200.0.3:0    

(Gen: 1, K(nh):25, Action:F, Flags:, QOS:-1, S(nh):25,  Stats:10/980,

SPort 52554, TTL 0, Sinfo 3.0.0.0)


   136612<=>491760       200.200.0.3:40961                                   1 (1)

                         200.200.0.4:0    

(Gen: 1, K(nh):25, Action:F, Flags:, QOS:-1, S(nh):18,  Stats:8/784,  SPort 63784,

TTL 0, Sinfo 10.168.10.16)


   343052<=>79908        200.200.0.3:45569                                   1 (1)

                         200.200.0.4:0    

(Gen: 1, K(nh):25, Action:F, Flags:, QOS:-1, S(nh):18,  Stats:10/980,

SPort 64447, TTL 0, Sinfo 10.168.10.16)


   491760<=>136612       200.200.0.4:40961                                   1 (1)

                         200.200.0.3:0    

(Gen: 1, K(nh):25, Action:F, Flags:, QOS:-1, S(nh):25,  Stats:8/784,  SPort 53993,

TTL 0, Sinfo 3.0.0.0)
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