ipv6 networking fails

[Nobby6]

Hi,
Firstly, I'll admit I'm not expert with ipv6, but have been around in the ipv4 world for nearly 20 years.

I have for a while been running a private ipv6 LAN at home using  fd0d:......./64  this works fine linux LAN.

So I set up a tunnel here with HE, from the box that connects which I'll call GW I can ping  the other end of tunnel and get out to the world.

But, (yep there's always a but!) this is where it all ends....  I removed the fd0d private range, substituting it for the routed /64 range HE gives us (yes, the routed, not the tunnel's /64), but now, the LAN does not on any machine, no box on the LAN can reach any other box on the LAN using ipv6 nor access the internet via ipv6. I am using static IP's not dynamic, so radvd and dhcp6 etc are not in use.

I'll show the config for  GW and one other box (all in use are linux) and I fudge one section to protect the guilty ;)  XXX1 will be the tunnel and XXX2 is the routed /64


GW:
 (sysctl.conf) net.ipv6.conf.all.forwarding=1

he-ipv6   Link encap:IPv6-in-IPv4  
         inet6 addr: 2001:470:XXX1:524::2/64 Scope:Global
         inet6 addr: fe80::a0a:91/128 Scope:Link


eth0    
         inet6 addr: 2001:470:XXX2:524::5/64 Scope:Global
         inet6 addr: fe80::211:50ff:fe08:2ad9/64 Scope:Link

2001:470:XXX1:524::/64 via :: dev he-ipv6  proto kernel  metric 256  mtu 1480 advmss 1420 hoplimit 0
2001:470:XXX2:524::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
fe80::/64 via :: dev he-ipv6  proto kernel  metric 256  mtu 1480 advmss 1420 hoplimit 0
fe80::/64 dev eth0  proto kernel  metric 256  mtu 1500 advmss 1440 hoplimit 0
default dev he-ipv6  metric 1024  mtu 1480 advmss 1420 hoplimit 0



On the second box

eth0    
         inet6 addr: fe80::214:c2ff:fe0b:dccf/64 Scope:Link
         inet6 addr: 2001:470:XXX2:524::6/64 Scope:Global

2001:470:XXX2:524::/64 dev eth0  proto kernel  metric 256
fe80::/64 dev eth0  proto kernel  metric 256
ff00::/8 dev eth0  metric 256
default via 2001:470:XXX2:524::5 dev eth0  metric 1024


This is loaded from rc.ipv6 as:

/usr/sbin/ip addr add 2001:470:XXX2:524::6/64 dev eth0
/usr/sbin/ip -6 route add default via 2001:470:XXX2:524::5 dev eth0


I have also tried swapping the GW pc around to another box.
PC's to world _or_ GW with ipv6 all result in:  Destination unreachable: Address unreachable
Machines ping6'ing themselves do respond.

Removing all gateways and downing tunnels, so basically replicating my private range setup with no gateways defined even, still all fails.

Appreciate someone batting me with a clue stick , I'm sure the problem is obvious to everyone but me :)
Especially as to why the XXX2 range wont work locally either when the fd0d......... range did. I have another box on network setup same as second box with its diff IP of course, and suffers same fate.
all boxes have been rebooted in case, and the ipv6 forwarding in sysctl is only active on the gw pc, but was also tried on a second machine with no change.

Nobby

[cholzhauer]

Blocking out the ip's doesn't help and confuses us more.

To confirm, your client machines can't ping your "gateway"?

[Nobby6]

Blocking out the ip's doesn't help and confuses us more.

To confirm, your client machines can't ping your "gateway"?

Not sure how it confuses you :) they are real IP's only 3 octets changed to XXX instead of what the three HE issued me.

Correct, and gateway can not ping the client machines

Forgot to add, no firewalls are in us on LAN either at present.

[cholzhauer]

It is just easier (especially when working with multiple subnets) to not obfuscate the IP address.  If you don't want to share your IP address for some reason, use the documentation prefix of 2001:db8::/32 that was designed for this purpose. 

Did you try RA or was static addressing your first attempt at making this work?  Unless I'm missing something really obvious, I don't see any issues with the config you've listed.

What kernel are you running?  I seem to recall people having problems with older kernels in the forums.

[broquea]

A reason not to obfuscate is in case we want to try reachability tests, and making sure there aren't any typos in the addresses. Like making certain we see 2001:470:XXX2:524::5 is reachable, thus confirming your static route upstream is in place.

Regardless, if your machines on the LAN can't ping each other, something is amiss. Did you have any ip6tables rules on your linux machines for allowing the ULA space, or at all?

[broquea]

Ok well seeing as this is in my ipv6-ops folder as well, after you try Eric's suggestion of pinging multicast, if you renumber back to ULA, does it all work?

[Nobby6]

It is just easier (especially when working with multiple subnets) to not obfuscate the IP address.  If you don't want to share your IP address for some reason, use the documentation prefix of 2001:db8::/32 that was designed for this purpose. 

Did you try RA or was static addressing your first attempt at making this work?  Unless I'm missing something really obvious, I don't see any issues with the config you've listed.

What kernel are you running?  I seem to recall people having problems with older kernels in the forums.

Static addressing is what I use, and I have used before on VPS's, and they worked, what I cant understand is why, with this range, client a and b also cant talk to each other with no firewall rules, does the kernel treat 2003/3 different?  

