Adventures in IPv6 – The Next Generation – Part 2

Part 2 – Configuring The IPSec Tunnel

First thing you’ll need to do is decide whether you’re going to use certificate based or PSK authentication between the ends of the IPSec tunnel, if you decide on certificate based auth, you’ll of course need some certificates, your choice where you get them from, I created an internal CA on my local pfSense box and used that to issue the certificates for my tunnel.

Next step is to configure IPSec Phase 1 (the configurations of each end of the IPSec tunnel are basically mirrors of each other, so I’ll only show one side here);

One end of the IPSec Phase 1 config, the other end mirrors this

Now onto Phase 2 (again, this is the “outside” host, the “inside” host mirrors this);

“Outside” end IPSec Phase 2 config, the other end mirrors this.

Once that’s done, verify that the tunnel comes up.

IPSec Status showing the tunnel is up and online

At this point you’re largely done and dusted, you need to assign an appropriate IP address (one from your \48) to the LAN interface on your local pfSense box, configure DHCPv6 however you choose, personally I assign the chunk of addresses from ::00FF to ::EFFF to my wired LAN then delegate \62 prefixes out to every other router in my network to dispense as needed, it’s unlikely I’m ever going to have more than 4 subnets behind any of them, should that change in future I can always change the delegation size.


The config as described here does work, but there’s an issue which seems intractable, inbound connections on IPv6 are fine, connections between “inside” hosts and the “outside” host are fine, connections from my “outside” host and the rest of the world are fine, but connections from “inside” to the rest of the world are excessively slow (~70kB/sec), it seems to be an MSS/MTU issue, I suspect that the IPSec overhead is just too much to do efficient IPv6 encapsulation on my connection.

So for the purposes of exposing internal hosts this is fine (because my end manages MSS at that point), but for actually connecting out to the IPv6 internet it’s not great.

My next step will be to try again with another tunneling protocol that’s lighter weight than IPSec, more on that when I get around to it 😉

Morgan / 2017-08-01 / Uncategorized / 0 Comments

Adventures in IPv6 – The Next Generation – Part 1

Part 1 – Background and Approach

I posted a few days ago about my Adventures in IPv6 which was a brief summary of getting IPv6 connectivity via the Hurricane Electric free IPv6 Tunnel Broker service, in that post I remarked about some issues I had due to the fact that my tunnel was terminated in Japan, this series of posts will cover “The Next Generation” where I basically set up a “personal” IPv6 Tunnel service.

A quick note ahead of time; in my setup, I’m using pfSense on both ends of the tunnel, this is mainly because I’m lazy. Most of the parameters in pfSense map directly to config files though so it should be relatively straight forward to translate the steps here into raw config files if that is more to your taste.

This project morphed several times as it encountered a few stumbling blocks on its way to completion:

  • Plan A – find an Australian IPv6 tunnel broker;
    NOPE, there do not appear to be any active IPv6 tunnel brokers with Australian PoPs any more.

    • SixXS stopped accepting signups and requests for tunnels January 2016 declaring “Call your ISP for IPv6” month, which given that we’re basically awash with IPv4 addresses here in AU, was never really going anywhere for us.
    • The AARNet tunnel broker service appears to have been discontinued, but the web portal has not been decommissioned
    • IPv6Now apparently used to run a tunnel broker service, there is nothing on their website any more and they did not respond to my email
  • Plan B – find some “reasonably priced” colo in Australia with IPv6 transit to drop a router into;
    NOPE, “reasonably priced” colo is a unicorn in Australia (I recall this being the case some many years ago, things have not really changed), the cheapest option I found was $85/month, which would nearly double the monthly price of my connection.
  • Plan C – find a VPS provider with IPv6 connectivity and roll my own tunnel broker.

Plan C it is

Initially I found HostUS (affiliate link), who offered reasonably priced VPSes in their Australian PoP; I signed up with them, started to play with things then discovered that OpenVZ wasn’t going to work for me. After some discussions with support basically concluded that they weren’t going to be able to satisfy my requirements, which is unfortunate, because I was REALLY impressed with their support department. I cancelled my service and received full refund (quick and painless, a credit to their approach).

Did some rummaging around for KVM VPSes hosted in Australia with IPv6 connectivity, apparently I wasn’t looking under the right rocks because I didn’t manage to find anything myself. Time to ask the brainstrust, asked on a couple of lists to see if anybody knew of any suitable providers, got referred to Vultr (affiliate link).

Vultr, I’ve got to say, is pretty much the slickest interface I’ve ever seen for VPS/Cloudy stuff management (not that I have a huge amount of experience but every other provider I’ve worked with seems to run WHMCS with varying levels of customisation), and their billing system is nicely flexible. Unfortunately the largest allocation Vultr will provide is a /64, but they are happy to provide BGP sessions so you can announce your own IP space. As such, for my purposes I needed to purchase some IPv6 addresses from a third-party.

