Redirect IP port for a container via Proxmox firewall?

[BlueLineSwinger]

Basically, I have a number of containers that run web services on non-standard ports (e.g., 8000). Is there a way, using Proxmox's own firewall, to redirect connections such that a user could access the service using one of the standard ports (i.e., not having to add the port to the URL)?

After searching everything that I could find on this assumes the Proxmox host is running NAT for the containers. However, in this case each container is directly accessible via its own IP address.

Thanks.

 

[manu]

the pve firewall blocks or allow ports but doing port redirection is outside its functionality.
If each of your container has its own IP you could for instance add on the container a reverse proxy which would forward the traffic to the real service running on port 8000

 

[Rares]

I had the same setup/"problem".

In the end I created a KVM running linux as a gateway. On it I have setup Apache to run as proxy for the internal web servers. Also this machine is offering SSL for all the servers using Lets encrypts. Is is very easy to have only one certbot to manage for certificate renewal. On the same server I created port forwarding rules for internal machines too.

Regards,
Rares

 

[BlueLineSwinger]

Ah, that's too bad. I was hoping to not have to install iptables into the affected containers to do the redirect, but it shouldn't be too big an issue.

 

[Rares]

You don't have to install nothing on the affected containers, just make an extra VM to act as a gateway beside them and install iptables there.

 

[BlueLineSwinger]

Yeah, but then all of the other containers are reliant on that one being up and properly routing. I'd rather keep each as independent as possible. I was willing to let the Proxmox host fulfill this role as it'd already be performing firewall functions for the containers and theoretically a redirect would be just a bit of a tweak to those settings.

 

[dale]

Ah, that's too bad. I was hoping to not have to install iptables into the affected containers to do the redirect, but it shouldn't be too big an issue.

BlueLineSwinger, your system is Debian. It seems you are not limited by Proxmox Filrewall functionality.

 

[bofh]

what? why?
jsut set iptables on the promox host for port forwarding to the vms
if you want a graphical gui for that usw firewallbuilder. its a gui standalone on win/linux/mac that create iptables scripts

just run that script at startup and youre golden. no reson for gateway vms or similar

 

[BlueLineSwinger]

The problem with that is changes made directly to the host's iptables config aren't pinned to the container in any way. Should the container be moved to another host or deleted the redirect settings won't automatically be adjusted as needed. Using Proxmox to set up such forwarding (were it supported), or embedding them into the container itself, means that the setup always follows the container without any additional work.

 

[bofh]

The problem with that is changes made directly to the host's iptables config aren't pinned to the container in any way. Should the container be moved to another host or deleted the redirect settings won't automatically be adjusted as needed. Using Proxmox to set up such forwarding (were it supported), or embedding them into the container itself, means that the setup always follows the container without any additional work.

that is not a reason sorry. but if you try to run a setup 2 or more host with one public ip each, seperated from each other,
then youre out of luck anyway you gonna spin the wheel in almsot all cases


first of all your host is not aware of vms internal ip, so there is always reconfigureing something outside promox when moving that vm
you jsut made it harder with require another linux router on each host.
also that ip not gonna reroute itself, in order for the second host to accept that outsideip for forwarning you walways have to reconfigure at least the host but almost always either an outside firewall or mac table

this would be different in a routed setup with mac awareness on your providers site. there your vm would get that ip directly based on mac
and if its a flex ip you could move vms around (even tough those flex ip are almsot always an extra service and usually used for failover the hosts not standard use for vms) anyway

that setup is the least just move the vm and it works of all.
you eitehr need identical private subnet ips (bad idea because it robs you from the possibility to vpn both hosts to each other and establish communication between vms on a private subnet level) but then you still have to reconfigure the hosts networking

otehrwise you need to reconfigure dns which is the worst of all, with a long ttl in your dns this will cause issues.
and in both cases you need need an identical cofnigured forwarding vm


if you go that route you could preconfigure that forwarding on both hosts anyway.
using a forwarding vm or forward on the host makes no difference in any whatsoever way

if you wann go with dns swtich and identical subnets then
-you can use an internal ip only once on both hosts (obiviously)
- you have to preconfigure the forwarding vm
- you could preconfigure ip forwarding on the host too


pinning that firewall config to promox wont give you any advantage as long promox aint make vm ip config and dynamic ip allocation on the host side (which it doesnt)

 

[BlueLineSwinger]

Um, I'm not quite sure what you're trying to explain here. Best I can discern you're going into some convoluted NAT setups. The original post specified that each container is directly accessible. There is no NAT setup on the Proxmox host, either directly or via some kind of router running as a guest itself.

All I was looking to do was utilize Proxmox's own container-specific firewall setup, already in use for basic ACL duties, in order to set up a basic port redirect. But given that it's currently not possible, simply installing iptables and configuring the redirect inside the container itself works fine.

 

[bofh]

yes portforwarding wont work with promox.

