Corporate firewalls can be a pain, you could well drown in a sea of red tape and meetings just to route traffic across any port but port 80 and 443. In this post we avoid swimming upstream, and go with the port 80 and 443 flow in a system level quality assurance testing scenario with a simple iptables rules.
Before we get onto the iptables rules, here is the exact scenario to give this post context.
- We have a system under test, which has a public IP address, and a remote test server which also happens to have a public IP address.
- The system under test accepts REST calls on port 443, that is we are dealing with HTTPS traffic.
- The system under test, in response to REST calls, will fire asynchronous REST callbacks to our remote test server, so we are dealing with bi-directional communication.
- A corporate firewall dictates that the asynchronous REST callbacks can only happen on port 80 or on port 443.
- Our remote test server already has a service running on port 80, so our HTTP listener, that waits for incoming REST callbacks, will have to run on another available port, say 8009.
So, here is the configuration that we will have to do on our test server.
# For a manual check of the rule below, run $sudo nc -l -v 8009 then ssh into the remote host (303.66.500.90) and execute $nc -v -z 55.333.536.4 iptables -t nat -I PREROUTING 1 -p tcp -s 303.66.500.90 --dport 80 -j REDIRECT --to-port 8009
Please note that the IP addresses where randomly generated. The rule above means that on our test server (with mentioned IP address 55.333.536.4), we’ll route traffic from our system under test (with IP address 303.66.500.90) on port 80 to port 8009. Presumably our test HTTP listener will be listening on port 8009.
Thats it, its working for me, hope it does for you too.