To start off this post, first of all, Ubiquiti is awesome. For those not familiar with who Ubiquiti is, they are an Enterprise-oriented network equipment provider, which develops Wireless equipment for Wi-Fi and point-to-point access, routing equipment built around the Vyatta OS, and switching equipment. Ubiquiti is well known for being a software-defined network (SDN) vendor. Ubiquiti is also less known for their UniFi Video platform, which is a DIY and easy to roll IP Camera system. The best part about all of the Ubiquiti products is that they are quite inexpensive, for the features and performance which is otherwise provided, and licensing per device is not an issue.
Across Buffalo, I have been working with a buddy of mine to replace shoddy Wi-Fi networks (you know, the ones which don’t work, slow down a lot, and need resetting all the time) in various apartment buildings. One of our goals with the network replacement is to ensure the network, when it is implemented, is ready to go for the future, and ready to go for the explosion in not only the Internet of Things field, but the explosion in digital entertainment which continues to show no decline. Something which won’t require replacing for some time, and something which won’t end up needing the reboot and pray trick to work. The Ubiquiti gear so far, has served that well.
There has been one major drawback. Part of building a future proofed network, is building a network which brings the future into today. That means IPv6 support. The Ubiquiti gear has full support for IPv6, and it isn’t too difficult to configure if you’re using something like an EdgeRouter from Ubiquiti. On the UniFi front, which is the controller-managed solution I use for these network builds, the options for IPv6 are unfortunately lacking (non-existent as of this post). It’s a bit of a surprise for Enterprise level gear, but then again, it was inexpensive. That doesn’t mean a thing to me.
After some web searching, I learned that the UniFi Security Gateway 3P, and the Security Gateway Pro 4, both run Ubiquiti’s EdgeOS, which is a fork of the Vyatta routing distribution. The version of EdgeOS on UniFi is identical to that of an EdgeRouter, with changes made to direct administration to the UniFi Controller (hosted on Amazon, a remote web server, or a local server such as Ubiquiti’s CloudKey). The UniFi Gear doesn’t have the Web UI of the EdgeOS equipment, and with that said, the only option I have, is to dig into the command line.
With some further web searching, I stumbled across this helpful blog post which details the commands needed to configure an EdgeOS device with IPv6, and firewall rules to help ensure that IPv6 doesn’t help devices on a network go rogue, being directly addressable on the Internet. Before entering the commands, I have to first verify which Interfaces on the USG are belonging to the WAN (Internet) connection, and the LAN connection. With an SSH session made to the UniFi Security Gateway, I simply run the command: show interfaces to get a list of them.
Linux ubnt 3.10.20-UBNT #1 SMP Fri Jun 23 08:47:03 MDT 2017 mips64
Welcome to EdgeOS
Last login: Thu Aug 3 00:15:23 2017 from 192.168.0.3
admin@USG:~$ show interfaces
Codes: S – State, L – Link, u – Up, D – Down, A – Admin Down
Interface IP Address S/L Description
——— ———- — ———–
eth0 192.168.0.1/23 u/u
eth1 – A/D
eth2 98.xxx.xxx.xxx/20 u/u
eth3 – A/D
lo 127.0.0.1/8 u/u
::1/128
admin@USG:~$
Per my output, on a UniFi Security Gateway Pro 4, my Internet connection lives on eth2, which is the WAN1 port physically on the device. LAN1 is the eth0 interface. As such, eth2 refers to LAN2, and eth3 is the WAN2 port. The rest are software loopback interfaces. On a USG 3P, the interface list will look different. Here’s an example from a network I’ve already set up with IPv6.
Linux ubnt 3.10.20-UBNT #1 SMP Fri Jun 23 08:31:09 MDT 2017 mips64
Welcome to EdgeOS
admin@USG:~$ show interfaces
Codes: S – State, L – Link, u – Up, D – Down, A – Admin Down
Interface IP Address S/L Description
——— ———- — ———–
eth0 67.xxx.xxx.xxx/22 u/u
2604:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/128
eth1 192.168.1.1/24 u/u
2604:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx:xxxx/64
eth2 – A/D
lo 127.0.0.1/8 u/u
::1/128
admin@USG:~$
On the USG 3P, you can see that my Internet connection lives on eth0, which is the “WAN1” port physically on the USG. My LAN1 port is eth1, and the unused VoIP port is on eth2. Then of course, you have your software loopback interfaces.
Returning to the mentioned blog post, the next step is to run the commands provided on the USG, changing the Interfaces for eth0 and eth1 as provided in the blog post, to match the configuration as it is for my own network and equipment. After the commands are executed, it’s time to commit my changes to the USG, and confirm that the USG has pulled an IPv6 address from the ISP. This is as simple as re-running the show interfaces command. Like in my second example, the USG should now show a single IPv6 address (a /128) assigned to the USG by the ISP. This is the router’s IP on the Internet. I should also see a /64 subnet assigned to my LAN port. The USG will issue out IP addresses to devices from the /64 subnet which has been issued. As a side note, for those who have changed the config to request a /56 subnet, in order to subnet it down into two /64s, or a /64 to subnet down into /96 subnets, you already know what you’re doing I’d say :-).
With IPv6 addresses confirmed, testing IPv6 is as simple as running commands such as ping6 www.yahoo.com or traceroute6 www.yahoo.com from the USG and any other device on the network. If you can get out to the Internet, you’re good to go. To verify all is working 100%, you can also use the sites https://ipv6-test.com/ and https://test-ipv6.com/ to confirm it is working properly.
Now, we need to move onto making sure the changes made to the USG persist. Should a setting become changed on the USG, or should the USG need to be reset someday, the UniFi Controller will re-provision the device with a copy of it’s config. This will remove all of the new IPv6 settings added. With UniFi, the controller is what is responsible for applying the configuration files, and a controller is capable of provisioning more than one “site” with configuration settings. Our end goal, is to make IPv6 access persistent.
Ubiquiti has been kind enough to provide sample configuration files for both the USG and the USG Pro in their knowledge base. Great! I can just download those files, then place them onto my controller, which in this case is a CloudKey. I just need to make sure the file as stored on the CloudKey is located in the root folder for the site I want to provision IPv6 to, and the file is called config.gateway.json. In my case, the file would be stored at /svr/unifi/data/sites/default/ within the CloudKey’s file system. After the file is in place, change any setting (like DNS Server settings) for your USG, or just click the Provision button on newer controller versions, and the network should be good to go.
There’s a few lessons to be learned, once the IPv6 configs are in place. First, some people may wish to use DHCPv6 for logging IP addresses to devices, instead of just allowing them to randomly pull any address at will from the /64 subnet announced by the USG. This is actually a smarter way to implement IPv6, and in the example provided above, there is no DHCPv6 support. Now, the reason why I do not implement DHCPv6 for address assignment, is because Android devices do not support DHCPv6 strangely enough. An Android device in a DHCPv6 environment will be left with broken, or otherwise very hesitant connectivity. Hopefully someday the Android community will fix that problem, so users such as I can avoid using SLAAC (Stateless Automatic Address Configuration) and use DHCPv6 instead. It is also worth pointing out, that older Android phones will not have working IPv6 connectivity unless IPv4 is up and working. They don’t try to use IPv6 if IPv4 is unavailable. This causes problems with IPv6-only networks, commonly used for research purposes at this time.
Now the second problem with the configuration provided above, is that the DNS servers are not necessarily provided to the client (notably a thing with Windows). To have true, and native IPv6 access, you’ll want to make sure you also give your devices IPv6 DNS access. On larger networks, I typically defer DNS to another host or to public resolvers, to avoid placing excessive levels of load onto the USG (which acts as a resolver/relay by default). Let’s go over some of the changes to the JSON file I’ve had to implement.
“eth0”: {
“ipv6”: {
“dup-addr-detect-transmits”: “1”,
“router-advert”: {
“cur-hop-limit”: “64”,
“link-mtu”: “0”,
“managed-flag”: “true”,
“max-interval”: “600”,
“other-config-flag”: “false”,
“prefix”: {
“::/64”: {
“autonomous-flag”: “true”,
“on-link-flag”: “true”,
“valid-lifetime”: “2592000”
}
},
“reachable-time”: “0”,
“retrans-timer”: “0”,
“send-advert”: “true”
Now, this section of the JSON file is nearly identical to the Ubiquiti provided JSON file. There are a few changes which are noteworthy to accomplish what I want to do. The first thing we must change, is the “other-config-flag” variable. other-config-flag is designed to tell clients who are IPv6 capable, to use DHCPv6 to ask for special options from the network. These special options are required to give an IPv6 client a DNS resolver. To enable, simply change the value from “false” to “true.” The next step is to add in a nameserver. Here, I add a line below “other-config-flag” with the value: ‘ “name-server”: “2620:0:ccc::2”, ‘. This configures the DHCPv6 server found in the USG to issue out an OpenDNS Server IP Address (that’s what 2620:0:ccc::2 is) to any client which responds to the other-config-flag and runs DHCPv6.
If you’ve made it this far, I’ve got Sample config files I use to provision IPv6 with the changes I’ve made, and to see for yourself where the changes should exist. Just click on the link for each based on whether you’re trying to configure a USG, or a USG Pro. And of course, if you wish to just run my edits to the configuration, you can just wget/curl/whatever them off of the site, and place them into your site directory. Just remember to rename them to config.gateway.json from their original name.
On a final note, should IPv6 not work even after applying the JSON files to your controller, it’s always smart to verify that your USG has actually received the updated configuration. To do this, simply SSH into your USG, and run the command: mca-ctrl -t dump-cfg . After this command executes, simply scroll through the Terminal (or pipe the command through the more command) and ensure that the changes from your JSON file show up in the runtime config. At which point, if IPv6 is not working, it’s wise to check with your ISP for support, or to experiment a bit more. To look up commands and support, USGs come included with DNSMasq and radvd for DHCP and IPv6 support, and the support is very similar to open router firmware such as OpenWRT. The Operating system is very close to the Vyatta OS.
I hope this was found to be informative. Have fun!
