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

Easy Config for Linux Router

Started by angelou, February 02, 2011, 11:53:09 AM

Previous topic - Next topic


Greetings All,

Since I spent the better part of the day trying to figgure out an easier way to do this in Ubuntu 10.10, I thought I would post the end results so it might be helpful to others.  I considered doing this on my DD-WRT, but for now wanted to keep it seperate for testing and to see how easy it would be from the local network standpoint.  This Ubuntu server is running on an VirtualBox VM using the Vitiro network drivers and is operating very well.  I tweaked the addresses below obfuscate me.

You need to install radvd which is available from apt-get and then tweak the following files to suit your needs.

/etc/network/interfaces: = HE Server IPv4 Endpoint
2001:470:8:7aa::1 = Static IPv6 assignment from my routable range to the linux router interface. (Can be any ip in routed range)
2001:470:7:7aa::2 = Client IPv6 Endpoint

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface - ipv4
auto eth0
iface eth0 inet dhcp

# The primary network interface - ipv6
iface eth0 inet6 static
     address 2001:470:8:7aa::1
     netmask 64

# IPv6 via Hurricane Electric Tunnel
auto he-ipv6
iface he-ipv6 inet6 v4tunnel
     address 2001:470:7:7aa::2
     netmask 64
     up ip -6 route add default dev he-ipv6
     down ip -6 route del default dev he-ipv6


2001:470:8:7aa::/64 = Routed range you are using

interface eth0
        AdvSendAdvert on;

        # Disable Mobile IPv6 support
        AdvHomeAgentFlag off;

        prefix 2001:470:8:7aa::/64
                AdvOnLink on;
                AdvAutonomous on;

                # Disable Mobile IPv6 support
                AdvRouterAddr off;


Add or Uncomment the following line

net.ipv6.conf.all.forwarding = 1

That's it, with the above configurations all ipv6 capable computers on my local lan assigned an address in the routed range and are transporting data over the HE tunnel.  Hope this helps others out there. 


Thank you for this post.  It made it easy for me to get the tunnel working on a small Ubuntu Server system which is not my main router.

In addition to what you posted above I added firewall rules based on some other forum posts.  After creating the rules file below I added the following to the auto he-ipv6 section of /etc/network/interfaces:

up ip6tables-restore < /etc/ip6tables.rules


# Generated by ip6tables-save v1.4.4 on Tue Feb  8 07:48:10 2011
-A INPUT -p ipv6-icmp -m limit --limit 50/min -j ACCEPT
-A INPUT -i he-ipv6 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -i eth0 -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -j REJECT --reject-with icmp6-port-unreachable
-A FORWARD -p ipv6-icmp -m limit --limit 50/min -j ACCEPT
-A FORWARD -i he-ipv6 -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i eth0 -j ACCEPT
-A FORWARD -j REJECT --reject-with icmp6-port-unreachable
# Completed on Tue Feb  8 07:48:10 2011


-A INPUT -p ipv6-icmp -m limit --limit 50/min -j ACCEPT

Maybe I am missing something here but it looks like this rule makes it trivially easy to launch a denial of service attack against the network.

If I were to ping your router or any host behind it at a fairly high rate I would quickly fill up the 50 per minute allocation of ICMPv6 packets. Once that happens Neighbor Discovery packets will no longer be allowed to enter the router. Since Neighbor Discovery is the IPv6 functional equivalent of ARP and neighbor information is generally only cached for a short period of time it won't be long before the L3 address-> L2 address neighbor cache times out and your router is no longer able to communicate with IPv6 hosts inside your network.

In fact since the rate limit is 50 per minute you could probably do something like this on any IPv6 enabled Windows box and have a pretty good chance at causing intermittent connectivity issues for a few hosts behind the router:

ping -t 2001:470:8:7aa::1

Write a script to send 5 pings per second or more and you'll really start causing havoc. This reminds me of the days when you could launch a DOS attack with only 8 SYN packets. ;)


I added the rate limit since it was suggested by an HE employee in this thread.


Yeah I saw that thread too. It wasn't until a few days later that I realized how easy a rate limit like that makes it to attack a network.

Personally I don't really see the logic behind rate limiting ICMPv6. With the more dangerous ICMP types like time stamp request/reply and mask request/reply removed from the v6 version I don't think ICMP will pose the same sort of dangers in IPv6 that it does in IPv4. I guess you could get more granular with the firewall rules and only rate limit or block certain ICMPv6 type codes like echo request, echo reply, and trace route or whatever but since those are pretty harmless I really don't see the point.

I am rather curious as to what jrocha's reasoning behind his recommendation is.


Perhaps that limit rule needs -i he-ipv6 so it only applies to traffic on the tunnel.

I'm afraid my iptables skills have gotten rusty.

EDIT: Really rusty.  If the limit rule fails to match due to a high rate, the -i eth0 -j ACCEPT rule will still pass link local ICMPv6, right?  So Neighbor Discovery won't be affected by the rate limit.


Limiting the rate limit to traffic on the tunnel interface won't do any good since that's where the malicious traffic will be coming from anyway.

I think you are right about the second bit though. "-i eth0 -j ACCEPT" should just allow everything in blindly, link local or otherwise. (My iptables knowledge is also a bit rusty. ;)) But if you have a blanket accept rule a couple of lines down then what is the point of having the rate limit rule there at all? Or the stateful rule for that matter?

Neighbor discovery actually runs on solicited node multicast addresses, which always start with "ff" and are dynamically generated based on the global unicast address. So I suppose if you started your iptables rules with statements that allowed all traffic from fe80::/10 and ff::/8 you would be alright I think.


Actually with all three policies set to ACCEPT, most of those rules are meaningless, the only one doing anything is probably the rate limit.


Before I added the recommended rate limit I tested to rules with the HE nmap tool and they have the desired effect of blocking all incoming tunnel traffic while allowing all outgoing traffic.  So they work for me.