GHSWiki

Gothenburg Hackerspace Wiki

User Tools

Site Tools


members:klondike:ipv6_deployment

IPv6 deployment at Vegagatan 1

The following article is intended more as personal write up on the deployment, the experiences we had with it and the discussions, it also gives a hint about the future there, although as usual, the future is… future :P

First steps: using a tunnel endpoint at the router

The first test deployment we did involved basically setting up a tunnel endpoint on the router so we could try IPv6 from there. Back then the router was a repurposed desktop Pentium 4 with 3 Fast Ethernet interfaces on which we installed Gentoo Hardened.

The idea behind it was testing a few things:

  1. Whether our ISP (Bredbandsbolaget) allowed proto 41 traffic
  2. Whether our firewall rules for inbound traffic were appropriate
  3. Whether our setup could support IPv6
  4. Whether IPv6 worked as expected or not (latency is not a big problem but things like network speed may matter here).

Once that was done the thing amounted to picking a 6in4 provider. We chose Hurricane Electric for their niceness and because I had been using them at the xiscosoft network for some time over SixXS with whom I have already had some trouble.

So well, I registered the account for GbgHackerspace and did the tests so I could enable IRC passthrough (which is an important service for us).

The tests were (as you can suppose) very successful. We discovered we needed to enable icmp ping traffic to the router Internet address to register the tunnel (as we were on this we enabled it too for icmpv6 as it simplifies network checking). We also discovered that protocol 41 packets may be dropped at times even if using a ESTABLISHED,RELATED catch all rule so we allowed them to pass through when coming from our tunnel remote endpoint,

Finally I had to set up a small script that would update the endpoint ip address on Hurricane's server as we had a dynamic IP address then, I made it to run every 5 minutes in a cron job, although I was considering setting it up as a dhcpcd hook so it would be called automatically when our ip was set by Bredbandsbolaget's DHCP server.

Once this was done, it was time to do the testing. The tests we made (ping6, wget -6, Gentoo portage tree syncs and even running a znc server) were quite successful and worked as well as we expected over a few weeks, so with this, we were ready to deploy IPv6 on the whole Hackerspace network.

First problem: the router migration

