Linux Networking — SNAT and Packet Forwarding to Connect to Internet From Namespace| Part 4

A Nerdy Guide to Understand Linux/Docker/Container Networking | Part 4

Photo by Brian Wangenheim on Unsplash

Table Of Contents

• Intended Audience
• Learning Structure
• Mode of Learning
• Outcome of Learning
• IP Tables
• NAT
• SNAT
• Packet Frowarding
• Successful Egress Traffic (device to internet)
• Series Learning Recap
• Test Yourself
• Home Work
• Conclusion

Intended Audience, Learning Structure, Mode of Learning

As this is the part 4of the Linux networking series, for Intended Audience, Learning Structure and Mode of Learning, please do visit the first part [here].

Recap of the Third Part

In the [third part] of the Linux networking series, we covered —

• The theory and internal working of bridge communication.
• Understood the different contexts of “Network is unreachable” and “Destination Host Unreachable.”
• Understood the theory and internal working of Default Gateway.
• Setup bridge and Default Gateway for Simplex communication.

The third part included a few “Test Yourself” exercises and one homework tasks. In this fourth part, we will try to solve the challenges from [part three].

If you haven’t read [part three] yet, I highly recommend completing it first. This part assumes you have already done the steps covered in [part three].

Problem Definition from Third Part

In the third part, we configured —

• A bridge and added the other end of the veth to it.
• Local network communication within 192.168.1.0 was successful.
• To enable communication with networks outside 192.168.1.0, we added a default gateway in the namespace.
• Adding the default gateway solved the issue, allowing us to ping networks beyond 192.168.1.0.

Then we wanted to —

• Ping Google’s DNS (8.8.8.8).
• Access any IP on the internet.

The issue we faced —

• The ping was unresponsive.
• There was no reply, and the request was stuck.

ping from namespace to google

tcpdump of bridge that shows packets are reached to the host

Understanding the Problem —

• When we ping 8.8.8.8 from the namespace, the packet’s source IP is the namespace’s private IP.
• The packet leaves the host machine and reaches Google.
• Google replies with a response packet, but it has the namespace’s private IP as the destination.
• The returning packet gets lost because network devices in between do not know where to route a private IP.
• The private IP is not recognized on the public internet, so the response never reaches the namespace.

The Solution —

To solve this, we need to use NAT (Network Address Translation).

• IPv4 uses NAT, while IPv6 has different mechanisms (SLAAC and NDP)
• There are two types of NAT: SNAT (Source NAT), also known as Masquerade Action and DNAT (Destination NAT).
• We will use SNAT (Source Network Address Translation) or Masquerade Action.

How SNAT Helps

• SNAT replaces the private namespace IP with a public IP before sending the packet.
• This allows the packet to reach the internet and return back to the host.
• We will also add a rule in iptables to ensure the packet is accepted by the operating system.
• Once the host machine receives the response, it can route it back to the correct namespace.

This will allow the namespace to successfully ping Google and access the internet.

Understand A Packet Journey with SNAT from Namesapce

A. Namespace —

• The namespace sends an ICMP echo request (ping) to 8.8.8.8.
• The source IP is the namespace’s private IP (for example, 192.168.1.2), and the destination IP is 8.8.8.8.

B. Host Network Stack —

• The packet reaches the host machine’s network stack.

C. SNAT/Masquerading —

• The host’s SNAT rule modifies the packet. It replaces the source IP (192.168.1.2) with the host’s public IP address (eg, 10.10.10.118).

D. Internet —

• The modified packet travels through the internet to Google’s name server (8.8.8.8).

E. Google’s Response —

• Google responds with an ICMP echo reply. The source IP is 8.8.8.8, and the destination IP is the host’s public IP (10.10.10.118).

F. Host Network Stack —

• The response packet arrives at the host machine.

G. Reverse Translation —

• The host’s SNAT mechanism recognizes the packet and performs the reverse translation.
• It replaces the destination IP (10.10.10.118) with the original private IP of the namespace (192.168.1.2).

H. Namespace —

• The host forwards the packet to the namespace via the bridge and veth interface.
• The namespace receives the ping response.

Implement the Solution

