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