One PC is opensuse with 2.6 kernel, and another two are slackware with custom kernels both 3.8.2
at present opensuse is GW, however, I also tried one of the slackware as GW as well, so unless their all-in-one kernel and my custom are both missing a critical kernel function, which might be it since I see no reason foir this not working, at least client to client.

If it helps:

CONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=y
# CONFIG_IPV6_SIT_6RD is not set
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_GRE is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y


Thanks

[Nobby6]

Ok well seeing as this is in my ipv6-ops folder as well, after you try Eric's suggestion of pinging multicast, if you renumber back to ULA, does it all work?

ULA? You mean the private range like fd0d:......?  Then yes that works if I renumber back to it, and no iptables rules exist, when I had reachability issues, flushing and setting policy to accept was first thing I did, sorry if I forgot to mention it.

[Nobby6]

You are correct about iptables, it is still showing rules FFS, I had to disable the firewall script and reboot, seems to have fixed  the LAN to LAN... no idea why it was not flushing...

They all respond with multiple returns, but clients can still not access the Inet via the GW...

This is the only problem (I think) that remains

Now traceroute shows timeouts
1  * * *
2  * * *
3  * * *
...

[broquea]

Ok so, if you tcpdump on the router's LAN interface are you seeing the traceroute packets from the LAN PCs make it to that interface?
Can the router ping/reach the LAN machines?
I know you already pasted your sysctl setting for forwarding, but can you make certain it has taken effect either by examining sysctl -a output, or checking in /proc?
And the last-ditch idea I can think of is, are any of these boxes running an RHEL variant that might be using kernel 2.6.18? That had a broken default route issue, where you had to specify 2000::/3 instead of "default" or ::/0

[Nobby6]

Ok so, if you tcpdump on the router's LAN interface are you seeing the traceroute packets from the LAN PCs make it to that interface?

Sure can.

Can the router ping/reach the LAN machines?

Now they can yes.

I know you already pasted your sysctl setting for forwarding, but can you make certain it has taken effect either by examining sysctl -a output, or checking in /proc?

Yes, that's showing 1, I see (from the GW)

09:30:30.519158 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:470:xxx2:524::6 > 2404:6800:4006:801::1013: ICMP6, echo request, length 64, seq 49
09:30:31.527219 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:470:xxx2:524::6 > 2404:6800:4006:801::1013: ICMP6, echo request, length 64, seq 50

etc etc with ping6 ipv6.google.com

And the last-ditch idea I can think of is, are any of these boxes running an RHEL variant that might be using kernel 2.6.18? That had a broken default route issue, where you had to specify 2000::/3 instead of "default" or ::/0

Nope , but I will changing to 2003::/3
OK, that made no difference.

[broquea]

You mean you tried using 2000::/3 right? 2003::/3 isn't a default route, nor is it a /3 allocation :)

I'd email HE and have them verify the static route for your routed /64 is correctly in place, and no other dupes configured on the tserv. Also maybe ask them to manually tear down the tunnel on their side, and rebuild either using their lovely automated scripts, or by hand. I'd do that before deleting the tunnel and trying to create another one as suggested on ipv6-ops.

[Nobby6]

Ok so, if you tcpdump on the router's LAN interface are you seeing the traceroute packets from the LAN PCs make it to that interface?

Sure can.

Can the router ping/reach the LAN machines?

Now they can yes.

I know you already pasted your sysctl setting for forwarding, but can you make certain it has taken effect either by examining sysctl -a output, or checking in /proc?

Yes, that's showing 1, I see (from the GW)

09:30:30.519158 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:470:xxx2:524::6 > 2404:6800:4006:801::1013: ICMP6, echo request, length 64, seq 49
09:30:31.527219 IP6 (hlim 64, next-header ICMPv6 (58) payload length: 64) 2001:470:xxx2:524::6 > 2404:6800:4006:801::1013: ICMP6, echo request, length 64, seq 50

etc etc with ping6 ipv6.google.com

And the last-ditch idea I can think of is, are any of these boxes running an RHEL variant that might be using kernel 2.6.18? That had a broken default route issue, where you had to specify 2000::/3 instead of "default" or ::/0

Nope , but I will changing to 2003::/3
OK, that made no difference.

Hey.. thanks VERY much for your help (and education) now we have sorted out the LAN, the GW must have issues, because swapping the GW and client machines around it is working !@!!!
So the GW problem is related to the OS, once swapped to the slackware 3.8.2 kernel as GW I can get out and get to it.

so problem was combination of operator (isnt it always) and a crook OS which in about 20 minutes (after my coffee) will be formatted and updated to current version.

[Nobby6]

You mean you tried using 2000::/3 right? 2003::/3 isn't a default route, nor is it a /3 allocation :)

I'd email HE and have them verify the static route for your routed /64 is correctly in place, and no other dupes configured on the tserv. Also maybe ask them to manually tear down the tunnel on their side, and rebuild either using their lovely automated scripts, or by hand. I'd do that before deleting the tunnel and trying to create another one as suggested on ipv6-ops.

Yes sorry - lacking of sleep/caffeine.

[broquea]

What was the GW's previous distro/kernel rev before the reinstall you are going to perform?