1

I have a kvm setup with several guest vms running ubuntu.

For some reason I cannot get traffic through port 80 from the guests to the outside anylonger. The other way round works just fine, the apache delivers the hosted webpages as it should. Other ports like ssh also work just fine.

Here is an example:

me@guest:~$ curl heise.de
curl: (7) Failed to connect to 2a02:2e0:3fe:100::8: Network is unreachable

Curl fails with Network unreachable after a longish timeout and appears to try to use the IPv6 address, which it is not supposed to do. Curl versus locally hosted domains works.

Ping works:

me@guest:~$ ping heise.de
PING heise.de (193.99.144.80) 56(84) bytes of data.
64 bytes from redirector.heise.de (193.99.144.80): icmp_req=1 ttl=245 time=6.92 ms
64 bytes from redirector.heise.de (193.99.144.80): icmp_req=2 ttl=245 time=7.05 ms

Since it happened on all my guests at the same time, I am thinking it must be something I did on the host. But even when I turn off all my homebrew iptables rules it still doesn't work.

So somewhere inside the kvm/libvirt networking my http requests go where they shouldn't. Here is my network configuration for KVM

<network>
  <name>network_nat</name>
  <uuid>....</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0' />
  <mac address='52:54:00:30:9B:D6'/>
  <ip address='192.168.100.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.100.128' end='192.168.100.254' />
      <host mac='52:54:00:e4:71:f5' name='web' ip='192.168.100.210' />
    </dhcp>
  </ip>  
</network>

My guests are configured to use that network. Dhcp appears to work: at least the guest has the IP Address I configured.

So why can't I access any websites from my guests?

2
  • I know two possibilities for such problems: ebtables and the packet filter in QEMU. Have you checked with tcpdump how far the packets get? May 27, 2013 at 19:59
  • It is really weird after a reboot they got stuck between br0 and virbr0 which brought me to the conclusion that it was indeed my port forwarding that was at fault. What happened before: no idea.
    – Yashima
    May 27, 2013 at 20:02

1 Answer 1

1

Part of the problem was solved after a reboot. It maybe that following the advice here: http://wiki.libvirt.org/page/Networking helped fix the network interface.

I added these lines to /etc/sysctl.conf

net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0
net.bridge.bridge-nf-call-arptables = 0

I also changed my interface definition in /etc/network/interfaces to look like this:

auto  br0
iface br0 inet static
  address   176.9.xxx.xxx
  broadcast 176.9.xxx.xxx
  netmask   255.255.255.224
  gateway   176.9.xxx.xxx
  bridge_ports eth0
  bridge_fd 0 
  bridge_maxage 0
  bridge_stp off

After these 2 changes (that may or not have helped) and a reboot curl would no longer run into a timeout and "network unrechable" error, instead it produced a result from my local apache. It became clear that my own port-forwarding in iptables was to blame. I had not specified an incoming interface for the port-forwarding of ports 80 and 443. I added br0 and then everything worked fine.

Here are my iptables rules for the port forwarding. I am using this in combination with ufw as firewall, so I have these lines at the end of /etc/ufw/before.rules

This one is added to the filter table:

-I FORWARD -m state -d 192.168.100.0/24 --state NEW,RELATED,ESTABLISHED -j ACCEPT

And this is my nat table. The error was omitting the --in-interface parameter:

*nat
:PREROUTING ACCEPT [0:0]
-A PREROUTING -p tcp --dport 12345 -j DNAT --to 192.168.100.210:22
-A PREROUTING -p tcp --in-interface br0 --dport 80 -j DNAT --to 192.168.100.210:80
-A PREROUTING -p tcp --in-interface br0 --dport 443 -j DNAT --to 192.168.100.210:443
-A POSTROUTING -s 192.168.100.0/24 -j MASQUERADE
COMMIT

(Note: For some reason entering these same rules manually while ufw is disabled doesn't produce a working port-forwarding configuration.)

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .