Firewall only allows port 443 traffic, but have multiple servers in the backend listening on different ports

firewalliisport-forwarding

I am a software dev by trade, and I think I might be missing a big feature here that I am not familiarise with.

In my developer PC, I have an app that uses a website hosted by my local IIS server on port 443, a https website. Then I also have another part of the software having a java process listening on another port, 8443. They are both up and running.

But in front of me in the real production environment is a firewall that only allow traffic going through port 443, which is default to https traffic. I have worked a way out to have my java application to send/receive https traffic that wraps up my application native/default traffic type, so that I don't have to worry about the firewall only allows certain types of application traffic coming in/out.

The question is, how can I configure the firewall or my PC so that it knows to forward traffic from one port (443) to different ports on my pc? So think of this situation where all traffic is coming to port 443 on the firewall, but after that I want it to direct traffic to port 443 IIS server and 8443 myJavaAppListener, what should I do to enable this?

Best Answer

You cant do this in a (regular/typical/iptables or similar based) firewall, you would need some kind of proxy/load-balancer. The "firewall equivalent" device would actually need to terminate the connection (and have the appropriate certificates for all domains in the case of HTTPS) and then create a connection to the real server and proxy the traffic.

Of-course this is job does not need to be done by the router - you can set up a proxy (using Apache + mod_proxy is one common way of doing this), then forward all port 443 traffic traversing your router to the proxy, and have the proxy manage this internally. This is a fairly typical arrangement.

Additional as per request

A TCP stream has a source and destination IP port. As requests need to come from all IPs and any port, all thats left to discriminate on is the destination IP (which is a single IP) and port (of which there is only one). This means that examining the packet wont let us know the destination and thus iptables is not sufficient.

The solution is to terminate the connection and then read the HTTP header which advises the requested resource, including (for HTTP/1.1 and later) and then act as a man in the middle.