(Re)enter HostUS;
HostUS will provide an APNIC issued /48 for $30USD/year, which seems pretty reasonable to me, so I purchased a block from them, requested an LOA (Letter Of Authorisation) from support, per my previous interactions with their support department the request was handled quickly and with a minimum of friction.

Next I raised a support ticket with Vultr to get BGP enabled on my account, basically had to provide a Use-Case, nominate a BGP password and attach the LOA to them, they’d come back within the day to say it was ready.

Time to start configuring our Tunnel, there are various options you could use for this, GRE, GIF, IPSec, probably OpenVPN and I’m sure there are others, I chose IPSec because it allows an IPv4 phase one with IPv6 and/or IPv4 encapsulation within phase two (if the slash and burn my ISP is presently engaged in on their international network (or rather the formerly pretty nice international network of one of their recent acquisitions) continues, there may come a time when tunneling my IPv4 traffic out through my Vultr instance and via their international transit may become preferable) the data is encrypted in transit (the other options are cleartext encapsulations) and the overheads are OK.

OK, this is probably an opportune point at which to break the post, the story will continue in Part 2.

Morgan / 2017-05-11 / Uncategorized / 0 Comments

Adventures in IPv6

So I was having a discussion on one of the boards I lurk on some weeks ago around IPv6, and that spurred me to finally pull my finger out and actually DO something about it (up until this point I’d been basically taking the “Ostrich” path of sticking my head in the sand and pretending it didn’t exist).

My current provider has not deployed dual-stack to the edge, and all indications are that there will be significant costs involved in doing so (and they’ve recently been purchased by the biggest cheapskate in the ISP game, so I’m not going to see native IPv6 any time soon), and I’m rather attached to my extremely lightly contested HFC connection, so switching to another provider for native IPv6 is not an option, time to do some fishing.

A bit of looking around reveals the existence of “Tunnel Brokers” who provide 6in4 tunneled connectivity, awesome, let’s go find one of them…

The largest tunnel broker in the world (and also arguably the “centre of the IPv6 internet” because they were basically the first major IPv6 deployment on the internet) is Hurricane Electric and their service which offers up to 5 free 6in4 tunnels (and optionally a routed /48 for each), signed up there, created a tunnel, followed this (now rather antiquated, but still usable) document to get the tunnel up and running on my border router.

Configured DHCPv6 to start serving the routed /64 provided by HE, et voila, IPv6 on my LAN. Surprisingly straight forward. The hardest part was needing to remove the “REALLY REALLY disable IPv6” regkey from my Windows box (because that meant I needed to reboot it 😉 ).

So at this point I’ve got IPv6 connectivity working on the LAN, time to go deeper (I’ve got several subnetworks for different purposes), and dig into the world of Prefix Delegation.

Log into HE, click button that says “assign /48”, /48 allocated, woo!

Update DHCPv6 config on pfSense, set “Prefix Delegation Range”, set “Prefix Delegation Size” to something sensible (I used 62, so I can have 4 networks behind each of my routers, realistically I could’ve used 56 and still not been remotely in danger of running out of prefix…).

Enable IPv6 WAN interface on (one of several) Wireless router, router pulls prefix and starts assigning to clients. Well shit that was easy…

Throw in an inbound rule to allow ICMP from one of my VPSes with IPv6 connectivity into one of the addresses on my wireless network, ping address, lo and behold, it “just works(tm)”…

All in all I was surprised at just how painless it was to get up and running, the nicest thing about this is I don’t have to bend over backwards to renew the LE certs I use on my internal services anymore 🙂

Unfortunately it’s not all roses though;

IPv6 in and of itself is pretty straight forward and more or less “just works(tm)”, the major ugliness comes in when you start looking into stuff like NAT64 and DNS64 which are dirty hacks intended to get us through the transition between “getting everything on IPv6” and “getting everything off IPv4”.

All in all, this setup works pretty well but there is one major issue with it. HE do not have any PoP’s in Australia, the closest PoP (routing-wise) I could find was Tokyo, which is not a major issue (though it adds 300ms of latency) in and of itself, but it is problematic in some situations because I have an IPv4 address which geolocates to Australia, where my IPv6 address geolocates to Japan. CloudFlare in particular does not like this, I’ve had a large increase in the incidence of “prove your human” type prompts out of it when I access CloudFlare protected sites. I’ve also had one attempt at purchasing something online being flagged as fraudulent because my IP address geolocates to a country that doesn’t match my CC billing address.

I’m presently working on resolving that issue, and once I get that working I’ll write a post on that.

Morgan / 2017-01-24 / Uncategorized / 0 Comments