Even more IP Tables Lunacy

[Mattski]

Fair point about libvirt and iptables, but at least it looks like there's no conflict there.

Am running out of time here, so some things to consider -

The routing looks fine on the host, but what's the routing table like on the guest? Is anything configured to tell it what interface to use to hit 192.168.0.5? Is a FW running on it that might stop this?

Other than that I'd have to replicate this environment and tool around with it. Sorry I couldn't be more help.

[suityou01]

Fair point about libvirt and iptables, but at least it looks like there's no conflict there.

Am running out of time here, so some things to consider -

The routing looks fine on the host, but what's the routing table like on the guest? Is anything configured to tell it what interface to use to hit 192.168.0.5? Is a FW running on it that might stop this?

Other than that I'd have to replicate this environment and tool around with it. Sorry I couldn't be more help.

You've been more than helpful old son.

PM me later. We might need to talk day rates.

[darmstadt]

systemctl status firewalld - l



Which I think are the rules I added earlier that I mentioned didn't work. Let me just flush ipTables and reload from scratch.

Are you doing a service iptables restart? If so then everything gets lost. I believe you need to send a sighup to libvirt which will rebuild its rules (I'll admit its been a while...) Maybe I'll have a play with my CentOS system here...

[suityou01]

Are you doing a service iptables restart? If so then everything gets lost. I believe you need to send a sighup to libvirt which will rebuild its rules (I'll admit its been a while...) Maybe I'll have a play with my CentOS system here...

Yes I restart the lot. Libvirt loads it's rules into the firewall which allow for the guests to talk, and get out to t'interweb. As for getting back in again there's only examples online of port forwarding from host to guest which isn't what I'm trying to do.

All I really want is a rule to solve the blocked packet I showed back in post 2 of the wireshark trace

[darmstadt]

How about the output from: iptables -L -n -v? This might give you more information such as is there a tun0 or tun+ interface there as they should be allowed as trusted interfaces?

try a snoop -d on the interface, you might see some more, different error messages when you try to connect.

Disabling iptables will probably fix it but I don't think you want to do that...oder...

# /etc/init.d/iptables save
# /etc/init.d/iptables stop

Now try it and see....

[suityou01]

How about the output from: iptables -L -n -v? This might give you more information such as is there a tun0 or tun+ interface there as they should be allowed as trusted interfaces?

try a snoop -d on the interface, you might see some more, different error messages when you try to connect.

Disabling iptables will probably fix it but I don't think you want to do that...oder...

# /etc/init.d/iptables save
# /etc/init.d/iptables stop

Now try it and see....

Danke Dir. Ich versuche Das spaeter.

In anderen Nachrichten

https://libvirt.org/firewall.html

type=nat

Allow inbound related to an established connection. Allow outbound, but only from our expected subnet. Allow traffic between guests. Deny all other inbound. Deny all other outbound.
target prot opt in out source destination
ACCEPT all -- * virbr0 0.0.0.0/0 192.168.122.0/24 state RELATED,ESTABLISHED
ACCEPT all -- virbr0 * 192.168.122.0/24 0.0.0.0/0
ACCEPT all -- virbr0 virbr0 0.0.0.0/0 0.0.0.0/0
REJECT all -- * virbr0 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable
REJECT all -- virbr0 * 0.0.0.0/0 0.0.0.0/0 reject-with icmp-port-unreachable

So die Verbindung ist noch nicht "established"

Was denkst du?

[suityou01]

As the connection is instigated by the guest, the return leg (forward chain) is established.

So this NAT rule setup by libvirt out of box should work.

The fwfilters you mention Darmie are defined at a guest level and there is nothing there that could prevent this packet getting through.

The windows firewall on the guest is turned off.

So the big question is what is dropping the packet on the forwarded route?

One idea I've had is to install wire shark on the guest as well. Then at least I can see if the packet is getting through to the guest, and is therefore being rejected by the guest.

That coupled with Darmies suggestion of IPTables -l -v so look at the packet counts against each rule.

[suityou01]

I fixed it.

[TheFaQQer]

Go Suity

[darmstadt]

I fixed it.

Just in case someone else has the same problem...