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

IPv6 output from client OK, replies not seen

Started by swsnyder, August 18, 2008, 02:02:51 PM

Previous topic - Next topic

swsnyder

I've set up a tunnel on a machine (server, CentOS v5.2) with 2 Ethernet interfaces.  Interface eth0 is internal while eth1 faces the Internet.  Another machine (client, Fedora8) will be using native IPv6 communication with the server. 

I find that IPv6 packets are routed correctly on the server:

# ping6 ipv6.breezy.ca
PING ipv6.breezy.ca(ipv6.breezy.ca) 56 data bytes
64 bytes from ipv6.breezy.ca: icmp_seq=0 ttl=58 time=160 ms
64 bytes from ipv6.breezy.ca: icmp_seq=1 ttl=58 time=156 ms
64 bytes from ipv6.breezy.ca: icmp_seq=2 ttl=58 time=149 ms

On the client machine IPv6 activity just hangs forever.  So I've tried running tcpdump to get an idea of what's going on.  The server network traffic is dumped while the client is attempting to ping ipv6.breezy.ca. 

Running tcpdump (and wireshark) on the client shows only ICMP6 echo requests and RADVD advertisements/solicitations.  Nary an echo reply seen. 

Running tcpdump on server interface eth0 (internal LAN) shows only the expected ICMP6 echo requests and requests to RADVD for solicitaions. 

Running tcpdump on sit1 is where it gets interesting.  See below.  Now the echo replies are finally seen.  But what the &%^*^%$!  is that redirect doing? 

I do have an iptables firewall in place on the server machine, but when I briefly flushed and deleted all rules I saw no change in client ping6 behavior. 

Anyone have any idea as to what could be going on here?  Thanks.




The server interfaces:

eth0      Link encap:Ethernet  HWaddr 00:0F:B5:04:4E:2D
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::20f:b5ff:fe04:4e2d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:7187 errors:0 dropped:0 overruns:0 frame:0
          TX packets:10341 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2210597 (2.1 MiB)  TX bytes:9772907 (9.3 MiB)
          Interrupt:11 Base address:0x8000

eth1      Link encap:Ethernet  HWaddr 00:10:4B:F6:56:8C
          inet addr:69.245.199.228  Bcast:255.255.255.255  Mask:255.255.252.0
          inet6 addr: fe80::210:4bff:fef6:568c/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:67807 errors:0 dropped:0 overruns:6 frame:0
          TX packets:9416 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:13428485 (12.8 MiB)  TX bytes:2605384 (2.4 MiB)
          Interrupt:11 Base address:0xe000

sit0      Link encap:IPv6-in-IPv4
          inet6 addr: ::127.0.0.1/96 Scope:Unknown
          inet6 addr: ::69.245.199.228/96 Scope:Compat
          inet6 addr: ::192.168.0.1/96 Scope:Compat
          UP RUNNING NOARP  MTU:1480  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)

sit1      Link encap:IPv6-in-IPv4
          inet6 addr: 2001:470:1f10:175::2/64 Scope:Global
          inet6 addr: fe80::45f5:c7e4/64 Scope:Link
          inet6 addr: fe80::c0a8:1/64 Scope:Link
          UP POINTOPOINT RUNNING NOARP  MTU:1480  Metric:1
          RX packets:105 errors:0 dropped:0 overruns:0 frame:0
          TX packets:244 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:13985 (13.6 KiB)  TX bytes:36559 (35.7 KiB)


----------------------------


# tcpdump -t -n -i sit1 -s 512 ip6 or proto ipv6

CLIENTIP=2001:470:1f11:175:230:48ff:fe7e:ecee
BREEZYIP=2001:470:8:24:201:3ff:fee2:e12a
TUNNLINK=fe80::c0a8:1

IP6 $CLIENTIP > $BREEZYIP: ICMP6, echo request, seq 1, length 64
IP6 $BREEZYIP > $CLIENTIP: ICMP6, echo reply, seq 1, length 64
IP6 $TUNNLINK > $BREEZYIP: ICMP6, redirect, $CLIENTIP to $CLIENTIP, length 160
IP6 $BREEZYIP > $CLIENTIP: ICMP6, echo reply, seq 1, length 64

IP6 $CLIENTIP > $BREEZYIP: ICMP6, echo request, seq 2, length 64
IP6 $BREEZYIP > $CLIENTIP: ICMP6, echo reply, seq 2, length 64
IP6 $TUNNLINK > $BREEZYIP: ICMP6, redirect, $CLIENTIP to $CLIENTIP, length 160
IP6 $BREEZYIP > $CLIENTIP: ICMP6, echo reply, seq 2, length 64




And, of course, the obligatory server routing table:

