Reply to: More IPTables lunacy

[suityou01]

chmod 777 all the way....

That's why you get paid the big bucks

[stek]

chmod 777 all the way....

[suityou01]

FTFY

Ah the cavelry's here now

[Contreras]

First problem is you need to make the script executable

chmod +x /etc/libvirt/hooks/qemu

Then you need to get the script right

FTFY

[suityou01]

Actually the hook script was down to me.

First problem is you need to make the script executable

chmod -x /etc/libvirt/hooks/qemu

Then you need to get the script right

The script runs from the command line, and has command line arguments which specify the machine name, and machine status.

So if your machine name is WIN_7_GUEST then the script should look like

#!/bin/sh

GUEST_NAME=Win_7_GUEST
GUEST_PORT=5902

if [ "$1" = "$GUEST_NAME" ]; then
        if [ "$2" = start ]; then
                iptables -I INPUT 1 -p tcp --dport "$GUEST_PORT" \
                -j ACCEPT
        elif [ "$2" = stopped ]; then
                iptables -D INPUT 1 -p tcp --dport "$GUEST_PORT" \
                -j ACCEPT
        fi
fi

Then when you spark up the VM it pokes a hole in the firewall for itself.

[suityou01]

OK so I have a hackaround.

iptables I INPUT 1 -p tcp --dport 5902 -j ACCEPT

This inserts the rule at the top of the input rule chain. This gets me out of a spot for now.

However I did find out that qemu (thats the hypervisor) supports hooks. So it's possible to write a script that runs when a VM is sparked up and shut down to add the necessary rules to iptables and remove them respectively.

So here's what I did.

/etc/libvirt/hooks/qemu

#!/bin/sh

GUEST_NAME
HOST_PORT
GUEST_IPADDR
GUEST_PORT

if [ "$1" = "$GUEST_NAME" ]; then
        if [ "$2" = start ]; then
                iptables -I INPUT 1 -p -tcp --dport "$GUEST_PORT" \
                -j ACCEPT
        elif [ "$2" = stopped ]; then
                iptables -D INPUT 1 -p -tcp --dport "$GUEST_PORT" \
                -j ACCEPT
        fi
fi

Naturally it only says it supports this feature, and in actuality it doesn't work

So for now I have to do this manually from an elevated shell.

So I have a hackaround for now at least.

[suityou01]

OK so the hackaround option seems to not work either

I started firewalld, started the hypervisor.

Output from iptables -L seems ok now.

Boot VM. VM has internet access and I cannot connect to it remotely. All familiar.

Then from an elevated shell I type

iptables -A INPUT -p tcp --dport 5902 -j ACCEPT

Ie adding the firewall rule AFTER the hypervisor has done it's biz.

Try to connect remotely and still no.

Output of iptables -L?

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
INPUT_direct  all  --  anywhere             anywhere            
INPUT_ZONES_SOURCE  all  --  anywhere             anywhere            
INPUT_ZONES  all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:5902

It's added my line right after the line which says reject everything else

Edit : -A means append so I guess that's fair enough, but still annoying.

[suityou01]

Just did a restart of firewalld and hypervisor and it works again, but no internet access for the guest.

Flaky as hell.

Edit : Here is the output of iptables -L since restarting the services

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

So libvirt has not loaded any of the NAT rules, hence why the internet is broken for the guest.
Hence also why I can connect to it remotely.

So it seems I have to now get libvirt to open 5902 by loading it's own rule into iptables.

Which brings me back to my hack around option.

[suityou01]

output from

iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     udp  --  anywhere             anywhere             udp dpt:domain
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:domain
ACCEPT     udp  --  anywhere             anywhere             udp dpt:bootps
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:bootps
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
INPUT_direct  all  --  anywhere             anywhere            
INPUT_ZONES_SOURCE  all  --  anywhere             anywhere            
INPUT_ZONES  all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             10.0.0.0/24          ctstate RELATED,ESTABLISHED
ACCEPT     all  --  10.0.0.0/24          anywhere            
ACCEPT     all  --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
REJECT     all  --  anywhere             anywhere             reject-with icmp-port-unreachable
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            
FORWARD_direct  all  --  anywhere             anywhere            
FORWARD_IN_ZONES_SOURCE  all  --  anywhere             anywhere            
FORWARD_IN_ZONES  all  --  anywhere             anywhere            
FORWARD_OUT_ZONES_SOURCE  all  --  anywhere             anywhere            
FORWARD_OUT_ZONES  all  --  anywhere             anywhere            
ACCEPT     icmp --  anywhere             anywhere            
REJECT     all  --  anywhere             anywhere             reject-with icmp-host-prohibited

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         
OUTPUT_direct  all  --  anywhere             anywhere            

Chain FORWARD_IN_ZONES (1 references)
target     prot opt source               destination         
FWDI_public  all  --  anywhere             anywhere            [goto] 

Chain FORWARD_IN_ZONES_SOURCE (1 references)
target     prot opt source               destination         

Chain FORWARD_OUT_ZONES (1 references)
target     prot opt source               destination         
FWDO_public  all  --  anywhere             anywhere            [goto] 

Chain FORWARD_OUT_ZONES_SOURCE (1 references)
target     prot opt source               destination         

