How to get round an ISP’s filter
Network Filter bypass solutions
The world is more connected now than ever before, and the change never seems to stop. My first experiences were a remarkable contrast to present-day possibilities.
Radio is a constant source of amazement to me. Ever since my first contact across the planet using morse code on 3.5MHz, I have been fascinated by the way signals bounce against the sky like a stone skipping across a pond; all dependant on the time of day, space weather, and the solar cycle. I began to experiment with combining computing and radio together. I worked with Modern DSP and, more recently, software defined radios. The hobby has never had so many opportunities. It is possible to send now what used to be unimaginably vast quantities of data, and these quantities increase all the time. It is even commonplace to use the moon as a giant reflector.
And then came the internet. That single development revolutionised the planet, aggregating traditional signalling over sound, radio and light waves together as a global network standard; even the eccentric and esoteric methods (RFC 1149; IP over Avian Carriers). It’s easier than ever to communicate across large distances, without the delays or problems traditionally experienced.
However not every change in recent years has been for the better.
With persistent attempts to erode net neutrality, including the upcoming battle in the European Parliament to repeal the neutrality law passed in 2014, this wealth of information and ability to communicate may soon disappear in the blink of an eye.
Recent introduction of mandatory filtering in the United Kingdom is the most insidious taste of what awaits us if this continues. Filtering is frequently touted as the solution, with little discussion of the fallout it causes. It has created many more problems than it has solved and should serve as a pertinent reminder of just how damaging censorship is and how easily open discussion can be silenced.
The Open Rights Group (ORG) have already demonstrated this, with the BLOCKED! project. It aims to reveal just how indiscriminate and futile filtering is. If you want to know more about it, or if you’ve ever wondered whether a site is blocked, visit blocked.org.uk.
Last July, tired of suffering mandatory filtering with ever more tedious opt-out procedures (along with Man In the Middle Attacks as a Service, and lousy networks) I decided that the time had come to find a solution. I wanted to avoid the hassle and hostility of public networks. I also wanted something easily supportable and (most importantly) cheap, with lots of redundancy.
It was time to look for a new provider, and there were several major considerations. IPv6 was one. Many public networks or ISPs still do not support or offer it on request. The same is also true for every VPN provider reviewed to date. This is disappointing as support in OpenVPN has been stable for some time and allows allocation of dynamic and static IPv6 addresses with minimal effort.
As an added consideration, I had begun to ask questions over whether IPv4 was still needed. I wanted to know if I could still work and play without it. This was the perfect opportunity to experience the wider internet with only IPv6 and NAT64.
Further pre-requisities narrowed the list down further:
1) UK and EU based companies with no presence in the US. Unfortunately, the US has some very regressive laws regarding privacy and citizen rights; I cannot willingly condone this or accept that my data will automatically be handed over as a result of Patriot (and other laws). This was a great deal more difficult than it might at first appear and I had to accept that it might ultimately be impossible to achieve, but I was determined to look for it nonetheless.
2) Connectivity as close to LoNAP/LINX/AMSIX as possible. Latency (both round-trip-time and jitter) is a big concern. Any ‘VPN-by-default’ solution needs to be located as close to a regional internet exchange as possible to mitigate the effective route from computer to endpoint, and endpoint to
3) Redundancy, preferably across different networks. As all networking will be firewalled on my computers, ideally there should be more than one endpoint and network.
4) Reasonably trustworthy third parties/endpoints. It’s extremely difficult to find providers who are willing to discuss and be very open about their network or how they operate. Even if you are not looking for a Google ‘Do no evil’ level of statement, it is still difficult to find mission statements that suggest a level of professionalism and reasonable expectations over security.
5) KVM VM support with either serial or VNC access to install from scratch.
As a long standing customer of Mythic Beasts (shameless plug; outstanding service and support, so good that I switched companies recently to work for them) they were high up on my list. And of course there was Tilaa in the Netherlands. Both companies have peering with regional Internet Exchanges (LoNAP/LINX with Mythic, and AMSIX with Tilaa). Third in the run up was NodeDeploy who very kindly offered to provide serial KVM and ISO images on request.
First experiences with IPv6+NAT64 were promising. Almost everything continued to work where IPv6 support existed in applications. Where IPv4 was either hardcoded (Skype/Steam/Mosh) or IPv6 support was missing, these understandably broke. Mosh was a point of annoyance for me: it was first released in 2012 but completely lacks all IPv6. If you are willing to use the experimental version, it does however switch between v4/v6.
Linux and FreeBSD both require extra work to coerce Neighbour Discovery Protocol to advertise OpenVPN clients to gateway routers. NDP is the ARP equivalent for IPv6; it is slightly more useful in comparison, although implementations vary subtly due to RFC ambiguity.
The easiest approach is arguably the incorrect one: to configure OpenVPN to use TAP interfaces and bridge your clients to the external interfaces.
At this point, NDP will correctly reply to solicitations from routers and local addresses, although you will be indiscriminately exposing your clients to layer 2 noise; in some cases this is a non-issue or desirable if you need layer 2.
For my situation, TAP interfaces add overhead per packet and network ‘noise’.
Working around the limitations of TUN interfaces and NDP is relatively painful in FreeBSD. The only reasonable solution is to modify the kernel (or create a kernel module) to manage the Neighbour Solicitation/Advertisement for your clients. The BSD implementation of NDP expects all addresses to have an associated hardware address on a given interface. This simply does not exist for TUN interfaces.
Some of this already exists in NDPROXY thanks to work by Alex Fenyo, although implementing it still requires non-trivial changes.
Linux is slightly easier to work around and does not require kernel modifications/modules. However every single address needs to be added to the routing table before Neighbour Advertisements are sent. If you only need a small number of addresses, this can be managed in two ways. The first is via the ‘route-up’ and ‘route-down’ hooks in OpenVPN to call external scripts to add or remove as needed. The second option is to use ndppd by Daniel Adolfsson, which will respond to Neighbour Solicitations for a configured subnet. This the preferred option with Linux as it does not require thousands of routing entries or use of hooks in OpenVPN.
So how does OpenVPN deal with redundancy? At the moment only a list of endpoints can be given for the client to attempt, in order of descending preference. This list can be randomised each time OpenVPN is started, if rudimentary balancing is required.
Travelling with OpenVPN is an interesting frustration that unfortunately is not easily avoided. Whilst OpenVPN in UDP mode is extremely tolerant of packet loss, it’s difficult to avoid the death of TCP connections.
Whilst MTU and tcp queues can be decreased and increased respectively on the server and liberal use of mssfix on clients, any disruption longer than 2 minutes unfortunately still ends in tears.
In the past year I’ve learned to accept this and have had reasonable success with minimum MTUs of 1280 whilst allowing OpenVPN to attempt another endpoint after 2 minutes. Liberal use of screen avoids much of the pain, whilst mosh allows mostly seamless connectivity regardless of tunnel state.
Finishing up, OpenVPN supports key renegotiation/generation after user defined limits. These currently include;
– Bytes sent/received
– Packets sent/received
These values are treated as ‘since last renegotiation’; renegotiation occurs whenever one of these values is reached. This allows you to ensure keys are only used for a maximum number of packets, data, and for limited lengths of time. To ensure a smooth transition, a transitional period exists, during which both old and new keys will be valid for use. This value can be increased or decreased as desired. It should be noted that both server and client must share these exact values. At the moment these values cannot be pushed to the client. When unset or mismatched, packet loss over the tunnel will occur until the client notices that keys have changed and renegotiates accordingly.
Of course, if Theresa May and David Cameron opt to ban encryption, things might turn out similar to:
A day in the life of a Mythic Beasts Employee
During the length of this project, SaltStack has helped to significantly simplify the pain involved in updating existing endpoint configurations for Bind9, OpenVPN, Tayga and firewalls. It’s also an invaluable tool when creating new endpoints for testing. In contrast to Puppet, updates and changes are pushed from master on-command, rather than continual polling. Visit SaltStack for more information.
About the author
Rhosyn Celyn lives in a strange world comprised of film quotations and My Little Pony. She enjoys wearing eccentric hats and manages the newly formed Wizard division at Mythic Beasts.
Other posts in our women in tech week include: