Tag Archives: IPv6

IPv6 access with 6to4 OpenWRT Backfire

A little while ago I shared some information on getting IPv6 at home, when all you have is a dynamic (but real/public) IP-address and a good old WRT54GL router with OpenWRT Backfire (brcm-2.4 edition).

I have now stabilized my configuration and I will share some details. You are presumed to

  • be comfortable with editing configuration files manually (using vi, or some other editor in OpenWRT)
  • use OpenWRT Backfire 10.03.1 on your router (which can probably be any router capable of running OpenWRT)
  • have some understanding of what you are about to do and why
  • have a public (but not necessarily static) IPv4 address

If you mess up your firewall rules, worst case you can not log in to your router or you expose your entire network to the world. Proceed at your own risk.

At some point you will start trying your IPv6 connectivity. I suggest using test-ipv6.com, ipv6-test.com and ipv6.google.com.

A good start is the OpenWRT IPv6 Article (it contains much information, but it is not very well structured). First follow the 6to4, 6rd instructions (down to the firewall rule, which is probably fine, but I dont need it).

You also need to enable IPv6 forwarding (which is described in the 6in4 section).
edit /etc/sysctl.conf:



/etc/init.d/sysctl restart

Now you should start testing what works and what does not. Run ifconfig both on the router and on your local machine (ipconfig on Wintendo). If you have a reasonably new OS, you should now at least have an IPv6-address, even if you cant ping6 or connect to anything.

Note: Your 6to4 IP should start with 2002: (both router and clients). Addresses starting with fe80: are private addresses and completely useless.

You probably have a Masquerading firewall configured for IPv4, but if you bother with IPv6 at all you probably don’t want to do Masquerade for IPv6 (dont know if it is possible).

I wanted my IPv4 to work just normally. And I wanted all my LAN-computers to be real IPv6 members accessible from the IPv6 internet (and protected by firewall, as needed, of course). That means, all replies from Internet should be fine, but incoming traffic from Internet should be restricted. The most natural thing would be to use connection tracking, but I encountered problems.

This is what my firewall configuration looks like now:

config 'defaults'
	option 'input' 'DROP'
	option 'output' 'ACCEPT'
	option 'forward' 'DROP'
	option 'syn_flood' '1'
	option 'drop_invalid' '1'
	option 'disable_ipv6' '0'

config 'zone'
	option 'name' 'lan'
	option 'network' 'lan'
	option 'input' 'ACCEPT'
	option 'output' 'ACCEPT'
	option 'forward' 'REJECT'
	option 'mtu_fix' '1'

config 'zone'
	option 'name' 'wan'
	option 'network' 'wan'
	option 'family' 'ipv4'
	option 'masq' '1'
	option 'output' 'ACCEPT'
	option 'forward' 'DROP'
	option 'input' 'DROP'

config 'zone'
	option 'name' 'wan6'
	option 'network' '6rd'
	option 'family' 'ipv6'
#	option 'conntrack' '1' 
	option 'output' 'ACCEPT'
	option 'forward' 'DROP'
	option 'input' 'DROP'

config 'forwarding'
	option 'src' 'lan'
	option 'dest' 'wan'
	option 'family' 'ipv4'

config 'forwarding'
	option 'src' 'lan'
	option 'dest' 'wan6'
	option 'family' 'ipv6'

config 'include'
	option 'path' '/etc/firewall.user'

config 'rule'
	option 'target' 'ACCEPT'
	option '_name' 'IPv6 WRT54GL ICMP'
	option 'src' 'wan6'
	option 'proto' 'icmp'
	option 'family' 'ipv6'

config 'rule'
	option '_name' 'IPv6: Forward ICMP'
	option 'target' 'ACCEPT'
	option 'family' 'ipv6'
	option 'src' 'wan6'
	option 'dest' 'lan'
	option 'proto' 'icmp'

config 'rule'
	option '_name' 'IPv6: WRT54GL "reply" to 1024+'
	option 'target' 'ACCEPT'
	option 'family' 'ipv6'
	option 'src' 'wan6'
	option 'dest_port' '1024-65535'
	option 'proto' 'tcp'

