Description

Contrail supports Source NAT to allow traffic from a private network to go out to a public network using a public source IP.

This article provides an example of SNAT configuration and a simple verification.

Solution

In this example, assuming there's a private virtual network (VN-PRIVATE) with the subnet of 10.10.1.0/24 and a public virtual network (VN-PUBLIC) with subnet of 200.200.0.0/24.

The following configuration steps allow packets from VN-PRIVATE to VN-PUBLIC through a gateway which can translate the source IPs of the packets with a single public IP. 

SNAT configuration from Web UI:

  1. Check the External option in VN-PUBLIC

  2. Create a router through Configure > Networking > Routers workspace

    Enter a router Name, select external gateway (VN-PUBLIC) and connected networks (VN-PRIVATE).

    After that, a service instance will be created automatically.

  3. Check the status of the service instance in Configure > Service > Service Instance workspace

    The automatically created service instance should be in Active state. The predefined service template 'netns-snat-template ' was used.

    Another VN (name starting from snat-si-left_snat_ ) was automatically created as well.

    One thing to notice is that the service instance is not in Openstack Web UI's list of VM instance.
     

SNAT Verification:

Create a private-vm1 (10.10.0.4) in VN-PRIVATE and a public-vm (200.200.0.4) in VN-PUBLIC. 

Find the tap interface for the public-vm. 

 

Send a ping from the private-vm1 (10.10.0.4) to the public-vm (200.200.0.4) while running tcpdump on the tap interface of the private-vm1 (tapb9d2c275-3a) and the tap interface of the public-vm (tap7b9b3a8e-f8).

$ ping 200.200.0.4 -c 3
PING 200.200.0.4 (200.200.0.4): 56 data bytes
64 bytes from 200.200.0.4: seq=0 ttl=62 time=9.717 ms
64 bytes from 200.200.0.4: seq=1 ttl=62 time=6.170 ms
64 bytes from 200.200.0.4: seq=2 ttl=62 time=4.711 ms
 
--- 200.200.0.4 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 4.711/6.866/9.717 ms
 
root@node14:~# tcpdump -i tapb9d2c275-3a
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tapb9d2c275-3a, link-type EN10MB (Ethernet), capture size 65535 bytes
10:54:58.530837 IP 10.10.1.4 > 200.200.0.4: ICMP echo request, id 41473, seq 0, length 64
10:54:58.552738 IP 200.200.0.4 > 10.10.1.4: ICMP echo reply, id 41473, seq 0, length 64
10:54:59.534881 IP 10.10.1.4 > 200.200.0.4: ICMP echo request, id 41473, seq 1, length 64
10:54:59.538631 IP 200.200.0.4 > 10.10.1.4: ICMP echo reply, id 41473, seq 1, length 64
10:55:00.535428 IP 10.10.1.4 > 200.200.0.4: ICMP echo request, id 41473, seq 2, length 64
10:55:00.536560 IP 200.200.0.4 > 10.10.1.4: ICMP echo reply, id 41473, seq 2, length 64

root@node16:~# tcpdump -i tap7b9b3a8e-f8
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tap7b9b3a8e-f8, link-type EN10MB (Ethernet), capture size 65535 bytes
10:54:58.549797 IP 200.200.0.3 > 200.200.0.4: ICMP echo request, id 41473, seq 0, length 64
10:54:58.550790 IP 200.200.0.4 > 200.200.0.3: ICMP echo reply, id 41473, seq 0, length 64
10:54:59.535936 IP 200.200.0.3 > 200.200.0.4: ICMP echo request, id 41473, seq 1, length 64
10:54:59.538023 IP 200.200.0.4 > 200.200.0.3: ICMP echo reply, id 41473, seq 1, length 64
10:55:00.536171 IP 200.200.0.3 > 200.200.0.4: ICMP echo request, id 41473, seq 2, length 64
10:55:00.536359 IP 200.200.0.4 > 200.200.0.3: ICMP echo reply, id 41473, seq 2, length 64
 

We can see that SNAT is functioning properly because the source IP address for the ICMP echo request is 200.200.0.3 (which is the public IP address assigned to the SNAT service instance). The original source IP 10.10.0.4 has been translated.