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

Ubuntu server as IPv6 gateway with HE tunnel

Started by langerak, May 01, 2013, 01:28:01 AM

Previous topic - Next topic

langerak

Hi all!

First of all, this is my first post, so if any information is missing that is needed, please let me know so I can supply it :)!

Last week I've received my UPC Horizon box (that is a cable/telephone modem + DVR + router in one box), if needed, more info is below (Dutch!):
http://www.upc.nl/horizon/

As this box is my router as well, and SSH access or any modification is not possible, this cannot be set as my IPv6 tunnel.

I also have a server running Ubuntu 13.04, there I have set up the IPv6 tunnel with the config the HE tunnel tool created for Ubuntu. I have the tunnel working now and am able to ping sites such as Google and Facebook. I also have radvd installed, so that it will serve as ipv6 dhcp server.

What I see is that the radvd service is handing out IP's to the devices on my network, but the given addresses are unable to connect to the outer world. Even a ping to the ipv6 gateway or an ipv6 ip on my local network will not work.

I have the feeling I am missing something here, is it even possible to have the ipv6 part handled by a different machine than the router itself? I think the radvd / server needs to know that it should allow the addresses to connect to the outer world.

My interfaces config is as follows:
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
        address 192.168.0.75
        netmask 255.255.255.0
        network 192.168.0.0
        gateway 192.168.0.1

# IPv6 via Hurricane Electric Tunnel
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
        address 2001:470:1f14:8b3::2
        netmask 64
        endpoint 216.66.84.46
        up ip -6 route add default dev he-ipv6
        down ip -6 route del default dev he-ipv6


My radvd config is below:
interface eth0
{
  AdvSendAdvert on;
  AdvLinkMTU 1480;
  prefix 2001:470:1f14:8b3::/64
    {
     AdvOnLink on;
     AdvAutonomous on;
};
};


On the server I am able to ping:
root@server:~# ping6 www.google.com
PING www.google.com(wb-in-x63.1e100.net) 56 data bytes
64 bytes from wb: icmp_seq=1 ttl=56 time=24.2 ms
64 bytes from wb: icmp_seq=2 ttl=56 time=20.7 ms
64 bytes from wb: icmp_seq=3 ttl=56 time=21.5 ms


I have a NAS as well, which gets an IP from the radvd service:
eth0      Link encap:Ethernet  HWaddr 02:50:43:ef:f0:1f
          inet addr:192.168.0.76  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::50:43ff:feef:f01f/64 Scope:Link
          inet6 addr: 2001:470:1f14:8b3:50:43ff:feef:f01f/64 Scope:Global
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:274 errors:0 dropped:0 overruns:0 frame:0
          TX packets:323 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:39691 (38.7 KiB)  TX bytes:29931 (29.2 KiB)
          Interrupt:11


But when I want to ping the ::2 address that's configured on my server, this will not work:
root@networkspace2:~# ping6 2001:470:1f14:8b3::2
PING 2001:470:1f14:8b3::2(2001:470:1f14:8b3::2) 56 data bytes
From 2001:470:1f14:8b3:50:43ff:feef:f01f icmp_seq=1 Destination unreachable: Address unreachable
From 2001:470:1f14:8b3:50:43ff:feef:f01f icmp_seq=2 Destination unreachable: Address unreachable
From 2001:470:1f14:8b3:50:43ff:feef:f01f icmp_seq=3 Destination unreachable: Address unreachable
^C
--- 2001:470:1f14:8b3::2 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3006ms


As said, the dhcp server seems to be working fine, but the internet is not being relayed correctly. Do I need to bridge anything on the Ubuntu server?

Any help is much appreciated!

kasperd

Quote from: langerak on May 01, 2013, 01:28:01 AMMy radvd config is below:
interface eth0
{
  AdvSendAdvert on;
  AdvLinkMTU 1480;
  prefix 2001:470:1f14:8b3::/64
    {
     AdvOnLink on;
     AdvAutonomous on;
};
};
You are using the wrong prefix. You are supposed to use the routed prefix, not the tunnel link prefix.

langerak

#2
Thanks for the quick reply!