installing iptables? you dont install iptables you just configure it, iptables is kernel land, nothing to install.

again redirecting aka DNAT or SNAT inside a VM (or container) makes no sense. jsut more overhead and more things to fail.
you can simply define the portforward on the host itself.

yes it wont carry over to host 2 - sames goes for any other container solution you try to use.
you alawys need to configure more than just moving your vm, so it wont matter much where the snat/dnat is done.

doing it on the host itself is the cleanest way with the least costs. doing it by a virtual router makes no sense on promox.

 

[BlueLineSwinger]

Gotta disagree with you. Implementing the redirect on the host itself, outside of Proxmox, is a bad idea. It adds separate steps to the management of the guests should they be migrated, readdressed, or deleted. You must separately reconfigure iptables on the host(s) for each change. Contrary to your assertion, this would be the more fragile setup. It would simply be too easy to miss or mangle something. High availability is also out as it can't make these adjustments. Also, the configuration of the host itself should remain as static as possible, so as not to possibly disturb the operation of the guests.

Now, were such a config allowed on the host within Proxmox, it would be ideal. It would be an extension of existing firewall functionality that's already in place and typically enabled. Also, since it's configured within Proxmox, the settings are pinned to the guest and will be accounted for when any changes, migrations, etc. take place. And it's a bit more efficient to run a single instance on the host to handle redirects, as opposed to instances within each guest.

But since that's not possible, the best option is to configure the redirect within the guest itself. It does add a (very minor) bit of overhead to the guest in RAM and disk space. But the setup remains easily portable and directly linked to (i.e., within) the guest. The host has no direct knowledge of the setup, but doesn't need to. Any automated tasks, such as HA/migrations/etc., will work properly.

Again, I'm not sure where you're getting the idea that there's a virtualized router running as a separate guest to handle the port redirects.

And by "install iptables", it should be obvious that this is in reference to the package(s) that contain the executables and libraries used to implement the functionality.

 

[bofh]

*facepalm* above peopel described using it as a defacto virtual router
beside its a singel point of failure and cant be moved from host to host without reconfigure the virtual router

if all your hosts are within the same lan then its adifferent and port mangeling should be done on lans firewall
if hosts have external ips with added privat subnets than the vm version is the most fragile version possible.
in those setups ha wont work anyway unless you have a failover ip configured
well it does work but it wont be reachable from outside

 

[BlueLineSwinger]

@bofh I don't know why you continue to believe, after being corrected at least twice, that there's a virtualized router (or for that matter any router aside from the typical Internet gateway) anywhere in the mix. Nor am I willing to put one up as it's not necessary or desired. Given your lack of reading comprehension, coupled with writing that makes what you are trying to say much less than clear, I can't waste any more time with this thread.

Thank you to everyone else who provided useful information and ideas. To summarize, I got what I needed simply installing/configuring iptables within the container:

• 'apt-get install iptables iptables-persistent'
• edit '/etc/sysctl.conf'
  • 'net.ipv4.ip_forward=1'
• 'iptables -t nat -A PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8000'
  • (while applied to the iptables "nat" table, it's simply a port redirect (layer 4) and not an address translation (layer 3).)
• 'dpkg-reconfigure -y iptables-persistent'
  • (write out the iptables config so that it will be read in on reboot.)

As expected and desired, this setup is perfectly portable when the container is moved between hosts, and resource usage is so minimal it may as well be nonexistent.

 

[bofh]

corrected? good one, go get some qualifications first
be grateful i gave away a little of my valued time to support newbies like you

i told you why its not a good idea and why it wont work the way you expect it to work.
take it or leave it but dont try to devalue someone with more knowlege only because you found some kind or working solution (that isnt one in reality)

ofc you cant comprehend what iam saying, thats why you even attemp that nonsense

 

[Jpppb]

corrected? good one, go get some qualifications first
be grateful i gave away a little of my valued time to support newbies like you

i told you why its not a good idea and why it wont work the way you expect it to work.
take it or leave it but dont try to devalue someone with more knowlege only because you found some kind or working solution (that isnt one in reality)

ofc you cant comprehend what iam saying, thats why you even attemp that nonsense

Sorry, just read this thread.

Gotta agree with BlueLineSwinger. You may have made a valid point, but it's hard to read and thus hard to find. On top of that, to put it mildly ,you're not very friendly or helpful for any person who doesn't have the exact knowledge you have (But you wouldn't be able to help them in that case ).

Don't patronise others like this, it's toxic, breaks down communities and repels newcomers from asking questions. If you're going to do that; at least make sure you're 100% correct, able to properly write & correct their own english at a decent level (looking at your last sentence..) (also isn't my first language, boohoo.) and that you are able to clearly explain subjects without defaulting back to 'hurrr durr yu dumb dumb" .

edit: some spelling, probably going to find some more later on

 

[iniciaw]

nginx proxy manager