Reply to: Even more IP Tables Lunacy

[suityou01]

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

Oh ok, sure.

Well now knowing what I know, and re-reading the thread the wireshark trace excerpt is really all you need to look at.

ldap 36.147965000 192.168.0.5 10.0.0.222 ICMP 94 Destination unreachable (Host administratively prohibited)

A firewall is programmed with rules that tell it what do with a packet. Generally it is

1) Let is pass
2) Drop it
3) Reject it

So from a ping point of view if you get a response, it was allowed.
If you get a "Destination host unreachable" error, then a rejection was received.
If you get a "Request timed out" error then the packet was dropped (ie nothing came back).

In the wireshark message above you can see that this is a rejection message. It is from 192.168.0.5 to 10.0.0.222, saying that an earlier attempt to initiate a connection on the LDAP port was denied.

So to fix it, you just need to open the port on 192.168.0.5. In my example I only wanted to receive traffic from the virtual network, so I did this :

iptables - I INSERT 1 -p tcp -s 10.0.0.0/24 --dport 389 -j ACCEPT

This allows traffic on port 389 from the 10.0.0.0/24 subnet.

There were other ports to open up, and I spent the day sifting through wireshark traces and fixing problem but in the end all the wireshark traces were clean and the VMs talking happily to the host.

For info, the host is Centos7, running Samba4 and I am using this to establish an Active Directory without using Windows server. Then I administer the AD from a windows 7 guest using the server management tools.

Any questions just holler.

[darmstadt]

I fixed it.

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

[TheFaQQer]

Go Suity

[suityou01]

I fixed it.

[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]

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?

[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]

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]

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]

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.

[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]

That might be it - RHEL7+ uses firewalld by default, not iptables. Give these a try and report back:

firewall-cmd --get-zones

firewall-cmd --get-active-zones

firewall-cmd --get-zones

block dmz drop external home internal public trusted work

firewall-cmd --get-active-zones

[suityou01]

That might be it - RHEL7+ uses firewalld by default, not iptables. Give these a try and report back:

firewall-cmd --get-zones

firewall-cmd --get-active-zones

The only problem with that statement is that KVM uses Libvirt, which loads rules into IPTables.

[suityou01]

systemctl status firewalld

firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; enabled)
Active: active (running) since Thu 2015-03-05 14:44:52 GMT; 42s ago
Main PID: 44375 (firewalld)
CGroup: /system.slice/firewalld.service
\u2514\u250044375 /usr/bin/python -Es /usr/sbin/firewalld --nofork --nopid

Mar 05 14:44:53 maidmentjudd.com firewalld[44375]: 2015-03-05 14:44:53 ERROR: COMMAND_FAILED: '/sbin/iptables --table filter --delete FORWARD --destination 10.0.0.0/24 --in-interface em2 --out-interface virbr0 --match conntrack --ctstate ESTABLISHED,RELATED --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
Mar 05 14:44:53 maidmentjudd.com firewalld[44375]: 2015-03-05 14:44:53 ERROR: COMMAND_FAILED: '/sbin/iptables --table filter --delete FORWARD --source 10.0.0.0/24 --in-interface virbr0 --out-interface em2 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
Mar 05 14:44:53 maidmentjudd.com firewalld[44375]: 2015-03-05 14:44:53 ERROR: COMMAND_FAILED: '/sbin/iptables --table filter --delete FORWARD --in-interface virbr0 --out-interface virbr0 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
Mar 05 14:44:54 maidmentjudd.com firewalld[44375]: 2015-03-05 14:44:54 ERROR: COMMAND_FAILED: '/sbin/iptables --table filter --delete FORWARD --out-interface virbr0 --jump REJECT' failed: iptables: No chain/target/match by that name.
Mar 05 14:44:54 maidmentjudd.com firewalld[44375]: 2015-03-05 14:44:54 ERROR: COMMAND_FAILED: '/sbin/iptables --table filter --delete FORWARD --in-interface virbr0 --jump REJECT' failed: iptables: No chain/target/match by that name.
Mar 05 14:44:54 maidmentjudd.com firewalld[44375]: 2015-03-05 14:44:54 ERROR: COMMAND_FAILED: '/sbin/iptables --table filter --delete INPUT --in-interface virbr0 --protocol udp --destination-port 53 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
Mar 05 14:44:54 maidmentjudd.com firewalld[44375]: 2015-03-05 14:44:54 ERROR: COMMAND_FAILED: '/sbin/iptables --table filter --delete INPUT --in-interface virbr0 --protocol tcp --destination-port 53 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
Mar 05 14:44:54 maidmentjudd.com firewalld[44375]: 2015-03-05 14:44:54 ERROR: COMMAND_FAILED: '/sbin/iptables --table mangle --delete POSTROUTING --out-interface virbr0 --protocol udp --destination-port 68 --jump CHECKSUM --checksum-fill' failed: iptables: No chain/target/match by that name.
Mar 05 14:44:55 maidmentjudd.com firewalld[44375]: 2015-03-05 14:44:55 ERROR: COMMAND_FAILED: '/sbin/iptables --table filter --delete INPUT --in-interface virbr0 --protocol udp --destination-port 67 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).
Mar 05 14:44:55 maidmentjudd.com firewalld[44375]: 2015-03-05 14:44:55 ERROR: COMMAND_FAILED: '/sbin/iptables --table filter --delete INPUT --in-interface virbr0 --protocol tcp --destination-port 67 --jump ACCEPT' failed: iptables: Bad rule (does a matching rule exist in that chain?).

[Mattski]

That might be it - RHEL7+ uses firewalld by default, not iptables. Give these a try and report back:

firewall-cmd --get-zones

firewall-cmd --get-active-zones