Please wait...
One other thought I had, which I use often is to do those types of translations at the router level. I guess to give a proper answer, I would need to know more about the environment (like why not just set your apache to listen on 8443 if it is security through obscurity?) also, If it is your local network access which you are concerned with or just outside connections. Those things make a difference with what method you use. You can get really technical and set up an stunnel listener on the 8443 and have it route to localhost (either directly, or through some fancy /etc/hosts file entries ) to your 443 port.
I agree about the Static IP vs Dynamic. One other thing to consider is that every dynamic IP is on a block list if you plan on running a mail server, so expect for your messages to get rejected by at least half of the servers out there.
Computers are much smarter at scanning than we are, but also, most of the time are just after the low lying fruit. Port knocking does have a way of thwarting them, when combined with firewall rules which denote which IP addresses the connection requests can come from, etc.
I suppose we have to get this out of the way: why are you trying to tackle this problem using port forwarding? Most server programs can be told to listen on a variety of interface:port combinations.
If you really must forward, and if the protocol being used is HTTP or HTTPS, then maybe you could consider running an nginx proxy as a connection multiplexer.
If you do that it can handle things like SSL offload for you as well.
In this situation, the person gains a full virtual machine that they can alter with as many network adapters configured however they want.
The people who would use this product might have unusual security conditions that may require peculiar network environments. If I can provide a flexible environment that lets them connect to the product however they wish (whatever port they want, etc), then the product becomes more appealing to them.
The only possible problem with stunnel is that it forces SSL. But, we force it anyway, so I don't view that as a serious impediment; we don't really want this information openly viewable via wireshark or the like.
I can indeed tell apache2 to listen to specific ports and specific adapters, but I don't know how well it listens to multiple ports/adapters configured in wildly different ways (e.g. 10.1.0.41:9123 & 192.168.1.23:443). Or, for that matter, if it's relatively simple to program such configurations. I can research it, though.
Port forwarding just seemed like it would work easily via iptables, but considering that stack overflow (or, as they call it now, superuser) has had a question similar to this for 5 years left unanswered, perhaps this isn't as easy an approach as I expected.
Hmm... nginx proxy... I can look at that, too.
Huh... actually, apache2 does support doing exactly what I want.
I have to modify two files to do it instead of just one, but it is possible to specify multiple ip/port combinations for a single <VirtualHost>.
You can also mess around with ipv6.
This is probably the most straightforward way to address this problem.
It's a trifle annoying, though, having to handle two configuration files instead of one, but, eh... whatever.
It is not uncommon to distribute an appliance with a front end web server installed to handle proxy, caching, security, and even connection pooling.
This appliance interfaces via web (both for a UI and services).
I just figured using forwarded ports would work more easily than having to reconfigure a web server, but it seems I am wrong.
depends on who's wisdom your listening to. that's certainly the latest trend.
too many public docker base-images have unpatched security holes.
We've considered the use of Docker for a different purpose... putting an arbitrary number of these things on one box, and forwarding from one to all of them simultaneously.
Sadly, though, we can't distribute this as a Docker image, as we can't let people have access to the code. If we were open-sourced, it wouldn't be a problem.