config 'rule'
	option '_name' 'IPv6: Forward "reply" to 1024+'
	option 'target' 'ACCEPT'
	option 'family' 'ipv6'
	option 'src' 'wan6'
	option 'dest' 'lan'
	option 'dest_port' '1024-65535'
	option 'proto' 'tcp'

Some comments on this:

  • I think it makes sense to think about IPv6 Internet as a separate wan6, not as part of wan
  • Incoming traffic is forwarded, as long as it is to unpriviliged ports (1024+)
  • ICMP works between everyone
  • The firewall.user script contains nothing of interest for IPv6
  • Masquerade is activated for wan, but conntrack (or masquerade) does not work for wan6
  • I have not needed a rule to allow INPUT protocol 41 to the router itself (the 6to4 traffic over IPv4), perhaps it gets allowed as ESTABLISHED,RELATED

Bridging and Connection tracking problems
I believe my configuration is working properly. But something is not completely right. Loading the firewall…

root@OpenWrt:~# /etc/init.d/firewall restart
Loading defaults
ip6tables: No chain/target/match by that name.
ip6tables: No chain/target/match by that name.
ip6tables: No chain/target/match by that name.
ip6tables: No chain/target/match by that name.
ip6tables: No chain/target/match by that name.
ip6tables: No chain/target/match by that name.
Loading synflood protection
Adding custom chains
Loading zones
Loading forwardings
Loading redirects
Loading rules
Loading includes
Loading interfaces
ip6tables: No chain/target/match by that name.

In the end of OpenWRT IPv6 documentation:
Note: firewall v1 (e.g. still in Backfire 10.03.1-rc4 and up to r25353) has no default rules at all and ip6tables configuration needs to be done from scratch. Insert the rules below to make the packet filter function properly.

ip6tables -A FORWARD -i br-lan -j ACCEPT
ip6tables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
ip6tables -A FORWARD -j REJECT

Well, I should be on a more recent version (10.03.1) but the second line (with conntrack) gives the No chain/target/match by that name error. I don’t know why, and I don’t know how to fix.

Also, in the same document, under the heading Directly forward ISP’s NDP proxy address to LAN there are instructions for “firewalling on ipv6 even for bridged interfaces”. I believe that this is what I want to do, but the ebtables package/module seems to not be available for WRT54GL/Backfire 10.03.1/brcm-2.4, and it also seems to be known to cause performance problems.


  1. I messed something up when installing/configuring OpenWRT, and now I dont know how to fix it
  2. Something IPv6-related that I want to do is not fully supported on Backfire/brcm-2.4
  3. I am just trying to do the wrong thing, without understanding it

Other config files
In case it is helpful to anyone (and possibly myself in the future) I post a few of my configuration files.

/etc/sysctl.conf (there are more lines)


/etc/config/network (all file)

config 'switch' 'eth0'
	option 'enable' '1'

config 'switch_vlan' 'eth0_0'
	option 'device' 'eth0'
	option 'vlan' '0'
	option 'ports' '0 1 2 3 5'

config 'switch_vlan' 'eth0_1'
	option 'device' 'eth0'
	option 'vlan' '1'
	option 'ports' '4 5'

config 'interface' 'loopback'
	option 'ifname' 'lo'
	option 'proto' 'static'
	option 'ipaddr' ''
	option 'netmask' ''

config 'interface' 'lan'
	option 'type' 'bridge'
	option 'ifname' 'eth0.0'
	option 'proto' 'static'
	option 'netmask' ''
	option 'ipaddr' ''

config 'interface' 'wan'
	option 'ifname' 'eth0.1'
	option 'proto' 'dhcp'

config 'interface' '6rd'
	option 'proto' '6to4'
	option 'adv_subnet' '1'
	option 'adv_interface' 'lan'

/etc/config/radvd (all other configs have option ignore 1)

config interface
	option interface	'lan'
	option AdvSendAdvert	1
	option AdvManagedFlag	0
	option AdvOtherConfigFlag 0
	list client		''
	option ignore		0

And a few packages that you should probably have installed in OpenWRT:


I have not enabled any (IPv6) DHCP – autoconfigure works fine for me. I have also not configured anything DNS related. My normal DNS resolves IPv6-only hosts ok (i.e. ipv6.google.com).

The day I want to allow incoming traffic to just a few of my local/LAN machines I will have to think about it.

The following tools/strategies have proven useful for troubleshooting:

  • ping6 between router and local/LAN machines
  • ping6 to internet hosts (ipv6.google.com)
  • Disable firewall or set policies to ACCEPT
  • Send/receive TCP traffic using ncat (the best nc/netcat) version for OpenWRT.
  • Test ping/ncat to/from an IPv6 host on a different network – I installed miredo on my Lubuntu netbook and let it connect to internet via my iPhone. That way it had no shortcut at all to my router and LAN.
  • I find myself having more success when I unplug my router to restart it; just restarting makes it not come up properly.

In case you are not familiar with ncat:

On the router (start listening):

root@OpenWrt:~# ncat -6 -l -p 9999

On your local computer (send a message):

$ echo 6-TEST | nc 2002:????:????:1::1 9999

On the router (should have got message):

root@OpenWrt:~# ncat -6 -l -p 9999

This is useful all directions, and on different ports, to confirm that your firewall works as you expect.

OpenWRT, IPv6, VPN and Replacing WRT54GL

After having relied on the router my Internet provider has supplied me with for years, I decided to take back control over my LAN. There were a few factors that inspired me to put some effort into this:

  1. The announcement of the WRT1900AC could open up the door for a new generation of routers
  2. IPv6 is getting somewhere and I want to be able to play with it to learn – so I want IPv6 at home
  3. I want a VPN solution at home, for different reasons, but one of them is to be able to access the Internet more safely when using public Wifis, and another is to access services when I am abroad
  4. My Wifi at home (supplied by my router from my Internet provider) was not 100% stable

I ended up keeping my WRT54GL, Installing OpenWRT 10.03.1 on it, and configuring it to provide VPN using PPTP and IPv6 using 6to4. I mostly followed documentation on the OpenWRT web page, but there were and are some issues.
Update 2014-04-12: Details about IPv4 using 6to4.

OpenWRT and WRT54GL
The WRT54GL is not supported by the most recent versions of OpenWRT, and the final release with good WRT54GL support was 10.03.1. Everything I write in this article applies to 10.03.1 (the brcm-2.4 edition).

OpenWRT is very nice. It used to be more hardcore compared to other router firmware. With that I mean that Tomato (and DD-WRT) are 100% Web-GUI-configurable, while OpenWRT was more dependent on the command line. Most things can now be handled using the Web-GUI. But dont attempt to get advanced things (like VPN/PPTP and IPv6) working without using the command line. If you dont feel comfortable with that, just stay with Tomato (which is very nice). This is for OpenWRT 10.03.1 – perhaps more recent version are more configurable without the command line.

For end user needs in 2014, IPv6 is not needed. However, if you anyway decide to play with it, IPv6 is in some ways a more simple protocol than IPv4: not needing a NAT (all your clients get to have real IPs) takes away a lot of things that just happens to be complicated with IPv4. However, although NAT was never meant to provide security it did as a side effect – with IPv6 you need to think about really firewalling incoming traffic to your network. Things like port forwarding and VPN (to access internal resources) suddenly are not needed.

There is also no need for DHCP (as the clients can autoconfigure themselves, and there are so many available addresses on each network, that a conflict is very unlikely). But your IPv6 router must advertise the network so the clients know it exist.