Chain FORWARD_direct (1 references)
target     prot opt source               destination         

Chain FWDI_public (1 references)
target     prot opt source               destination         
FWDI_public_log  all  --  anywhere             anywhere            
FWDI_public_deny  all  --  anywhere             anywhere            
FWDI_public_allow  all  --  anywhere             anywhere            

Chain FWDI_public_allow (1 references)
target     prot opt source               destination         

Chain FWDI_public_deny (1 references)
target     prot opt source               destination         

Chain FWDI_public_log (1 references)
target     prot opt source               destination         

Chain FWDO_public (1 references)
target     prot opt source               destination         
FWDO_public_log  all  --  anywhere             anywhere            
FWDO_public_deny  all  --  anywhere             anywhere            
FWDO_public_allow  all  --  anywhere             anywhere            

Chain FWDO_public_allow (1 references)
target     prot opt source               destination         

Chain FWDO_public_deny (1 references)
target     prot opt source               destination         

Chain FWDO_public_log (1 references)
target     prot opt source               destination         

Chain INPUT_ZONES (1 references)
target     prot opt source               destination         
IN_public  all  --  anywhere             anywhere            [goto] 

Chain INPUT_ZONES_SOURCE (1 references)
target     prot opt source               destination         

Chain INPUT_direct (1 references)
target     prot opt source               destination         

Chain IN_public (1 references)
target     prot opt source               destination         
IN_public_log  all  --  anywhere             anywhere            
IN_public_deny  all  --  anywhere             anywhere            
IN_public_allow  all  --  anywhere             anywhere            

Chain IN_public_allow (1 references)
target     prot opt source               destination         
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh ctstate NEW
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:5901 ctstate NEW

Chain IN_public_deny (1 references)
target     prot opt source               destination         

Chain IN_public_log (1 references)
target     prot opt source               destination         

Chain OUTPUT_direct (1 references)
target     prot opt source               destination

[suityou01]

OK so I'm leaning towards Stek's Linux is crap argument slightly more.

WFH on this now so I opened 5902 on the router, opened 5902 in iptables with a slightly different statement this time

-A INPUT -m state --state NEW,ESTABLISHED,RELATED -m tcp -p tcp --dport 5902 -m comment --comment "SPICE Client" -j ACCEPT

And bingo I am in like flint.

Except that the VM no longer has internet access, ie NAT is not forwarding on for some reason.

Fairy snuff.

systemctl restart firewalld

Then restart the hypervisor.

Restart VM. Bingo, internet access.

But I can no longer connect using remote viewer.

OK so spin up Wireshark and slap a Display filter on tcp.port eq 5902

Very enlightening.

5902	7.874682000	192.168.0.5	90.195.100.51	ICMP	94	Destination unreachable (Host administratively prohibited)

So you can see the firewall, on .5 is telling me to bog off again.

Note, no firewall rules were changed since it last worked.

Irgo I conclude libvirt is adding something to the inbound rule chain that is overriding my rule and blocking me.

[suityou01]

Quick look at err, one at work...

Try setting iptables to allow TCP ports 5801, 5901 and 6001....... Or 5800, 5900 and 6000 etc....

AIUI - those are needed for VNC viewer, client and server respectively...

Thanks stek. 6 beer tokens are all yours. Cash them in when we meet sometime.

The ports and ranges have been opened. I think the problem lies in that when KVM starts the NAT, libvirt adds it's own rules to ip tables for the NAT.

So I open port 5902 or whatever, restart IPTables, and restart the hyper visor then grep the port with IPTables and its mysteriously not there.

I'm looking at a hack around, to get libvvirt to add the port rules instead of adding them to ip tables. Just some scripting.

Seems completely mental that you can add a guest, configure the port and that KVM handles the NATTING from guest to outside world but doesn't handle outside world to guest. It's like out of box you can have as many VMs as you want, but just don't expect to talk to them ever

[stek]

Quick look at err, one at work...

Try setting iptables to allow TCP ports 5801, 5901 and 6001....... Or 5800, 5900 and 6000 etc....

AIUI - those are needed for VNC viewer, client and server respectively...

[suityou01]

5901 is vnc. That works.
5900 - 5910 was originally open as a range. Then I reverted to a single port.

News is that wireshark reveals that it is the outbound connection from 192.168.0.5 to 192.168.0.10 that is being refused.

So the incoming ack gets through. This smells right to me as now the virt-viewer is just sitting there saying connection.

Kind of Ack .........

And no Syn ever comes.

I added and outbound rule for the same port and restarted the services but still nichts.

Proper grateful for your time Mr Stek. Reckon this one might be unsolvable via a forum.

[stek]

Lol. You don't remember the last load of fun and games with that?

If NAT is working without the poxy firewall then it can't be the NAT.

This has to be a pure IPTables problem, Shirley?

I think it might be the VNC port is use from a previous connection attempt - try it with multiple ports;

blah blah -m multiport --dports 5901:5906,6001:6006 blah blah

[suityou01]

Lol. You don't remember the last load of fun and games with that?

If NAT is working without the poxy firewall then it can't be the NAT.

This has to be a pure IPTables problem, Shirley?