Now that we understand the problem, the solution, and how it works internally, let’s implement it in the namespace and test it ourselves.

We will continue from where we left off in [Part Three]. If you haven’t completed it or missed any section, I highly recommend going through [Part Three] first.

To quickly recall what we covered, refer to the Recap of the Third Part at the beginning of this post.

The solution is to add SNAT in the iptable rules

Let’s add SNAT on the Host Machine

Run the following command on your host machine

sudo iptables -t nat -A POSTROUTING -s 192.168.1.0/24 -j MASQUERADE

Explanation

-t: table

• IP table has various tables, and with -t tag, we are defining which table we would interact.
• We are explicitly defining the table as nat.

-A: Append

• We are appending a rule in POSTROUTING chain in the IP table named nat .
• This ensures that outgoing packets are modified after routing but before leaving the system.
• We have already dicussed about IP tables in our first part of this series, if you’ve happen to miss, plese take read it [here].

-s: Source

• Define the source IP range
• We are definining the source IP range as 192.168.1.0/24 i.e. the subnet of the namespace.

-j: Action

• Which action to take
• The action is to take is MASQUERADEwhich is SNAT in other term.
• Applies SNAT (Source Network Address Translation) by dynamically replacing the private namespace IP with a public IP (Host’s IP).

This step allows packets from the namespace to go out to the internet by modifying their source IP.

Accept the Returned Packets in the Bridge

Since we have changed the source IP to a public IP (using SNAT), we also need to accept returning packets and correctly forward them to the namespace.

Now, we need to forward the traffic to the corrent interface, and we need to add some rule.

Rune below two rules for this case —

sudo iptables --append FORWARD --in-interface br0 --jump ACCEPT 

sudo iptables --append FORWARD --out-interface --jump ACCEPT

Explanation

--append FORWARD

• Adds a rule to the FORWARD chain to control packet forwarding.

--in-interface br0

• Allows incoming traffic from the bridge (br0).

--out-interface br0

• Allows outgoing traffic to the bridge (br0).

--jump ACCEPT

• Ensures that packets passing through the bridge are accepted.

Test the connecption

Now, try pinging Google (8.8.8.8) or any external IP from the namespace:

ping 8.8.8.8

If everything set up correctly, the ping to google or any external IP from namespace is successful. You’d see the reply is being received into the private network namespace!

a successful ping from namespace after configuring NAT

tcpdump of bridge from host that demonstrates the packets behabiour after configuring NAT

What We Have learnt in this Series

Let’s summarize the key takeaways from this series in a concise manner.

A. Want Only Container/Namespaces Communication?

Yes.

• Devices in the same IP range (subnet) can communicate.
• If you want containers/namespaces to communicate, place them in the same subnet and connect them with a bridge.
• If you get “Destinatoin Host Unreachable”, your network configuration is likely correct, but —
• Check the IP address you are trying to reach.
• Ensure the host is active and ready to accept communication.

B. Need to Communicate With Another Subnet From the Namespace?

Yes.

• If you want to communicate with the host machine, it is in a different subnet than the namespace.
• You need to assign a Default Gateway.
• Add the bridge as the default gateway for all namespaces. This ensures that any communication outside the namespace subnet is forwarded correctly.
• If the default gatway is not set, you may get the error —
• “Netwrok is unreachable.”

C. Need to Connect to the Internet From a Namespace?

Yes.

• Private IPs cannot communicate directly with the internet.
• You need a public IP address to receive responses from external servers.
• To enable internet access from a namespace —
• Configure SNAT (Source Network Address Transaltion) in iptables.
• Forward packets to the correct bridge network from the host machine.
• If SNAT is not configaured, you may notice —
• Ping gets stuck with no response.
• Running tcpdump on the bridge shows packets leaving the host but no packets retunring.

Home Work

The homework is simple:

• Explore NAT and packet forwardingng rules used in this session.
• Understand teh detailed meaning of the commands.
• Learn about iptables tables, chains, firewalls, and how they work together.

Conclusion

I hope this series was exciting for you. I love networking and Linux, but what I enjoy even more is sharing knowledge.

This was a small effort from my side to share what I know.

Let’s wrap up here. See you in another exciting series!
Until then, keep grokking.