IPv6 – How to get it
How can you get IPv6 if your internet provider only provides IPv4? There are different transition mechanisms that you can use (that are designed just to give you IPv6 when you only have IPv4):

  • Teredo needs to be configured on each client computer seperately, but requires nothing of the network (except that the firewall does not block the traffic). Teredo is the easiest way to access IPv6, but it gives you no IPv6 network. In Debain you just #apt-get install miredo, that is all.
  • Tunnel Brokers provide you IPv6 in a VPN-fashion, much like there are VPN-providers who give you an IP-address in another country, or for anonymization purposes. You can set up the tunnel on a single client, or even better on your router. Your IPv4 router does not have to be your IPv6 router, so it is possible to configure for example a Raspberry Pi as an internal IPv6 router behind a (IPv4) NAT. A Tunner Broker is probably the best and most reliable solution if you have real IPv6 needs. I havn’t tried this, but I suggest start looking at SixXS (who provides free tunnels)
  • 6to4 is a very elegant idea. However, in practice it seems to be a not very popular transition mechanism (supposed to be fading). 6to4 requires that you have a real public IPv4 address (it may be dynamic). This is what I tried, and it works well for me.

Note, when you have IPv6 via a transition mechanism, your cliens may still prefer to use IPv4 when accessing services that are available on IPv4 (which might be all the services you can possibly want to use). There are services to test IPv6.

IPv6 – 6to4 – OpenWRT 10.03.1 on WRT54GL
I followed these instructions (the 6to4 part). I ended up with Firewall problems: the internal IPv6 worked, but I had problems accessing the rest of the world. I have not really stabilized my firewall scripts yet (they give some errors), but if you are not too paranoid, you can try to ACCEPT IPv6 FORWARD on lan (allowing IPv6 traffic from Internet to your local network) and ACCEPT IPv4 INPUT on lan (allowing all IPv4 traffic from Internet to get to your router).
Update 2014-04-12: Details about IPv4 using 6to4.

VPN/PPTP – OpenWRT 10.03.1 on WRT54GL
First, before you set up a PPTP server and use it, consider the security problems with MS-CHAP-v2! If you are aware of the risk and the threat, the advantages with VPN/PPTP are:

  • No need for certificates
  • Good client support

I followed these instructions. Again, I ended up with firewall problems, but found a solution. Try:

iptables -A input_rule -i ppp+ -j ACCEPT
iptables -A forwarding_rule -i ppp+ -j ACCEPT
iptables -A forwarding_rule -o ppp+ -j ACCEPT
iptables -A output_rule -o ppp+ -j ACCEPT

Now, the confusing part is the IP-addresses of your VPN. Each VPN-connection will get both a local and a remote IP-address. And none of these will probably be on your LAN. And this is ok! There is a “localip” option for pptpd which is no longer supported, and I wasted some time trying to assign IP-numbers. But the above firewall rules fixed everything if I just didnt think about about IP-numbers at all.

Best router for OpenWRT
So, what happened to my WRT1900AC plans? Well, the WRT1900AC is not available yet, and I decided to play with my old WRT54GL to see how far I could get with it, and it turned out that for now it does everything I want it to.

OpenWRT has a long list of supported routers (they even have a buyers guide). I did some research (only reading on the Internet) and it seems that TP-link provides fine routers for OpenWRT, for example WDR3600, WDR4300 (N750) or WR1043ND. TP-link also seems to have a good Open Source policy. The N750 is probably what I would buy today, if I were to replace that WRT54GL.

So, what about that WRT1900AC? With Dual core CPU, 256MB of RAM, ESata and USB 3.0 port it is clearly a very capable router. And with 128Mb of storage, much more potent firmwares (or OpenWRT versions) are possible. But is it a good idea? Perhaps the router should only be a router, and other services (fileserver, print server, backup, sql, webserver) are better handled by something else (why not a Raspberry Pi), to not ever disturb the critical router function? I like OpenWRT for having a normal editable filesystem (compared to Tomato or DD-WRT) and packages instead of everything in one image. But 128Mb? Perhaps it would make more sense to just use an SD-card and run Debian?

The WRT1900AC is expensive for being a router, and if it ends up providing no more value/function than the TP N750 mentioned above, what is the point? On the other hand it is not very much money – just expensive for a router. For now I will keep my WRT54GL, but the WRT1900AC is still tempting.