2

My network is composed as follows:

  • Host A with ip 9.x.x.x and vpn ip 192.15.206.x (openvpn client)

  • Host B with ip 9.x.x.x and vpn ip 192.15.206.1 (openvpn server) this host has a bridge br0 with ip 192.168.206.1

  • Host C with ip 192.168.206.2/192.168.206.255 who lives in the vnet0 of host B. the vnet0 is bridged with br0

I want reach C from A. This is what happens:

  • From host B I can ping both A (with 9.x.x.x or 192.15.206.x) and C
  • From host C I can ping both B and A (with 192.15.206.x)
  • From host A I can ping B either with IP 192.15.206.1 or 192.168.206.1 but not C who has IP 192.168.206.2

So the question is why ? The route table is:

192.15.206.2    0.0.0.0         255.255.255.255 UH    0      0        0 tun0
9.168.58.0      0.0.0.0         255.255.255.0   U     0      0        0 eth0
192.15.206.0    192.15.206.2    255.255.255.0   UG    0      0        0 tun0
192.168.206.0   0.0.0.0         255.255.255.0   U     0      0        0 br0
169.254.0.0     0.0.0.0         255.255.0.0     U     1002   0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1004   0        0 br0
0.0.0.0         9.168.58.254    0.0.0.0         UG    0      0        0 eth0

the bridge configuration is:

bridge name     bridge id               STP enabled     interfaces
br0             8000.005056a67d62       no              eth1
                                                        vnet0

The command:

cat /proc/sys/net/ipv4/ip_forward

returns 1

With tcpdump -i tun0 if i run ping 192.168.206.1 on host A:

14:33:23.927126 IP 192.15.206.6 > 192.168.206.1: ICMP echo request, id 768, seq 513, length 40
14:33:23.927191 IP 192.168.206.1 > 192.15.206.6: ICMP echo reply, id 768, seq 513, length 40

the replay it's sent back. But if i run ping 192.168.206.2 on host A the replay it's not sent back.

14:36:33.262959 IP 192.15.206.6 > 192.168.206.2: ICMP echo request, id 768, seq 1281, length 40
14:36:38.749631 IP 192.15.206.6 > 192.168.206.2: ICMP echo request, id 768, seq 1537, length 40

Seems like the packets arrive from A to B with the tun0 device but these are not forwarded to br0 who should send then the packet to vnet0 that connects the C host.

The problem it's related to iptables, indeed by stopping the iptables service i can ping C from A. I tried this rules without success:

-A FORWARD -i br0 -j ACCEPT
-A FORWARD -o br0 -j ACCEPT
-A FORWARD -i br0 -j ACCEPT
-A FORWARD -o br0 -j ACCEPT
-A FORWARD -i vnet0 -j ACCEPT
-A FORWARD -o vnet0 -j ACCEPT
-A FORWARD -i vnet0 -j ACCEPT
-A FORWARD -o vnet0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT
-A FORWARD -i tun0 -j ACCEPT
-A FORWARD -o tun0 -j ACCEPT

Any ideas ?

Bemipefe
  • 115
  • 1
  • 11

2 Answers2

1

This can be

  1. a firewall problem on B (counter intuitive Netfilter blocks packets over a bridge, too)
  2. a firewall problem on C (not very probable)
  3. a routing problem on C

So check iptables -L -nv on B for forwarding and ip route on C.

Edit 1

The firewall on B can be configured to let those packets through by e.g.

iptables -I FORWARD 2 -m physdev --physdev-in vnet0 -j ACCEPT
iptables -I FORWARD 2 -m physdev --physdev-out vnet0 -j ACCEPT

Of course, you may use source and destination addresses instead (or in addition).

Edit 2

Like:

iptables -I FORWARD 2 -s 192.15.206.2 -d 192.168.206.2 -j ACCEPT
iptables -I FORWARD 2 -d 192.15.206.2 -s 192.168.206.2 -j ACCEPT
Hauke Laging
  • 5,285
  • 2
  • 24
  • 40
  • It's a problem related to iptables on host B. Indeed stopping iptables service solve the problem. Of course i can't stop this service for both security issue and routing rules needed and added by the OpenStack component. The iptables it's very long i can't post here. Do you have any hint to find a blocking rule or to add a non blocking one ? – Bemipefe May 02 '13 at 15:43
  • @Bemipefe See the edit. – Hauke Laging May 02 '13 at 15:55
  • Thank you. But this don't solve the problem. – Bemipefe May 03 '13 at 08:52
  • However i think the problem is on br0 not in the vnet0 because the packets pass through br0 before arrive to vnet0 and i can see the packet arrive only to tun0 (with tcpdump) but these never reach the br0 interface. – Bemipefe May 03 '13 at 09:00
  • @Bemipefe You may upvote non-working answers but you should not accept them because that kind of closes the question... See the second edit. – Hauke Laging May 03 '13 at 11:18
0

The issue is probably not relevant for you anymore but I still wanted to leave this here since I had the same issue.

Issue the following command:

#brctl showstp br0
.... other interfaces ....
tun0 (8)
 port id                8008                    state                disabled
 designated root        8000.0cc47a95b66f       path cost                100
 designated bridge      8000.0cc47a95b66f       message age timer          0.00
 designated port        8008                    forward delay timer        0.00
 designated cost           0                    hold timer                 0.00
 flags

Notice that the state of your tun0 is likely disabled. This means that the machine thinks the link is down, thus ignores all packets. You simply need to issue the following command, and the interface will go to learning state, stay there for about 10 seconds and then enter forwarding stage in which everything will go through.

ip link set dev tun0 up
metrotyranno
  • 1
  • 2