Join Log in
Score:0
TheAnachronism avatar Server

Firewalld port forwarding Proxmox makes port unusable for other connections

in flag
TheAnachronism

I have a server hosted by hetzner with a single public ip address which runs proxmox and some VMs. This ip address is configured inside /etc/interfaces like this:

auto enp35s0
iface enp35s0 inet static
    address {{my-public-ip}}/{{subnet}}
    gateway {{hetzner-gateway}}
    up route add -net {{hetzner-ip}} netmask 255.255.255.192 gw {{hetzner-gateway}} dev enp35s0

This configuration was done by hetzner.

Because I don't want to get additional ip addresses from hetzner I masquerade that ip for an internal VM-Network:

auto vmbr0
iface vmbr0 inet static
    address 172.16.0.1/24
    bridge-ports none
    bridge-stp off
    bridge-fd 0

    post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
    post-up   iptables -t nat -A POSTROUTING -s '172.16.0.0/24' -o enp35s0 -j MASQUERADE
    post-down iptables -t nat -D POSTROUTING -s '172.16.0.0/24' -o enp35s0 -j MASQUERADE

With this my VMs have internet access and can reach each other.

Because iptables port forwarding is a bit too complicated for me I've started using firewalld. In there I have my enp35s0 interface assigned to the external zone and vmbr0 to trusted. I know maybe I should assign it to internal instead but currently it doesn't really make a difference (or I think so in my problem case).

I now have a service running inside a VM with the ip 172.16.0.3 on port 38080. To reach this service I add a port forwarding rule in firewalld: port=38080:proto=tcp:toport=38080:toaddr=172.16.0.3. With that I can reach that service from outside of this server machine. The problem now is, that if I use a software like uptime-kuma and run it also inside a VM on the same physical machine, I can't reach that service on port 38080 because the port forwarding is only done for external requests. Important here is, that the hostname that uptime-kuma uses is the FQDN that gets resolved to the public ip address of my host machine. So to make this possible I add the same port forwarding rule to the trusted zone of firewalld because my vmbr0 interface is in there and from that interface comes the request. Now this connection does work and my software (uptime-kuma) can reach my service.

The large problem now is, that EVERY request from inside the Virtual network which wants to use the port 38080 gets redirected to that VM (172.16.0.3), even those that go to a completely different server.

How can I tell firewalld to only redirect that traffic if the request was actually targeted at the host machine?

584
0 + 0
TheAnachronism avatar
in flag
TheAnachronism
My current workaround is to use ports that aren't required for any external services but that can't be the solution to this problem
0
Reply
Score:0
TheAnachronism avatar Server
in flag
TheAnachronism

So I couldn't really find a solution to the firewalld behavior but I found something else that made the port forwarding rule in the trusted zone unnecessary. By adding the FQDN which would resolve to the public IP of the host to the /etc/hosts file inside the VM I no longer need the port forward because it instantly connects to itself again (which is what I wanted in the first place). By using that port forwarding rules inside the trusted zone aren't needed anymore and I can use those ports for external requests again.

0 + 0
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.