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? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part. URL: <http://lists.centos.org/pipermail/centos/attachments/20201211/ce3074f7/attachment-0003.sig>
Simon Matter
2020-Dec-11 21:30 UTC
[CentOS] Baffled by firewall rules with a Qemu VM, CentOS 7
> 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 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
Anthony K
2020-Dec-12 03:05 UTC
[CentOS] Baffled by firewall rules with a Qemu VM, CentOS 7
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 > > 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 > > <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.