Tag: iptables

I recently heard about a case where someone wanted to allow an AWS EC2 instance on a public IP address to access a corporate intranet resource. Their solution was to run an HAProxy server on the corporate network that could proxy traffic from the AWS compute instance to the intranet server.

Whether or not accessing intranet resources from an external host is good idea or violates corporate policy I will leave aside for now, but I thought of 6 additional ways to accomplish the same objective.

What follow is one of those 6 ideas: using Network Address Translation (NAT) on the intermediary host via nftables. I have spent far more time with iptables than I have with nftables. But this seemed like a good opportunity to experiment.

The 3 servers for this example:

1. The corporate intranet resource, intranet.osric.net or 192.0.2.43
2. The NAT host, nat.osric.net or 198.51.100.200
3. The AWS EC2 instance, ec2-203-0-113-155.compute-1.amazonaws.com or 203.0.113.155

The nat.osric.net server is running RHEL 10, although the commands should work on other systems using nftables.

I followed the steps provided by Configuring destination NAT using nftables on nat.osric.net:

sudo nft add table nat
sudo nft -- add chain nat prerouting { type nat hook prerouting priority -100 \; }
sudo nft add chain nat postrouting { type nat hook postrouting priority 100 \; }

The next commands needed the interface name, which I found using nmcli device status (ens5 in this case).

sudo nft add rule nat prerouting iifname ens5 tcp dport { 80, 443 } dnat to 192.0.2.43
sudo nft add rule nat postrouting oifname "ens5" snat to 198.51.100.200
echo "net.ipv4.ip_forward=1" | sudo tee /etc/sysctl.d/95-IPv4-forwarding.conf
sudo sysctl -p /etc/sysctl.d/95-IPv4-forwarding.conf

It worked! Well, with a couple caveats: an issue with the TLS certificate, and a wide-open NAT configuration.

The TLS certificate

From the EC2 instance:

$ curl https://198.51.100.200
curl: (60) SSL: no alternative certificate subject name matches target host name '198.51.100.200'
More details here: https://curl.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

I could think of a few ways around this:

• Add an entry to /etc/hosts on the client, i.e. on ec2-203-0-113-155.compute-1.amazonaws.com
• Ignore the warning, e.g. curl --insecure https://198.51.100.200/
• Add a subject alternative name (e.g. nat.osric.net) to the TLS cert for intranet.osric.net

The last method, adding a Subject Alternative Name (SAN) sounded like a pain, and also may not be feasible if you don’t manage the TLS certificate for that host. And I never like ignoring security warnings. But editing the /etc/hosts file was a simple solution that worked. Here’s the line I added to the EC2 instance (ec2-203-0-113-155.compute-1.amazonaws.com):

198.51.100.200   intranet.osric.net

After that, I was able to use curl https://intranet.osric.net/ to return content without errors or warnings.

The wide-open NAT

The configuration, as implemented, could allow anyone on the Internet to bypass the network security controls around intranet.osric.net. All they have to do is visit nat.osric.net (and maybe ignore some TLS warnings). This is terrible! Fortunately, we can use nftables to limit NAT to only specific inbound traffic.

How can I review what has already been added to nftables? Fortunately, Quick reference-nftables in 10 minutes was helpful here.

$ sudo nft list tables
table ip nat
$ sudo nft list chains
table ip nat {
        chain prerouting {
                type nat hook prerouting priority dstnat; policy accept;
        }
        chain postrouting {
                type nat hook postrouting priority srcnat; policy accept;
        }
}
$ sudo nft list ruleset
table ip nat {
        chain prerouting {
                type nat hook prerouting priority dstnat; policy accept;
                iifname "ens5" tcp dport { 80, 443 } dnat to 192.0.2.43
        }

        chain postrouting {
                type nat hook postrouting priority srcnat; policy accept;
                oifname "ens5" snat to 198.51.100.200
        }
}

In order to delete the dnat rule, I needed its handle. To get this, I used the -a flag:

$ sudo nft -a list ruleset
table ip nat { # handle 1
        chain prerouting { # handle 1
                type nat hook prerouting priority dstnat; policy accept;
                iifname "ens5" tcp dport { 80, 443 } dnat to 192.0.2.43 # handle 8
        }

        chain postrouting { # handle 2
                type nat hook postrouting priority srcnat; policy accept;
                oifname "ens5" snat to 198.51.100.200 # handle 9
        }
}

I deleted handle 8:

sudo nft delete rule nat prerouting "handle 8"

And added a new prerouting rule:

sudo nft add rule nat prerouting iifname ens5 ip saddr 203.0.113.155 tcp dport { 80, 443 } dnat to 192.0.2.43

That provides NAT for only the EC2 instance at 203.0.113.155.

The thing that I like about this solution is that it requires no new software. It uses the networking functionality that is already present on the host. However, unless you take additional steps, there is virtually no logging. nftables can log messages to syslog for packets that match the DNAT rule, but even that is very different than the level of logging that a proxy server would provide.

References:

• How can I port forward with iptables? (serverfault.com)
• Configuring destination NAT using nftables (docs.redhat.com)
• Quick reference-nftables in 10 minutes (wiki.nftables.org)
• The man page for nft

During some initial testing, I was using another EC2 instance as the NAT server and it did not work immediately. That’s because the EC2 instance was not aware of its own public IPv4 address, it was only aware of its private IPv4 address: 172.31.15.224. Removing the SNAT rule for the public IP address and adding a new SNAT rule for 172.31.15.224 solved that.