I have changed the prefix and got an ip from the routed ipv6 range that had to be set:
eth0      Link encap:Ethernet  HWaddr 02:50:43:ef:f0:1f
         inet addr:192.168.0.76  Bcast:192.168.0.255  Mask:255.255.255.0
         inet6 addr: 2001:470:1f15:8b3:50:43ff:feef:f01f/64 Scope:Global
         inet6 addr: fe80::50:43ff:feef:f01f/64 Scope:Link
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:197 errors:0 dropped:0 overruns:0 frame:0
         TX packets:259 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 txqueuelen:1000
         RX bytes:19939 (19.4 KiB)  TX bytes:25425 (24.8 KiB)
         Interrupt:11


Yet still, no internet connection can be established, pings are not allowed and even a ping to the gateway is not possible.

I've got the tunnel set up on the server, but should eth0 not contain a ipv6 address as well?

kasperd

Quote from: langerak on May 01, 2013, 01:47:40 AMI've got the tunnel set up on the server, but should eth0 not contain a ipv6 address as well?
Yes, assign an IPv6 address from the routed prefix to that interface. A typical configuration would be to assign 2001:470:1f15:8b3::1 with a 64 bit netmask.

Once you have done that, verify that the NAS and the server can ping each other. If they can ping each other, but you still cannot send packets between the NAS and the HE tunnel server, then you need to enable IPv6 packet forwarding on your server.

langerak

I have changed all settings, on my server, my network config is now:
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
       address 192.168.0.75
       netmask 255.255.255.0
       network 192.168.0.0
       gateway 192.168.0.1

iface eth0 inet6 static
       address 2001:470:1f15:97a::1
       netmask 64
       gateway 2001:470:1f14:97a::2

# IPv6 via Hurricane Electric Tunnel
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
       address 2001:470:1f14:8b3::2
       netmask 64
       endpoint 216.66.84.46
       ttl 64
       up ip -6 route add default dev he-ipv6
       down ip -6 route del default dev he-ipv6

My radvd conf is:
interface eth0  #change this to the interface that connects to the local network
      {
             AdvSendAdvert on;
             AdvHomeAgentFlag off;
             MinRtrAdvInterval 30;
             MaxRtrAdvInterval 100;

             prefix 2001:470:1f15:8b3::/64
             {
                    AdvOnLink on;
                    AdvAutonomous on;
                    #AdvRouterAddr on;\
              };
      };

My sysctl.conf contains these 2 extra lines:
net.ipv6.conf.all.forwarding=1
net.ipv6.conf.default.forwarding=1


I am still able to ping Google from the server.

On the NAS the network config is:
auto lo
iface lo inet loopback

# The primary network interface
auto eth0
iface eth0 inet static
       address 192.168.0.76
       gateway 192.168.0.1
       netmask 255.255.255.0
iface eth0 inet6 static
       address 2001:470:1f15:8b3::2
       netmask 64
       gateway 2001:470:1f15:8b3::1


From the NAS I cannot ping the server nor Google. From the server I can ping Google, but not the NAS.\

The guide I used is this one:
https://erikbandersen.com/wordpress/?p=28

At this point I don't know what I'm doing wrong... :(

kasperd

Quote from: langerak on May 01, 2013, 05:12:17 AMiface eth0 inet6 static
       address 2001:470:1f15:97a::1
       netmask 64
       gateway 2001:470:1f14:97a::2
Where did the 97a come from? It should have been 8b3. Also, you shouldn't be specifying your IPv6 gateway on eth0, but rather on the tunnel interface.

Quote from: langerak on May 01, 2013, 05:12:17 AM        up ip -6 route add default dev he-ipv6
        down ip -6 route del default dev he-ipv6
These two commands are redundant, when you have specified a gateway.

You appear to be specifying a default route both with and without gateway. Whether specifying a gateway in the route or not makes a difference depends on the underlying media type. On a point to point tunnel, including the gateway doesn't actually make a difference.

I'd use the gateway specification rather than the two route commands since it is shorter and cleaner. So put the gateway specification on the tunnel interface instead and remove the two route commands, and fix the incorrect IP addresses, then I think you are done.

langerak

I saw the 97a flaw just as of now :), it's working now.

I have removed the 2 up/down rules as well, everything is working as expected now!

Thank you very much!