Posts in category 'ipv6'

Many of the non-critical services I run–messaging, RSS, home automation–run on an Intel NUC I’ve hidden away at home. This has advantages over a VPS in that if I need additional resources, I can just add some memory or storage rather than having to move to a new service tier and paying that much more every month. Plus, given how much I’m working and using these services at home, having them hosted locally means higher perceived performance due to lower latency.

Unfortunately, connectivity for services hosted on a residential broadband connection is always a pain in the butt. While over the years my residential broadband connection has been incredibly stable, I still face the challenge of changing IP addresses. And yes, I can set up dynamic DNS, but I’ve always found it relatively fragile (not to mention an enormous hack). Additionally, you have to contend with ISPs potentially blocking ports and so forth. And finally there’s all the issues with NAT, reverse port mappings, internal and external DNS record management, and on and on. Basically it’s painful and brittle.

On what might seem like an unrelated note, IPv6 is still gradually getting deployed. Certainly mobile networks use v6 extensively, but outside that space adoption is still pretty nascent. As a result, it’s always been a bit questionable if deploying v6 at home is worth the trouble (minus the novelty and bragging rights).

But it turns out that, with a VPS and an IPv6 tunnel, you can dramatically simplify the process of hosting services on a residential broadband connection. As a result, this has proven to be the “killer app” that has driven me to truly adopt v6 at home.

Continue reading...

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:

1. Use iptables or something similar to throttle inbound ssh connection attempts.
2. Coupled with the previous, implement tarpitting (this slows down ssh responses, which means the attacker wastes resources on your server).
3. Implement something like fail2ban to automatically detect attacks and dynamically add them to a set of block rules (managed with something like iptables).
4. 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!

Update:

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).