iptables – How to Fix Connection Refused When Accessing Container Through Reverse Proxy

connection-refusediptablesnat;proxmoxreverse-proxy

I am running Proxmox VE on a root server. There are several virtual containers, on of them acts as a reverse proxy who does TLS termination.

On the proxmox machine iptables handles port forwarding and protection of the internal network. The configuration looks like this:

*nat
# enable network access for vms
-A POSTROUTING -s 192.168.1.0/24 -o enp4s0 -j MASQUERADE
# reverseproxy
-A POSTROUTING -s 192.168.1.2/24 -o vmbr0 -j MASQUERADE
-A PREROUTING -i vmbr0 -p tcp --dport 80 -j DNAT --to 192.168.1.2:80
-A PREROUTING -i vmbr0 -p tcp --dport 443 -j DNAT --to 192.168.1.2:443
COMMIT

*filter
# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT
# Accepts established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
# Allows all outbound traffic
-A OUTPUT -j ACCEPT
# Allows SSH connection
-A INPUT -p tcp -m state --state NEW --dport 22 -j ACCEPT
# Allow ping
-A INPUT -p icmp -j ACCEPT
# log iptables denied calls (access via 'dmesg' command)
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7
# Reject all other inbound - default deny unless explicitly allowed policy:
-A INPUT -j REJECT
COMMIT

When i try to connect (with wget) from one container to the public url of another container, i get an error message containing:
"xxx.xxx.xxx.xxx|:443… failed: Connection refused."

When i access the same url from the outside i can access the container without problems. Is there something i accidentially blocked or forgot to enable?

Best Answer

The answer was quite obvious:

i enabled port forwarding for the reverse proxy coming from the interface vmbr0 (bridge between static server ip and internal network) but not for vmbr1 (bridge over which containers are connected). As domain names resolved to the external IP, but the packets were coming from the internal bridge vmbr1 and not from the external vmbr0 no port forwarding was done.

The solution was adding this in the *nat table:

-A POSTROUTING -s 192.168.1.2/24 -o vmbr1 -j MASQUERADE
-A PREROUTING -i vmbr1 -d SERVERIP -p tcp --dport 80 -j DNAT --to 192.168.1.2:80
-A PREROUTING -i vmbr1 -d SERVERIP -p tcp --dport 443 -j DNAT --to 192.168.1.2:443

Related Solutions

Linux – iptables port forward forwarding

You're sending the traffic to 10.52.208.221. Given the config you posted, your problem is the webserver, not the firewall. Your rules look to be correct. FORWARD and INPUT are redirected to RH-Firewall-1-INPUT where your first rule is to allow all traffic. As somebody else pointed out, you could be allowing all traffic on eth1, while the world is actually coming in eth0. Secondary, you have to NAT the traffic as it goes back out to the world

iptables --table nat --append POSTROUTING --proto tcp --dport 80 --jump MASQUERADE -o OUT_INTERFACE

Your traffic originating from the router will never hit the input or forward chains, but instead traverse the output chain on to the webserver. Other systems in that subnet will similarly go directly to the webserver. Systems out on the world at large however will traverse the INPUT / FORWARD chains and need SNAT as well as DNAT so that it appears to the world to be one machine. You still cannot test from within your network. you must test from the opposite interface from the webserver. Get me your IP addresses and I'll point you to the proper configs.

Iptables – ftp tls firewalled :(

In Passive mode, when the client wants to get a file from the server or send a file to the server, the FTP server will pick a random port and send that port to the FTP client.

When you're not using encryption, a properly configured firewall (using the ip_conntrack_ftp helper kernel module, which may be what you're missing for non-TLS connections) would "listen in" on the connection and mark these connections as RELATED. With encryption the firewall can't listen in.

The quick and dirty solution to this is to configure the FTP server to choose a small range of ports for passive connections, and then allow access to all of these ports. For instance, in vsftpd:

pasv_min_port=12000
pasv_max_port=12049

Then in iptables:

iptables -A INPUT -p tcp -m tcp -i eth0 --dport 12000:12049 -j ACCEPT

Allowing anyone to access these ports opens one possible exploit: if someone were to be scanning them over and over they might get lucky and be able to "beat" the real user to the data port and grab the file. Ideally your FTP server would check and make sure the connection is coming from the same place as the original connection, but thanks to things like "FXP" (transferring files from one server to another server by convincing one to make an active connection to the other's passive data port) some servers don't check the connection by default. You should check your configuration file and see if there is an option to disable FXP, and use it. (vsftpd calls this "promiscuous" and is disabled by default.)

Best Answer

Related Solutions

Linux – iptables port forward forwarding

Iptables – ftp tls firewalled :(

Related Topic