Nov 062016

Sometimes, it is desirable to have a TLS-based VPN tunnel for those times when you’re stuck behind an oppressive firewall and need to have secure communications to the outside world.  Maybe you’re visiting China, maybe you’re making an IoT device and don’t want to open your customers’ networks to world+dog by making your device easy to compromise (or have it pick on Brian Krebs).

OpenVPN is able to share a port with a non OpenVPN server.  When a tunnel is established, it looks almost identical to HTTPS traffic because both use TLS.  The only dead giveaway would be the OpenVPN session lasts longer, but then again, in this day of websockets and long polling, who knows how valid that assumption will be?

The lines needed to pull this magic off?  Here, we have sniproxy listening on port 65443. You can use nginx, Apache, or any other HTTPS web server here.  It need only be listening on the IPv4 loopback interface ( since all connections will be from OpenVPN.

port 443
port-share localhost 65443

There’s one downside.  OpenVPN will not listen on both IPv4 and IPv6.  In fact, it takes a ritual sacrifice to get it to listen to an IPv6 socket at all.  On UDP, it’s somewhat understandable, and yes, they’re working on it.  On TCP, it’s inexcusable, the problems that plague dual-stack sockets on UDP mostly aren’t a problem on TCP.

It’s also impossible to selectively monitor ports.  There’s a workaround however.  Two, in fact.  Both involve deploying a “proxy” to re-direct the traffic.  So to start with, change that “port 443” to another port number, say 65444, and whilst you’re there, you might as well bind OpenVPN to loopback:

port 65444
port-share localhost 65443

Port 443 is now unbound and you can now set up your proxy.

Workaround 1: redirect using xinetd

The venerable xinetd superserver has a rather handy port redirection feature.  This has the bonus that the endpoint need not be on the same machine, or be dual-stack.

service https_port_forward
flags = IPv6               # Use AF_INET6 as the protocol family
disable = no               # Enable this service
type = UNLISTED            # Not listed in standard system file
socket_type = stream       # Use "stream" socket (aka TCP)
protocol = tcp             # Protocol used by the service
user = nobody              # Run proxy as user 'nobody'
wait = no                  # Do not wait for close, spawn a thread instead
redirect = 65444 # Where OpenVPN is listening
only_from = ::/0 # Allow world + dog
port = 443                 # Listen on port 443

Workaround 2: socat and supervisord

socat is a Swiss Army knife of networking, able to tunnel just about anything to anything else.  I was actually going to deploy that route, but whilst I was waiting for socat and supervisord to install, I decided to explore xinetd‘s capabilities.  Both will do the job however.

There is a catch though, socat does not daemonise. So you need something that will start it automatically and re-start it if it fails. You might be able to achieve this with systemd, here I’ll use supervisord to do that task.

The command to run is:
socat TCP6-LISTEN:443,fork TCP4:

and in supervisord you configure this accordingly:

command=socat TCP6-LISTEN:443,fork TCP4:"

Jun 232011

It was interesting when I posted a news article to the WIA regarding IPv6, how quickly it got shot down by “experts”.

A recent addition to our network was a 2008-model Apple MacBook, which I have dual-booting Gentoo and MacOS X 10.6.7 nicely.  One quirk of this particular laptop though, is that it will, when running its native OS, intermittently drop off the IPv4-only network.

The first tip-off to this is usually things like Skype ceasing to work.  Then I’ll notice DNS isn’t resolving (DNS is IPv6-accessible, but not many systems support RDNSS).

As a work-around to the problem, and also for my own self-education, I decided I’d have a crack at getting NAT64 and DNS64 to work.  What are they exactly?

NAT64 as the name suggests, is a variant of NAT that translates IPv6 to IPv4.  In doing so, allowing my MacBook that’s just disappeared from the face of the IPv4-only world, to still access the IPv4-part of the Internet.

DNS64 is a service that synthesizes AAAA records for host names that do not provide one.

The two work together to provide Internet access to an IPv6 only host.

What you will need to know

Make sure you have the following information on-hand.  I’ll use the following examples:

  • Your server’s IPv4 address on the local network: e.g.
  • IPv4 NAT address pool: This must not overlap with your existing networks.
    Examples use, I used
  • TAYGA’s tunnel IPv4 address: This will be the first address in the above subnet (i.e.
  • Your network’s IPv6 subnet: e.g. 2001:dead:beef:1200::/56
  • IPv6 NAT address pool: This needs to be a non-overlapping portion of your address space.  In my case, I’m borrowing a /56 from AARNet, and I used a /64 for this, setting the lower 8-bits of the prefix to 0x64.  It only needs to be /96 in size.
    Example used: 2001:dead:beef:1264::/96

NAT64 setup

To get NAT64 working; start by installing TAYGA.  This is a userspace daemon uses the TUN device to route between IPv4 and IPv6.  On Gentoo, begin by running emerge tayga.  (You may need to keyword it.)

This installs the binary, but crucially, it comes with no init scripts.  You will need to create one yourself like this:

# Copyright 1999-2004 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: /var/cvsroot/gentoo-x86/sys-libs/gpm/files/gpm.rc6,v 1.12 2004/07/15 01:02:02 agriffis Exp $

depend() {
    need gw6c net.nat64

start() {
    ebegin "Starting tayga"
    start-stop-daemon --start --quiet -p /var/run/ \
        --exec /usr/sbin/tayga -- \
        -u nobody -g nogroup \
        --pidfile /var/run/
    eend ${?}

stop() {
    ebegin "Stopping tayga"
    start-stop-daemon --stop --quiet --pidfile /var/run/
    eend ${?}

Now, edit /etc/tayga.conf, using /etc/tayga.conf.example as a guide.  There are comments provided.  The following are the settings I used (with the above addresses):

# TAYGA's IPv4 address.  This is NOT your router's IPv4 address!  TAYGA
# requires its own address because it acts as an IPv4 and IPv6 router, and
# needs to be able to send ICMP messages.  TAYGA will also respond to ICMP
# echo requests (ping) at this address.
# This address can safely be located inside the dynamic-pool prefix.
# Mandatory.
# ... etc ...
# The NAT64 prefix.  The IPv4 address space is mapped into the IPv6 address
# space by prepending this prefix to the IPv4 address.  Using a /96 prefix is
# recommended in most situations, but all lengths specified in RFC 6052 are
# supported.
# This must be a prefix selected from your organization's IPv6 address space
# or the Well-Known Prefix 64:ff9b::/96.  Note that using the Well-Known
# Prefix will prohibit IPv6 hosts from contacting IPv4 hosts that have private
# (RFC1918) addresses, per RFC 6052.
# The NAT64 prefix need not be specified if all required address mappings are
# listed in `map' directives.  (See below.)
# Optional.
prefix 2001:dead:beef:1264::/96
# Dynamic pool prefix.  IPv6 hosts which send traffic through TAYGA (and do
# not correspond to a static map or an IPv4-translatable address in the NAT64
# prefix) will be assigned an IPv4 address from the dynamic pool.  Dynamic
# maps are valid for 124 minutes after the last matching packet is seen.
# If no unassigned addresses remain in the dynamic pool (or no dynamic pool is
# configured), packets from unknown IPv6 hosts will be rejected with an ICMP
# unreachable error.
# Optional.
# ... etc ...

Now, having done this… you just need to make sure the nat64 device gets created and initialised by openrc.  In /etc/conf.d/net:

# NAT64 configuration for TAYGA

preup() {
        case ${IFACE} in
                        /usr/sbin/tayga --mktun

Now, symlink /etc/init.d/net.lo to /etc/init.d/net.nat64, start the tayga service, and you should find that you can ping e.g. 2001:dead:beef:1264:: ( is Google DNS).

DNS64 setup

All good and well if you know the IP addresses, but most people don’t.  Now emerge totd.  Use /usr/share/doc/totd-VERSION/totd.conf.sample.bz2 as an example for configuring /etc/totd.conf:

; $Id: totd.conf.sample,v 1.9 2003/09/17 15:56:20 dillema Exp $
; Totd sample configuration file
; you can have multiple forwarders, totd will always prefer
; forwarders listed early and only use forwarders listed later
; if the first ones are unresponsive.
forwarder 2001:dead:beef:1234::1 port 65053
forwarder port 65053
forwarder port 53
forwarder port 53

; you can have multiple prefixes or even no prefixes at all
; totd uses them in round-robin fashion
prefix 2001:dead:beef:1264::
; the port totd listens on for incoming requests
port 53
; the pidfile to use (default: /var/run/
pidfile /var/run/
; interfaces totd listens on (UDP only for now and not on Linux)
; If left out totd will only open wildcard sockets.
;interfaces br0
; 6to4 reverse lookup

In my case, I have a local caching name-server (BIND), which I’ve moved to port 65053. The trick-or-treat daemon now sits on port 53 where the rest of the network expects it. You can now start the totd service, point your /etc/resolv.conf files to it, and everything should Just Work.


Easiest way is to shut off IPv4, and set up /etc/resolv.conf on your client with the IPv6 address of your server running totd.  You should now be able to browse IPv4-only sites as if IPv4 were running.  I achieved this test by plugging into Ethernet, turning off wicd (it kept wanting to start-up dhcpcd), then manually bringing the interface up and configuring /etc/resolv.conf.

Jun 082011

Well… has anyone noticed anything different about the ‘net?

stuartl@atomos ~ $ host is an alias for is an alias for has address has address has address has address has address has IPv6 address 2404:6800:4006:802::1011

I knew World IPv6 day was coming up, but it seems it snuck up on me and I barely noticed. Likely a testament to the fact we run a dual-stack network here, and so everything magically Just Worked™ as it should. Indeed, a lot of websites are now dual-stack, as is much of the infrastructure, Google (as seen above), FaceBook, and numerous other sites.

Sadly, a lot of ISPs here in Australia did the demented ostrich act when it came to IPv6. I wonder how many technical support calls they received, with users complaining about websites being slow to load up or failing to connect.

iTel, formerly “Global Info-Links”, now calling themselves “South East Community Telco“… were one of the masses that drove their RFC791-only heads in the sand and pretended that the entire Internet can be compressed into 32-bits of address space. We’ve been waiting to hear back from them on their plans for addressing since January as we’d like to upgrade the 512/128kbps ADSL link we use here. (Anyone noticed this site tends to load up a bit slow? That 128kbps figure is the reason why.)

We’ve been with this ISP since 1996. That’s quite a long innings… We’ve stayed put because until now we’ve been happy with the service. 512kbps was quite fast when we upgraded from 56kbps PSTN dialup (14.4kbps dialup when we first started… still have that modem too!). These days it plods along, but the 128kbps uplink is a notable thorn in my side with my telecommuting. So we’re looking at ADSL2+.

However, there’s one hitch. iTel is only a fairly small ISP. At the moment they do the noble thing of providing static public addresses on IPv4 for all fixed-broadband customers, but how long will that last? The last thing I want, is to sign up a contract for 12 months, then find out that in 6 months they need to move us behind CGN (Carrier grade NAT) to squeeze in some more customers. That won’t fly for us. I’d ideally like to ditch the 6-in-4 tunnel I have with AARNet and go native, or at the very least, swap it with one terminated at the ISP, but that doesn’t seem to be happening anytime soon.

At the moment there is only one ISP I know of that offers any sort of IPv6 connectivity. Internode. Kudos to them for taking the pioneering step! I’m seriously looking in their direction. I’m also hoping the NBN that we keep hearing about, is IPv6 enabled… and I’m holding out with the hope that our little suburb might soon be getting the long strands of glass laid down our street. If it’s only another year or so, it may be worth just hanging on with ADSL1 until then.

Thankfully, we do have the 6-in-4 tunnel through AARNet (and my greatest gratitude to them for providing it). There is a growing community on this newer protocol… I’m also happy to report absolutely 0 spam via IPv6… any spam or malware thus far has been via IPv4 … although I know this won’t last. The good news there is that with one unique address per computer (instead of per customer, or worse, per 100+ customers), it should be easier to track down the guilty party causing such Internet shenanigans. CGN by comparison is likely to be a spammer’s playground.

What am I doing about IPv6 deployment? Aside from my small-time tinkering with the network here… any socket programming I do today is at the very least dual-stack. One of my hobby projects is a digital mode stack for amateur radio… if I get my way it’ll be IPv6-only when used on a computer network.

One of my work projects involves interfacing some proprietary software to some power meters using RS-232 and RS-485 to Ethernet bridging devices. Even though the devices themselves are IPv4 only (and will be for the foreseeable future), I’m designing the software to handle IPv6. Doing this, future proofs the software. Surprisingly, I’m finding it easier to just design for dual-stack than it is to develop a IPv4-only application. If you’re building an application today, dual-stack IMHO must be part of the strategy if the application is going to work beyond this decade.

Some have asked about IPv6 on packet… sadly AX.25 packet does not go anywhere near fast enough to make IPv6 (or indeed, IPv4) networking a viable option on packet radio using existing TNCs… however I think IPv6 will, and should, play a much bigger part in amateur radio communications than it presently does… we can’t expect to hold on to the subnet for much longer.

To the ISPs that are lagging behind, I say get moving! IPv4 is older than I am! This is especially true of the smaller ISPs… if you don’t move, you will get squeezed out of the future Internet connection market as address space gets consumed. To the nay-sayers who keep telling us that something else will replace IPv4, to you I say get moving… you haven’t got long to invent this magical silver bullet, in fact I say you’ve left it too late.

Sep 122005

After some tinkering today, I managed to figure out the wonderous black art that is IPv6. Now I get to discover the Internet that IPv4 user’s don’t see.

How does one get hooked up to IPv6? Well, if your ISP doesn’t support it, then you have to establish an IPv6-in-IPv4 tunnel with an IPv6 broker. Since I’m in Australia, naturally, I set up an account with AARNet, and requested a tunnel through them.

Gentoo have a nice little guide, that steps users through setting up with either 6Bone or Freenet6… however it seems AARNet do things slightly differently.

The way I set things up was as follows…

Connecting a host to IPv6 via AARNet

Before we start, you’ll want to make sure you’ve got IPv6 support in your kernel. If you see a directory called /proc/sys/net/ipv6, then chances are good, you’ve got what it takes. 🙂

First, create an account. This is the username and password you’ll use to request the tunnel later. You’ll be emailed a system generated password. You only get one, and there’s no password changing facility (that I can see), so it would be adventageous to keep this email safe.

Next, fill out this form. If you’re just wanting to hook up a single host, then ignore the “Request for /48 prefix”. Otherwise, you’ll need to check that box — in the “Interface Name” field, enter the interface name for your internal LAN interface (e.g. eth1 in my case). You’ll then be asked for your username and password before downloading a setup shell script ( if you selected Linux).

Now, Place this somewhere convenient. I stuffed it into /etc/setup-ipv6. This script is what you’ll use to establish the tunnel. I call it from my /etc/conf.d/local.start (rc.local for those playing along with other distributions), so my tunnel is established at boot.

Right, with that over, it’s now time to install the tools necessary. On Gentoo, simply USE=ipv6 emerge iputils iproute2 freenet6 — Freenet6 use the exact same tools. Other distributions, AARNet provide the tools from their front page. You’ll also want iproute2, and a version of iputils with IPv6 support.
Gentoo users may find it adventageous to set USE=ipv6 in their /etc/make.conf, and update their system so that they can make use of IPv6 support in any applications able to utilise it.

Lastly, we need to configure tspc, the tunnel client. On Gentoo, edit /etc/freenet6/tspc.conf (just hack up the example config). Place in there, the username and password you were given from AARNet, and down the bottom, change the server= line to read You’ll also want to edit the file, to make sure the directories mentioned are correct, in particular, TSP_HOME_DIR should point to the directory containing tspc.conf.

And now we’re ready to bring up the tunnel. Run sh (or whatever you ended up calling it). You should see something like this…

(23:32) www ~ # /etc/setup-ipv6
--- Start of configuration script. ---
Script:  setup-ipv6
sit1 setup
Setting up link to
This host is: 2001:0388:f000:0000:0000:0000:0000:0279/
Adding default route
Router configuration
Kernel setup
net.ipv6.conf.all.forwarding = 1
Adding prefix to eth1
Starting radvd: /usr/sbin/radvd -u radvd -C /etc/freenet6/tsprtadvd.conf
--- End of configuration script. ---
(23:32) www ~ # _

You’re now running IPv6. Go on, get out there… explore. 🙂 To check you’re really browsing IPv6, try pointing an IRC client at (Ohh, and don’t forget to pop in to one of the Gentoo channels and say Hi ;-)), or point your web browser at the KAME website. If you’re running IPv6, their tortise should be dancing (it’s an animated GIF). You can also try pinging various sites such as or using the ping6 utility.

Sharing the love

So, suppose you asked for a /48 prefix, and you’ve got a bunch of machines sitting behind the router that you want on IPv6 too. Easy fixed. You’ve got a couple of options. One is to set up dhcpv6, or the other, is to simply use radvd. The latter works out of the box, the tunnel script automatically configures radvd for you.

On Gentoo, simply emerge radvd. Then restart your tunnel script. It should start radvd, and within a few seconds, the other machines on your network should receive the route/adressing advertisments, and automatically configure themselves for IPv6.

This is only half of the story though … You then have to enable IP forwarding on your server. (Sound familiar? Should do… same as IPv4).
Simply run echo 1 > /proc/sys/net/ipv6/conf/default/forwarding, and you should see the packets start flowing.

Keeping the nasties out

Now that you’ve got routing set up, it’s time to lay down the law regarding firewall rules. Quite obviously, you don’t want the outside riffraff upsetting your delicate hardware unless it’s got a specific invitation to do so. Make sure you’ve got netfilter6 support in your kernel, and the ip6tables utility. (distributed with iptables)

At the moment, there’s no connection tracking in IPv6, nor is there any network address translation (which is unnecessary on IPv6 anyways). The following is what I use for my firewalling rules, adapt to taste.

# Generated by ip6tables-save v1.3.2 on Sun Sep 11 23:57:08 2005
:PREROUTING ACCEPT [16827:6712869]
:INPUT ACCEPT [1297:98415]
:FORWARD ACCEPT [15530:6614454]
:OUTPUT ACCEPT [1629:131392]
:POSTROUTING ACCEPT [17230:6752830]
# Completed on Sun Sep 11 23:57:08 2005
# Generated by ip6tables-save v1.3.2 on Sun Sep 11 23:57:08 2005
# By default, drop anything comming in or through us.
# Allow all ICMP traffic
-A INPUT -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT

# Local LAN interfaces (note, since I'm behind an ADSL router, all my interfaces are private, except sit1)
-A INPUT -s ::/0 -d ::/0 -i eth+ -j ACCEPT

# Allow SSH and IRC connections (I'd open more, but I'll need DNS working first)
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -s ::/0 -d ::/0 -p tcp -m tcp --dport 6667 -j ACCEPT

# Forwarding rules...
# Allow internal traffic OUT
-A FORWARD -s ::/0 -d ::/0 -i eth+ -j ACCEPT

# Allow established connections back IN
-A FORWARD -s ::/0 -d ::/0 -i sit1 -o eth+ -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -j ACCEPT

# Allow ICMP traffic
-A FORWARD -s ::/0 -d ::/0 -p ipv6-icmp -j ACCEPT

# Log anything else
-A FORWARD -s ::/0 -d ::/0 -j LOG --log-prefix "FORWARD IPv6: "
# Completed on Sun Sep 11 23:57:08 2005

It’s a crude firewall, but it works. 🙂
The above guide, is far from being perfect, but hopefully my notes above will assist others in migrating to IPv6.