I figured I should at least once title my article IT related. The heading is a command in Linux and it offers an overview about the currently implemented NAT rules (when executed as root or with sudo permissions). It was an essential part of my testing routine:
if (newIdeaForARule=true) {
Implementing a new rule –> iptables -t nat -L (ensuring the rule was successfully recognized) –> testing the new rule –> new rule fails –>
deleting the new rule –> iptables -t nat -L (ensuring the rule was successfully deleted)
}
else
iptables -t nat -L (act of desperation, no purpose at all)
This very accurate sequence plan resulted in me using this command a lot. What did I need it for? It was vital for my (probably) last work project here at DATACTICS. I needed to implement a NAT (Network Address Translation)-Gateway, more precisely also a PAT (Port Address Translation)-Gateway for the AWS cloud. The configuration seemed to be easy but a bit messy. AWS had to be configured accordingly; Security groups, route tables and a gateway had to be created. Next up was the configuration on the command line of the Gateway. Because of the AWS environment, the configuration process ended up being a mesh of using the AWS GUI and the Linux CLI. A lot of options that actually had to be configured on the CLI of the machine were forfeited by AWS. But this wasn’t the root of my problem, it was the NAT rule.
It’s very easy when you think about it: I wanted to redirect traffic entering the public IP of the NAT-Gateway on port 23435 (could have been any other number) to be redirected to the private IP address of a machine in the same net and the port 22. An example to provide a better illustration: 118.12.20.3:23435 –> 10.0.0.127:22
I experimented with a lot of different rules but always found myself thinking that this one rule should work. It made sense. It was getting a little frustrating, I started to question everything about this project. Are the ports open? Is the interface responding? Was iptables -t nat -L maybe not the most appropriate troubleshooting tool? No, that couldn’t be it.
I was in a state of despair when I randomly changed a minor option of the rule. It worked. I was taken aback. The only thing I changed was to not label the public IP address in the command. I still don’t know why the public IP wasn’t accepted. But I am glad that my original idea turned out to be (mostly) correct. After I finished implementing the rule, I found myself typing iptables -t nat -L again. Why? I’m a simple person, I want to admire my success.
