Many years ago I experimented with running IPv6 in my home network (dual-stacked, not IPv6-only… I’m not that crazy!). At the time this was mainly an intellectual exercise. While a lot of major services already offered IPv6 (including Google, Facebook, and Netflix), the big draw of v6 is the ability to completely do away with NAT and simplify access to services and P2P applications running out of my home. But without broad v6 support, even if my home network was available via v6, the rest of the world wouldn’t be able to access it, which pretty severely curtailed the utility of the whole thing.
But, it was still an interesting exercise!
Until, that is, Netflix started cracking down on VPNs.
The way v6 was deployed in my network was via a tunnel supplied by Hurricane Electric. That tunnel terminated in California, and, while not intentional, it allowed me to watch US Netflix in Canada.
That is until Netflix realized people were abusing those tunnels and started blocking inbound traffic via HE.
I considered potential workarounds, but I could never figure out a satisfying solution (in large part thanks to closed devices like Chromecasts).
And so I shut down v6 in my network. While, previously, v6 didn’t provide a lot of value, it also didn’t cause me any problems. Once this issue surfaced, it was no longer worth the effort.
Recently I decided to take another look at the situation to see if anything had changed.
Well, unfortunately Netflix still blocks traffic coming from Hurricane Electric traffic originating in the US.
However, it turns out, back in 2013, HE added new Points of Presence (POPs) in both Calgary and Manitoba. That meant I could set up a tunnel with an exit point inside the country.
Would Netflix block that?
It turns out, the answer is: No!
So I now have IPv6 back up in my home network.
But has the connectivity story changed? Yes!
Much to my astonishment, I discovered that in the last couple of years, AT&T, Rogers, and Telus have all deployed native IPv6 inside their networks. That means that, when I’m out and about in both Canada and the US, I have direct v6 connectivity back to my home network! Even my mother-in-law’s house has access thanks to her Telus internet package.
That’s a huge expansion in coverage!
In fact, ironically enough, of the places I frequent, the only location that lacks v6 connectivity is my workplace. Go figure. But, in that case, I can always just tunnel through my linode VPS, which has had v6 connectivity for many many years.
IPv6 adoption may be taking a while, but it is happening!
So, one of the ongoing issues that anyone with a public-facing server has to deal with is a barrage of SSH login attempts. Now, normally this isn’t a problem, as a decent sysadmin will use fairly strong passwords (or disable password-based logins entirely), disable root logins, and so forth. But it’s certainly an irritant, and so it’s worth implementing something to mitigate the issue.
Now, traditionally, there are a few general approaches people take:
- Use iptables or something similar to throttle inbound ssh connection attempts.
- Coupled with the previous, implement tarpitting (this slows down ssh responses, which means the attacker wastes resources on your server).
- Implement something like fail2ban to automatically detect attacks and dynamically add them to a set of block rules (managed with something like iptables).
- Move SSH to a non-standard port.
All of these work reasonably well, and particularly for the lazy, something like fail2ban on Ubuntu is dead easy to deploy and works quite nicely. Of course, there’s always the chance that you lock yourself out if you fail at a few login attempts, so it’s not without it’s risks.
But I recently discovered a fifth option which, at least at this stage of IPv6 growth, works incredibly well: disable inbound SSH over IPv4. See, most attackers aren’t v6 connected. Meanwhile, acquiring v6 connectivity remotely is usually just a matter of running a Teredo tunneling client. The result is perfectly workable remote accessibility, while the number of SSH attacks is cut down to essentially zero.
Of course, this won’t last forever. In the future, v6 is likely to get deployed more widely, and I suspect I’ll start seeing v6-based ssh attacks. But until then, this solution is dead simple to deploy and works great!
And naturally, just a day after I finish writing this, I decided to fiddle around with NX for remotely accessing this server, and lo and behold, NX doesn’t support IPv6. :) So, I’m back to using fail2ban, until NX can get their act together (though, to be fair, latency over my v6 tunnel has an unfortunate negative impact on NX performance, and so I’m not sure I’d use v6 even if I could).
Welcome to the new domain! As per my previous post, I’ve made the migration to my new domain, “b-ark.ca”. Additionally, this website is now IPv6 accessible, so anyone with IPv6 access (either through a tunnel broker, 6to4, or teredo) will be able to reach this place over v6 instead of v4.
As an aside, Hurricane Electric and Afraid.org are awesome services. Tunnel performance is spectacular (I see maybe 20ms extra latency over IPv6 versus IPv4), and they provide a routed /64, a full routed /48 if you want it, and support for reverse DNS delegation (so my IPv6 addresses will reverse resolve to my host names).
Meanwhile, Afraid.org has excellent support for IPv4 and dynamic DNS, and IPv6, both forward and reverse. Now maybe I’ll go apply for an “IPv6 Enabled” badge to stick on the website…
So during the last week I decided it was about time I rebuilt my firewall, if for no other reason than to upgrade to the latest version of m0n0wall, as the version I was running dated back to 2006. Of course, naturally enough, during the course of my initial experimentation, my old firewall hardware kicked the bucket (it was an old 150Mhz P-II… I’m surprised it hadn’t died sooner), so I suddenly found myself in need of a new firewall PC. “Lucky for my, I ditched my old MythTV motherboard”, I thought to myself… what a fool I was.
As a bit of background, I’ve been running an open wireless access point for years and years now, and to achieve reasonable security, the network topology was something like the following:
Where both the WiFirewall and Firewall perform network address translation. Unfortunately, this means:
- The wireless network is double-NATed, which makes forwarding ports back from the firewall to the wireless network a heck of a lot more cumbersome.
- I have to maintain two separate sets of firewall rules.
Plus, the WAP I have doesn’t support IPv6, so if I wanted to deploy IPv6 internally, I couldn’t do so for the wireless pool.
Well, this screamed for a solution, hence me building a new firewall. My vision was the following:
In this sort of arrangement, the firewall acts as a single NAT for both subnets, and also allows me to control access from the wireless pool to the LAN and vice versa all in one place. Plus, because both subnets are directly connected to the firewall, which supports IPv6, I can deploy v6 across my network.
Of course, this scenario requires three NICs in the firewall, one for the WAN, one for the wireless subnet, and one for the LAN subnet. So I took my spare machine, threw three NICs in it, fired up the newest version of m0n0wall, and got… “watchdog timeout: dc0”, followed by hard locks.
Many hours later, after running up and down the stairs a couple dozen times, my conclusion was IRQ conflicts between one of the NICs and the USB controller on the board. Yes, that’s right, in 2010, I was fighting with IRQ conflicts. Seriously, what the heck?
The next day, I relented and decided to try out another motherboard I had lying around (yes, that’s right, I had two spare motherboards just lying around. Go figure.) Luckily, this one seems to work beautifully, and I now have a brand new firewall set up as described above. I even configured m0n0wall’s traffic shaping such that bittorrent traffic is de-prioritized versus other traffic, so I no longer need to perform upstream throttling in rtorrent, as the firewall takes care of everything (and it works beautifully… rtorrent can now saturate my upstream, while web browsing, etc, continue to work flawlessly).
Furthermore, I figured, hey, why not deploy IPv6 for kicks? So I went and allocated a tunnel from Hurricane Electric. They provide free IPv6 tunnels plus a free routable /48 if you want it (yes, that’s right, an 80-bit address space for nothing). You just need a router/firewall that supports it. Well, as you might imagine, m0n0wall does. Additionally, Hurricane Electric has a deal with Google such that, if you use HE’s nameservers, then all of Google’s services will be accessible over IPv6. So now anyone connected to my WAP will be able to browse the IPv6 internet, and access Google’s services over v6. Neat!
And, as if that weren’t enough, I registered a new domain name: “b-ark.ca”. I then plan to use afraid.org, which is a free DNS hosting service which provides support for IPv4, both static and dynamic, and IPv6, both forward and reverse. Of course, I’ll need to find a way to cleanly migrate away from “frodo.dyn.gno.org”, but once I do, that address will be disappearing, and this place will be reachable at “blog.b-ark.ca”.
1 of 1