# route -A inet6
Kernel IPv6 routing table
Destination                        Next Hop  Flags Metric Ref    Use Iface
*/96                               *         U     256    0        0 sit0
2001:470:1f10:175::/64             *         U     256    0        0 sit1
2000::/3                           *         U     1024   0        0 sit1
fe80::/64                          *         U     256    0        0 eth0
fe80::/64                          *         U     256    0        0 eth1
fe80::/64                          *         U     256    0        0 sit1
*/0                                *         U     1      0        0 sit1
localhost6.localdomain6/128        *         U     0      0        1 lo
::69.245.199.228/128               *         U     0      0        1 lo
127.0.0.1/128                      *         U     0      0        1 lo
192.168.0.1/128                    *         U     0      0        1 lo
2001:470:1f10:175::/128            *         U     0      0        2 lo
......tserv9.chi1.ipv6.he.net/128  *         U     0      85       1 lo     
fe80::/128                         *         U     0      0        2 lo
fe80::/128                         *         U     0      0        2 lo
fe80::/128                         *         U     0      0        2 lo
fe80::45f5:c7e4/128                *         U     0      0        1 lo
fe80::c0a8:1/128                   *         U     0      0        1 lo
fe80::/128                         *         U     0      0        2 lo
fe80::/128                         *         U     0      0        2 lo
fe80::/128                         *         U     0      0        2 lo
fe80::45f5:c7e4/128                *         U     0      0        1 lo
fe80::c0a8:1/128                   *         U     0      0        1 lo
fe80::20f:b5ff:fe04:4e2d/128       *         U     0      26       1 lo
fe80::210:4bff:fef6:568c/128       *         U     0      0        1 lo
ff00::/8                           *         U     256    0        0 eth0
ff00::/8                           *         U     256    0        0 eth1
ff00::/8                           *         U     256    0        0 sit1


broquea

#1
First thing that I'd guess at is: is sysctl set to forward all ipv6 packets?
Then, are you assigning the first address out of the advertised /64 to eth0 (2001:470:1f11:175::1/64) since radvd is configured to use that interface?

swsnyder

Quote from: broquea on August 18, 2008, 02:31:41 PM
First thing that I'd guess at is: is sysctl set to forward all ipv6 packets?
Then, are you assigning the first address out of the advertised /64 to eth0 (2001:470:1f11:175::1/64) since radvd is configured to use that interface?


Yes to the 1st question:

# sysctl net.ipv6.conf.all.forwarding
net.ipv6.conf.all.forwarding = 1

No to the 2nd question.  My understanding is that one is supposed to provide the prefix, not an address.  This is my radvd.conf file:


interface eth0
{
   AdvSendAdvert on;
   AdvHomeAgentFlag off;
   MinRtrAdvInterval 30;
   MaxRtrAdvInterval 100;
   prefix 2001:470:1f11:175::/64
   {
      AdvOnLink on;
      AdvAutonomous on;
      AdvRouterAddr off;
   };
};


The debug output of "radvdump -d 4" looks reasonable to me.  Or at least no more unreasable than the parameters I specified:


# radvdump -d 4
[Aug 18 18:09:53] radvdump: recvmsg len=56
[Aug 18 18:09:53] radvdump: receiver if_index: 3
#
# radvd configuration generated by radvdump 0.9.1
# based on Router Advertisement from fe80::20f:b5ff:fe04:4e2d
# received by interface eth0
#

interface eth0
{
        AdvSendAdvert on;
        # Note: {Min,Max}RtrAdvInterval cannot be obtained with radvdump
        AdvManagedFlag off;
        AdvOtherConfigFlag off;
        AdvReachableTime 0;
        AdvRetransTimer 0;
        AdvCurHopLimit 64;
        AdvHomeAgentFlag off;
        AdvDefaultPreference medium;
        AdvSourceLLAddress on;

        prefix 2001:470:1f11:175::/64
        {
                AdvValidLifetime 2592000;
                AdvPreferredLifetime 604800;
                AdvOnLink on;
                AdvAutonomous on;
                AdvRouterAddr off;
        }; # End of prefix definition

}; # End of interface definition





Thanks for the response.

broquea

I've always just added the first usable from the routed allocation to the internal LAN interface, and not had problems.
The following is a rough draft that I wrote a while back with working examples: http://broquea.corp.he.net/ddwrt/rough-office-v6.pdf
Also you mentioned some iptables configuration, but make sure you are looking at the ip6tables config as well.

swsnyder

Quote from: broquea on August 18, 2008, 03:39:03 PM
I've always just added the first usable from the routed allocation to the internal LAN interface, and not had problems.

That fixed it for me.  I can't say that I understand how that fixed it, but after wrestling with this for 3 days, it is very nice to see IPv6 Internet access on my client machine.

Thanks so much!