Using IPTables to forward packets

Preface

Although I’m quite comfortable working with IPTables, I didn’t do as well as expected on that section during my LFCS practice exam. Of course, I know my chains and how to block all traffic except for specific exceptions. I also know how to use an ipset list to block unwanted IP ranges, which is way faster than manually setting up multiple rules. But the area where I stumbled was traffic forwarding.

I knew that IPTables could reroute traffic between interfaces, as well as between ports and IPs. I’ve set it up dozens of times, but usually with a bit of help from Google—especially when troubleshooting when things didn’t go as planned. However, during the exam, you can’t rely on Google; you have to figure it all out on your own, which makes things a lot trickier.

To get more confident with IPTables, I’ve decided to stop using 'UFW' almost entirely and have switched to using plain IPTables. I also came up with a fun little project to practice forwarding and rerouting traffic to another server.

Scenario

For this project, I’m working with three servers. The issue I need to solve is that the app1 server needs to connect to the db1 server to retrieve important data for its application. However, due to security policies, the only way to access db1 is through a gateway, gw1.

In a real-world scenario, these servers could be on different VLANs. For example, the db1 server might be in a separate VLAN from app1, which adds an extra layer of isolation (layer 2 instead of just layer 3). In my setup, I’ve placed them on the same VLAN and within the same IP range, but I’ve isolated them as much as possible using firewall rules. For instance, the db1 server drops all traffic except for certain connections from gw1. App1 can’t directly access db1, and the reverse is true as well.

Server overview

Current Firewall(s)

We’re starting with identical firewall configurations on all three servers. Here's the setup:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Allow loopback interface
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow all connections from Trusted VLAN
-A INPUT -s 10.50.0.0/24 -j ACCEPT

# Allow ICMP (ping)
-A INPUT -p icmp -j ACCEPT

COMMIT

The configuration drops all incoming traffic except for connections from the 10.50.0.0/24 range, which allows me to connect via SSH. ICMP (ping) is also permitted for troubleshooting purposes.

Proof of concept

From the app1 server, we won’t be able to connect directly to db1:

root@app1:~# mysql -h 10.30.1.79 -u app -p
Enter password:
ERROR 2003 (HY000): Can't connect to MySQL server on '10.30.1.79:3306' (110)

As expected, the connection is blocked.

Solution

To connect to the db1 server, we need to go through the gw1 server first. IPTables will recognize this connection and reroute it to db1. For this to work, we need a few things:

• Enable 'net.ipv4_ip_forward'
• Create NAT rules
• Set up the forwarding rules
• Accept traffic on port 3306
• Allow traffic on port 3306 from gw1

Let’s walk through all the necessary steps to make this work.

The gateway server

This is the key player. It will accept traffic from app1 and reroute it to db1. By default, Linux isn’t set up to intercept and reroute packets to a different destination. To get this working, we need to enable a sysctl parameter: net.ipv4.ip_forward.

Enabling ip_forward

To enable net.ipv4.ip_forward, we’ll use sysctl. First, let’s check if it’s already enabled with this command:

root@gw1:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 0

As you can see, forwarding is currently disabled. Let’s enable it and verify that it’s set correctly:

root@gw1:~# sysctl -w net.ipv4.ip_forward=1
root@gw1:~# sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Awesome! Make sure the value is '1'. If it’s still '0', something went wrong.

Creating NAT rules

With that done, we can now focus on the NAT rules. The goal here is to manipulate network packets for routing and translating IP addresses. This is important because we’ll only accept traffic from the gw1 server on db1.

To put it simply: NAT is like a receptionist at a busy office, receiving messages (network packets) and relaying them to the right person (the correct device on your network), all while using a single public address.

Let’s define the NAT table:

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]

# DNAT rule to redirect traffic
-A PREROUTING -p tcp --dport 3306 -j DNAT --to-destination 10.30.1.79:3306

# Ensure traffic is properly NATed
-A POSTROUTING -o eth0 -j MASQUERADE

COMMIT

These rules may seem complex at first, but they’re actually straightforward. Here’s what’s happening:

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

The section above tells IPTables that we’re working with the NAT table. The rules for PREROUTING, POSTROUTING, and OUTPUT define the necessary chains. If a packet doesn’t match any rule in the chain, it’s accepted by default (hence the ACCEPT policy).

# DNAT rule to redirect traffic
-A PREROUTING -p tcp --dport 3306 -j DNAT --to-destination 10.30.1.79:3306

This is our first rule. All traffic is accepted unless it matches a condition. In this case, we’ll “ignore” traffic unless it’s a TCP connection on port 3306. If it is, we route it to 10.30.1.79 (our db1 server) on port 3306.

