I've understood iptables well enough for a long, long time, and although I think firewall-cmd is a poor replacement for iptables, I've always been able to "get it to work" by comparing output with iptables -L or iptables -S and using a direct-rule or two.
And this time, I'm just baffled.
I have a qemu VM running on a host. Postgresql runs on the host, and I'm trying to connect to the Postgresql server on the host from the VM.
VM: loco Host: tesla
1) If I turn OFF the firewall on tesla, I have no trouble connecting from loco. tesla: systemctl stop firewalld loco: psql -U postgres -h 192.168.122.1 # yay! connection!
2) If I turn ON the firewall on tesla, I can't connect NO MATTER WHAT I DO tesla: systemctl start firewalld; loco: psql -U postgres -h 192.168.122.1 # Connection refused
I have tried: tesla# firewall-cmd --zone=public --add-port=5432/tcp tesla# firewall-cmd --add-service=postgresql tesla# firewall-cmd --set-default-zone=trusted; tesla# firewall-cmd --direct --add-rule ipv4 filter LIBVIRT_FWI 0 -j ACCEPT tesla# firewall-cmd --direct --add-rule ipv4 filter LIBVIRT_FWO 0 -j ACCEPT tesla# firewall-cmd --direct --add-rule ipv4 filter LIBVIRT_FWX 0 -j ACCEPT
... and many more things. Literally stumped for a few hours. The output of iptables indicates that I've wildcarded everything:
tesla# iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N LIBVIRT_FWI -N LIBVIRT_FWO -N LIBVIRT_FWX -N LIBVIRT_INP -N LIBVIRT_OUT -A INPUT -j LIBVIRT_INP -A FORWARD -j LIBVIRT_FWX -A FORWARD -j LIBVIRT_FWI -A FORWARD -j LIBVIRT_FWO -A OUTPUT -j LIBVIRT_OUT -A LIBVIRT_FWI -d 192.168.122.0/24 -j ACCEPT -A LIBVIRT_FWI -i virbr0 -j ACCEPT -A LIBVIRT_FWI -j ACCEPT -A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable -A LIBVIRT_FWO -i virbr0 -j ACCEPT -A LIBVIRT_FWO -j ACCEPT -A LIBVIRT_FWO -s 192.168.122.0/24 -i virbr0 -j ACCEPT -A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable -A LIBVIRT_FWX -j ACCEPT -A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT -A LIBVIRT_INP -j ACCEPT -A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT -A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT -A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT -A LIBVIRT_OUT -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 53 -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 68 -j ACCEPT
There are no REJECT rules not preceded by a wildcard ACCEPT, but I can't connect with this config. But simply stopping host (tesla) firewalld allows me to connect just fine.
Any ideas?
I've understood iptables well enough for a long, long time, and although I think firewall-cmd is a poor replacement for iptables, I've always been able to "get it to work" by comparing output with iptables -L or iptables -S and using a direct-rule or two.
And this time, I'm just baffled.
I have a qemu VM running on a host. Postgresql runs on the host, and I'm trying to connect to the Postgresql server on the host from the VM.
VM: loco Host: tesla
- If I turn OFF the firewall on tesla, I have no trouble connecting from
loco. tesla: systemctl stop firewalld loco: psql -U postgres -h 192.168.122.1 # yay! connection!
- If I turn ON the firewall on tesla, I can't connect NO MATTER WHAT I DO
tesla: systemctl start firewalld; loco: psql -U postgres -h 192.168.122.1 # Connection refused
I have tried: tesla# firewall-cmd --zone=public --add-port=5432/tcp tesla# firewall-cmd --add-service=postgresql tesla# firewall-cmd --set-default-zone=trusted; tesla# firewall-cmd --direct --add-rule ipv4 filter LIBVIRT_FWI 0 -j ACCEPT tesla# firewall-cmd --direct --add-rule ipv4 filter LIBVIRT_FWO 0 -j ACCEPT tesla# firewall-cmd --direct --add-rule ipv4 filter LIBVIRT_FWX 0 -j ACCEPT
... and many more things. Literally stumped for a few hours. The output of iptables indicates that I've wildcarded everything:
tesla# iptables -S -P INPUT ACCEPT -P FORWARD ACCEPT -P OUTPUT ACCEPT -N LIBVIRT_FWI -N LIBVIRT_FWO -N LIBVIRT_FWX -N LIBVIRT_INP -N LIBVIRT_OUT -A INPUT -j LIBVIRT_INP -A FORWARD -j LIBVIRT_FWX -A FORWARD -j LIBVIRT_FWI -A FORWARD -j LIBVIRT_FWO -A OUTPUT -j LIBVIRT_OUT -A LIBVIRT_FWI -d 192.168.122.0/24 -j ACCEPT -A LIBVIRT_FWI -i virbr0 -j ACCEPT -A LIBVIRT_FWI -j ACCEPT -A LIBVIRT_FWI -d 192.168.122.0/24 -o virbr0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT -A LIBVIRT_FWI -o virbr0 -j REJECT --reject-with icmp-port-unreachable -A LIBVIRT_FWO -i virbr0 -j ACCEPT -A LIBVIRT_FWO -j ACCEPT -A LIBVIRT_FWO -s 192.168.122.0/24 -i virbr0 -j ACCEPT -A LIBVIRT_FWO -i virbr0 -j REJECT --reject-with icmp-port-unreachable -A LIBVIRT_FWX -j ACCEPT -A LIBVIRT_FWX -i virbr0 -o virbr0 -j ACCEPT -A LIBVIRT_INP -j ACCEPT -A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 53 -j ACCEPT -A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A LIBVIRT_INP -i virbr0 -p udp -m udp --dport 67 -j ACCEPT -A LIBVIRT_INP -i virbr0 -p tcp -m tcp --dport 67 -j ACCEPT -A LIBVIRT_OUT -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 53 -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 53 -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p udp -m udp --dport 68 -j ACCEPT -A LIBVIRT_OUT -o virbr0 -p tcp -m tcp --dport 68 -j ACCEPT
There are no REJECT rules not preceded by a wildcard ACCEPT, but I can't connect with this config. But simply stopping host (tesla) firewalld allows me to connect just fine.
Any ideas? _______________________________________________
I can only guess because I've never used firewalld but, can it be that firewalld also changes something else and not only the iptables config?
Did you try to apply the iptable rules by hand for a test?
Simon
Did you try to apply the iptable rules by hand for a test?
This turned out to be the exact hint I needed. I turned off firewalld, and applied the rules I'd quoted exactly, to see a different result.
Eventually, it turned out that iptables does not expose zones, and found that applying the rules within the "libvirt" zone resolved the issue.
Thanks
On 12/12/20 8:15 am, Lists wrote:
I've understood iptables well enough for a long, long time, and although I think firewall-cmd is a poor replacement for iptables, I've always been able to "get it to work" by comparing output with iptables -L or iptables -S and using a direct-rule or two.
And this time, I'm just baffled.
I have a qemu VM running on a host. Postgresql runs on the host, and I'm trying to connect to the Postgresql server on the host from the VM.
VM: loco Host: tesla
- If I turn OFF the firewall on tesla, I have no trouble connecting from loco.
tesla: systemctl stop firewalld loco: psql -U postgres -h 192.168.122.1 # yay! connection!
- If I turn ON the firewall on tesla, I can't connect NO MATTER WHAT I DO
tesla: systemctl start firewalld; loco: psql -U postgres -h 192.168.122.1 # Connection refused
<snip>...
There are no REJECT rules not preceded by a wildcard ACCEPT, but I can't connect with this config. But simply stopping host (tesla) firewalld allows me to connect just fine.
I'd run tcpdump on the host where the firewall is deployed to see where the packets are coming from:
tcpdump -l -n -i any port 5432 # assuming you are using standard pgsql port
Then compare that with what's in my ruleset to see which rule is blocking.
PS: I'm no longer on CentOS but I believe iptables/tcpdump are the same on whichever Linux distro is installed.
-
Anthony K -
Lists -
Simon Matter