IPv6!
My ISP (AussieBroadband) has been testing IPv6 in beta for some time now, and I’ve not gotten around to looking at it. Several of my VMs have had IPv6 support for years, and I’ve recorded some of the trouble I’ve had with that but for the most part it’s been smooth sailing. Time to join the 21st century right? So I opted in to the beta, configured it on my VDSL modem (which was at the time doing the DHCP for diagnostic purposes), and within a few minutes I had IPv6 as far as the router. Awesome! Except for the problems:
Problem 1 - Prefix delegation to the LANs
I get a /56 delegated to me, and I couldn’t work out how to delegate portions of it to my two LANs, so that’s as far as it went all week. It was actually worse than when I started, because the LAN machines all had their own link-local IPv6 addresses still, but they somehow knew the router had IPv6, but any connection attempt to the outside world returned an error message relating to the scope of the source address (which is fair enough, link-local addresses are not globally routable). This manifested as all sorts of weirdness, like things going slow at first on our mobiles… every new connection taking about a second to set up… and things like sudo on the Linux machines complaining about DNS resolution. Argh!
The weekend arrived, and I was able to break things on Saturday night, so I did. It turned out there were a few issues with it, the primary one being that my modem’s support for IPv6 is super-weak, and basically it seems like if you have a separate modem+router, the modem really needs to be in bridged mode for prefix delegation to work correctly. I also ditched the DM200 in favor of the Vigor 130, which seems to have a real bridged mode, whereas the DM200 seems like it really only does forwarding with zero translation, so lots of things still don’t work.
Once that works, on the UniFi controller, head to the WAN configuration, turn on DHCPv6, and set the prefix size (56). If all goes well, IPv6 addresses should appear on the interfaces of the USG, and you should have ping6 connectivity to Google, etc from the USG.
Next I head over to the LAN network configuration pages (I have two LANs, so two different pages), turn on Prefix Delegation for IPv6, and set the Prefix ID for each of them - say 1 for one and 2 for the other. I left the rest of the settings default, and after solving all of the above issues I had IPv6 connectivity from all of the machines on the LAN. Huzzah!
Problem 2 - Bridge mode breaks my monitoring of the router stats
Naturally, bridged mode means that the router no longer has an RFC1918 address on the WAN port, so there’s no access to the modem’s status pages, SNMP service, etc. With pfSense, I solved this by strapping an alias to the dhcp configuration. On Alpine, it was just a case of defining an alias block in the dhclient configuration also. The USG uses dhclient, but vyatta clobbers the configuration for you every time, and there’s no ability in the code to add an alias or anything.
I started messing around with using task-scheduler to append a section to the configuration and restart dhclient, but it looked super dodgy and a couple of times I provision-looped my USG. After a while a fairly obvious solution hit: Linux specifies IP aliases as a separate pseudo-interface, so why not just bring one up that I want? ifconfig eth0:0 192.168.0.2 netmask 255.255.255.0 up works, and it’s idempotent. So it seems the obvious solution is just to add a cron task that brings that interface up every 2 or 5 minutes or so, and you’ll have connectivity to the router most of the time (when dhclient loses a connection, it’ll tear down all the IPs on the WAN interface, so you’ll lose it until the cron puts it back). The JSON configuration for one’s gateway-config seems pretty simple:
"system": {
"task-scheduler": {
"task": {
"resetmanagementip": {
"executable": {
"path": "/sbin/ifconfig",
"arguments": "eth0:0 192.168.0.2 netmask 255.255.255.0 up"
},
"interval": "5m"
}
}
}
}
Problem 3 - I lost my monitoring scripts for the Vigor 130.
I managed to misplace the script I used for generating stats for the Vigor 130, so I had to rewrite another one well after midnight (so naturally it’s not great). As I didn’t seem to properly document the OIDs I used, here they are:
Downstream Sync: iso.3.6.1.2.1.10.94.1.1.4.1.2
Upstream Sync: iso.3.6.1.2.1.10.94.1.1.5.1.2
Downstream Noise Margin: 1.3.6.1.2.1.10.94.1.1.3.1.4
Finally, it took me far longer than it should have to realize that snmpwalk defaults to SNMPv3, which the Vigor does not speak. You must specify -v1 or -v2 to get a response.
Problem 4 - I broke IPv4 port forwarding
I’m not sure if this is related to the solution to problem #2, or the IPv6 itself, but my port forwards are broken. tcpdump shows the packets coming in, but it doesn’t seem like any translation happens:
07:49:23.790797 IP my.vps.in.sydney.55747 > my.aussiebb.ip.https: Flags [S], seq 3821239806, win 65535,
options [mss 1460,nop,wscale 6,sackOK,TS val 1387760422 ecr 0], length 0
At the time of writing I still haven’t fixed this, but there’s really only one port forward that absolutely must work, and it travels via Cloudflare. So there’s a simple solution - remove IPv4 from that host on CF, set it to V6 only, and poke a hole through the firewall to allow connections to that port on IPv6. That worked, and Cloudflare does the IPv4 translation for me.
I’ll have to work out the IPv4 port forwards later (online gaming may be less than stellar with it), but for now I really need some sleep so I’m giving up.
fwagglePublished:
Modified:
Filed under:
Location:
Horsham, VIC, AustraliaNavigation: Older Entry Newer Entry