# Ensure traffic is properly NATed
-A POSTROUTING -o eth0 -j MASQUERADE

This rule ensures that any matched traffic exits through eth0 and is masqueraded. Masquerading means that the packet’s source IP address is rewritten as the IP of gw1 instead of app1. This way, db1 sees the traffic as coming from gw1 and accepts it.

COMMIT

The COMMIT at the end tells IPTables we’re done with the section.

Creating Filter rules

Since this post focuses on traffic routing, I’ll leave out some unrelated rules, such as those allowing traffic from the trusted VLAN or ICMP traffic. Below are the necessary filter rules:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

# Allow loopback interface
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

# Allow established and related connections
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# Allow traffic from `app1` to `db1` on port 3306
-A FORWARD -p tcp --dport 3306 -j ACCEPT

# Allow incoming traffic on port 3306
-A INPUT -p tcp --dport 3306 -j ACCEPT

COMMIT

Here’s a quick breakdown:

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [0:0]

This section defines the rules for the filter table. We drop all incoming traffic by default (INPUT DROP), as well as all forwarded traffic (FORWARD DROP). OUTPUT is set to ACCEPT, so the server can send out traffic without issues.

# Allow loopback interface
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT

Since we’re dropping all incoming traffic, we need to accept traffic from the loopback interface (127.0.0.1). This allows the server to communicate with itself, which is crucial for certain services.

# Allow established and related connections
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

These rules allow established or related connections to be accepted. Essentially, this permits traffic that’s part of an ongoing connection (e.g., responses to outgoing requests).

# Allow traffic from `app1` to `db1` on port 3306
-A FORWARD -p tcp --dport 3306 -j ACCEPT

# Allow incoming traffic on port 3306
-A INPUT -p tcp --dport 3306 -j ACCEPT

Finally, we arrived at the important rules. As you now might already know: these rules will cause traffic to be accepted. Like earlier said: IPtables will drop all traffic, except for mentioned otherwise. And, the mentioning happens here.

Any packets coming in on port 3306 will be accepted and go through the FORWARD chain. Here IPtables will look into the NAT table to see where the traffic has to go. In our case to 10.30.1.79 on port 3306: our db1 server.

The database server

Finally, we need to configure the db1 server. By default, it’s still blocking connections to port 3306. We’ll add a rule to allow traffic from gw1:

# Allow database connections from gw1
-A INPUT -p tcp -m tcp -s 10.30.1.78 --dport 3306 -j ACCEPT

Here, we’re allowing traffic from 10.30.1.78 (the gw1 server) that’s destined for port 3306. This should be everything.

Proof of concept 2.0

So. After reading along and adding all those rules we've finally arrived to the definitive test. Will we be able to connect on MySQL, on db1, from app1? Let's see.

root@app1:~# mysql -h 10.30.1.78 -u app -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or \g.

Yes! We are able to connect with the database server on db1. Just to let you all know that there is no database server running on gw1 :)

root@gw1:~# dpkg -l | grep -i 'mysql\|mariadb'
ii  mysql-client                    8.0.39-0ubuntu0.24.04.2                 all          MySQL database client (metapackage depending on the latest version)
ii  mysql-client-8.0                8.0.39-0ubuntu0.24.04.2                 amd64        MySQL database client binaries
ii  mysql-client-core-8.0           8.0.39-0ubuntu0.24.04.2                 amd64        MySQL database core client binaries
ii  mysql-common                    5.8+1.1.0build1                         all          MySQL database common files, e.g. /etc/mysql/my.cnf

For troubleshooting sake, there is a MySQL client installed. But there is of course no server!

In conclusion

Using IPTables to re-route incoming traffic is definitely a great way to centralize access to network resources. It also simplifies logging and monitoring. If you ever need to troubleshoot, you can easily track the traffic flow at the network level (Layer 3 and Layer 4). You'll be able to see where packets are coming from and where they’re headed. This kind of visibility can be really valuable.

In this post, we created a gateway that picks up connections on its local port (3306) and forwards them to another server. While this method works well for our case, I believe using a Layer 4 tool like HAProxy—or even better, MaxScale for databases—might be a more efficient solution since both also operate at Layer 7.

For instance, with HAProxy, you can define multiple backends and load balance between different database servers, something IPTables can't do. Additionally, you can set up ACLs for added security, filtering traffic before it even reaches the backend. This provides a lot more flexibility.

But, of course, this post exists because I struggled with IPTables during my LFCS practice exam, so it was a fun experiment for me to dive into!