One of the problems we had was that the line we installed provides 250/100 connectivity over a gigabit ethernet line to the router. We had prepared for this and both the core switch and the wireless APs we set up support both IPv6 and Gigabit Ethernet, but our router has only Fast Ethernet Interfaces (before getting the line with Bredbandsbolaget we were using a 3G modem so we didn't need more) and the replacement was not going to come any time soon. But then, an anonymous person (we keep him anonymous for obvious reasons) came with a procera packetlogic pbs (with a nice Silicom card with two bridgeable gigabit ethernet ports and stuff).

The Procera box has some fun problems, the first is that it refuses to start up (unless you short the power pin in the powersource) unless you have something connected on the administrative LAN. The second is that the Silicom cards aren't supported by recent kernels (trying to integrate their GPL drivers with the original ones is on my TODO list). The third is that it takes a long time to boot thanks to its SCSI card. But well despite all we installed Gentoo Hardened on it and it seems to work well so far, although having to connect to a Raspberry PI to access the Serial port is a little bit painful.

Once we had installed Gentoo Hardened on it and migrated the tunnel config, the dnsmasq config and the network config (and figured out some strange problems involving Netgear's Green Ethernet support) we got the whole thing working with dynamic IPv4 addresses.

Since we are using /16 private pools assigned based on MAC addresses lease conflicts weren't a big problem and after fixing some minor problems with the firewall, the house made initrd and damned udev we got the thing up and working and did a seamless handover.

Second problem: the political discussion

My original intention was setting up a completely unfiltered (other than port 25 done by Hurricane by default) network so people on the Hackerspace could easily connect to whichever IPv6 they wanted to set up from the outside. Thus as the planning was deploying full IPv6 by 17 of February I announced this into the appropriate medium so people could set up their firewalls to filter ipv6 traffic too if they hadn't already done so.

Of course things didn't go as planned and this basically sparked a big discussion over how networks should have opt out security and a fight for the providing a secure by default implementation. The discussion delayed us as we tried to reach a compromise solution and after some more discussion we agreed on the following implementation:

  1. We'll have 2 subnetworks, one providing unrestricted traffic from the Internet and other providing controlled traffic.
  2. Assignment to these networks would be made depending on the switch being used (labeling them as open and filtered) or depending on the VLAN stated by the RADIUS server.
  3. The initial deployment will be filtered by default.

Sadly our access switches aren't managed so we can't use 802.1x to provide VLAN assignment at port level nor do so based on the device MAC address. But as you can expect, I'm going to separate the secure VLAN used for WLAN devices from the one used for cabled devices as we do with the other networks so they can't directly see each other, if you want security you get it with all its consequences so if you want to be able to see wireless devices directly or you need to have an internal name assigned to your device you go to the unsecure network which was planned with hacking in mind and not with the idea that users would be kids needing to be protected from themselves.

Well that's mostly it for the ranting, so back to technical stuff on the 20 we did the deployment.

Deployment and third problem: IPv6 forwarding

As said we did the deployment later. Today we finally managed to get an static IPv4 address from bredbandsbolaget so after reconfiguring the router to use the new settings and since we already had had downtime (basically they just stop providing DHCP updates and you have to set it up all on the fly, instead of giving you a day or two for transition allowing to use both addresses) I closed any remaining details on how the deployment was going to be carried and the previous discussion and started with it.

Basically on the router we have dnsmasq running on the router providing appropriate IPv4 addresses depending on the device being used and providing also DNS caching services, so it was only logic to also use it for RA and DHCPv6 services too. The setup was quite easy and just required to add a single line to add support on the hackerspace VLAN:

dhcp-range=tag:lan.40, 2001:470:dc07:40::1:0, 2001:470:dc07:40::1:ffff, slaac, ra-names, 64, 15d

Finally I had to update the ip6tables FORWARD table to add connection filtering (I allowed ping though as it can be useful for testing). The relevant parts of the tables as it's now looks like this:

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target           prot opt in     out     source               destination         
    0     0 Internet_fwd_in  all      he6    *       ::/0                 ::/0                
    0     0 Internet_fwd_in  all      in1    *       ::/0                 ::/0                

Chain Internet_fwd_in (2 references)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 ACCEPT     all      *      *       ::/0                 ::/0                 state RELATED,ESTABLISHED
    0     0 ACCEPT     icmpv6    *      *       ::/0                 ::/0                 ipv6-icmptype 128
    0     0 DROP       all      *      *       ::/0                 ::/0                

You probably can notice that two interfaces (he6 and in1) are affected. he6 is the tunnel interface and needs to be firewalled as the Internet ipv6 traffic is expected to come from there. The reason why in1 (Bredbandsbolaget connection) is filtered too is that they may decide to provide IPv6 connectivity at some point of time and I don't like the idea of people being able to access our systems in that way.

But of course deployments usually come with problems, in this case I thought I had set up IPv6 routing on the machine but I hadn't done so. After looking around in the sysctl (as the option wasn't documented on the sysctl.conf file) I found the required option and enabled it. The IPv6 related sysctl now looks as follows:

#Config for ipv6 routing
# Enables packet forwarding
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.default.forwarding = 1

#Disable ipv6 autoconfiguration
net.ipv6.conf.all.autoconf = 0
net.ipv6.conf.default.autoconf = 0

#Except on in1 (Internet interface)
net.ipv6.conf.in1.autoconf = 1

#Disable source routes before they byte us (pun intended)
net.ipv6.conf.all.accept_source_route = 0
net.ipv6.conf.default.accept_source_route = 0

#Disable redirects to avoid MITM (at least for now)
net.ipv6.conf.all.accept_redirects = 0
net.ipv6.conf.default.accept_redirects = 0

And with that IPv6 came to life and started working, I'll report on any issues we find on the way and update this page.

You could leave a comment if you were logged in.
members/klondike/ipv6_deployment.txt · Last modified: 2014/02/21 02:34 by klondike