• Welcome to Hurricane Electric's IPv6 Tunnel Broker Forums.

A can't Ping B until C has pinged A (ipv6)

Started by higgers, February 26, 2011, 01:26:51 AM

Previous topic - Next topic

higgers

I have two Debian 6 x64 VMs running under ESXi4.1_U1. One of the VMs is acting as an ipv4 and ipv6 firewall/router using shorewall and has three virtual NICs, LAN, WAN and DMZ. I've set up a 6in4 ipv6 tunnel from Hurricane Electric but have a peculiar problem. The router can ping6 ipv6.google.com without problem, however any other VMs or physical boxes on the LAN can't ping6 ipv6.google.com until I ping6 the box from the router.

The sequence of events is:


higgers@ubuntu904:~$ ping6 ipv6.google.com
PING ipv6.google.com(2a00:1450:8006::63) 56 data bytes1.


ubuntu904 is client VM that sits behind the router VM. There is no feedback from ping6 command other than what you see above.


root@debian6:/etc/shorewall# ping6 ubipv6
PING ubipv6(2001:blah:blah:blah:blah:29ff:feb3:490f) 56 data bytes
64 bytes from 2001:blah:blah:blah:blah:29ff:feb3:490f: icmp_seq=1 ttl=64 time=3.57 ms
etc
etc
etc


debian6 is the router VM. As soon as it pings ubuntu904 (ipv6 AAAA record on my internal DNS server uses the name ubipv6) I start getting responses from the ping6 on ubuntu904:


higgers@ubuntu904:~$ ping6 ipv6.google.com
PING ipv6.google.com(2a00:1450:8006::63) 56 data bytes
64 bytes from 2a00:1450:8006::63: icmp_seq=141 ttl=53 time=321 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=142 ttl=53 time=321 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=143 ttl=53 time=321 ms
64 bytes from 2a00:1450:8006::63: icmp_seq=144 ttl=53 time=322 ms


Happy days! The client VM can ping6 google!

I've verified the same behaviour on a physical client machine running ubuntu 10.10. I'd like to test the behaviour on my opensolaris box but I can't find out how to enable ipv6 on it without rebooting it. It's hosting the NFS share that the VM images sit on and it's a bit of a ball ache to reboot it, especially when it hosts the image for the main router for the LAN and I'm currently offsite.

ipv6 addresses are issued using radvd on the router VM.

Any ideas what I should check?

PsilonuX

#1
Hi,

I'm experiencing a similar problem. From client I first need to ping6 my lan nic from where radvd is advertising, before I can reach any external ipv6 address. I must repeat this after idling. Im still searching whats causing this trouble . I'm thinking about radvd, or maybe some bad routing.

I have a ubuntu 10.04 box acting as router with shorewall (only 2 NICs) and a 6in4 tunnel. From here I have no problem pinging any external ipv6 address. The problem resides from client side. All ip6table rules are deleted, and policies set to ACCEPT.

caltechsol

Check that you have all the VMWare drivers loaded for whatever VM network card you're using; some need the VMWare tools loaded or they won't work correctly (offload, etc). e1000 is pretty good if you don't want to load anything.

gafe

Exactly the same here, fedora X64 in VirtualBox (local tunnel side and radvd advertising my /64) , it works correctly, clients (Windows 7 and Mandriva) can reach internet only after pinging the local tunnel ip. If you left clients idle they "disconnect" and you have to ping from clients the local side of tunnel in fedora to get it to work again.

Will try this evening to capture traffic in wireshark.


gafe

#4
For me, it was a routing problem. My side of tunnel it is 2001:470:1f08 and my /64 2001:470:1f09

In ip -6 route i had this (don't remember why):
2001:470:1f08:7d6::/64 via :: dev he-ipv6 .........

removing that line made it work as it's supposed (ip -6 route del 2001:470:1f08:7d6::/64)

Try posting here your routes (ip -6 route)

Edited again: not so clear....after a reboot didnt work...surely i do something more, but it's related to routing.

See you later


cholzhauer

Quote
Edited again: not so clear....after a reboot didnt work...surely i do something more, but it's related to routing.

You said it worked before you rebooted, then it didn't work after you rebooted...Did you make sure to put those routes in a place where they'd be run on startup?

gafe

#6
It's solved now (searching this forums):

- First, sysctl -w net.ipv6.conf.all.forwarding=1 must be BEFORE creating tunnel.
- Second, had to add the /64 route to eth0 ( route -A inet6 add 2001:470:1f09:7d6::/64 eth0)

After that, it works like a charm on Mandriva and Windows 7 as clients.

I find it here:
http://www.tunnelbroker.net/forums/index.php?topic=241.msg1469#msg1469

and here:
http://www.tunnelbroker.net/forums/index.php?topic=1415.msg8063#msg8063

Thanks all.

To correct my earlier post, that route was correct XD