Domain-Specific VPN Router | Hacker News Reader

Domain-Specific VPN Router

github.com

55 pointspatrickk27 comments

The killer use case of this would be for people like myself in places like Australia, if I wanted to make my entire network pretend that I was in the US as far as Netflix and only Netflix is concerned. That way, my PC, TV, media centre, iPad, etc. would all transparently have Netflix work yet not end up routing all of my other traffic through the US.

My family could then 'just use' Netflix on their various devices without me having to turn it on at the same time as I play a game without my ping being sent through the roof routing to the US and back.

PS: any Aussies out there, I am not telling you to do this. We're not allowed to use Netflix according to the ToS/EULA.

Edit: that is to say, Netflix is one of many. See also BBC iPlayer, Apple radio, etc. etc.

This is would make my wife really happy, being able to catch up with Aussie TV soaps from Germany. Thanks for making my life a bit better.

By the way, is this achievable via OpenWrt or something similar?

There are services that offer this now. You simply change your DNS servers on the media box to the proxy providers', and they rewrite DNS answers for those specific hosts to point at their proxies for those specific services.

It's nice because it requires no network changes, only DNS settings on the media player device.

Pretty cool. Anyone try to get this running on openwrt? Seems like the most logical place to have it.

Won't that leak metadata like crazy? Most pages are not contained to a single domain, and all 3-rd party traffic pertaining to a certain VPN'd web site will still go around unencrypted...

So this might be marginally useful for things like watching US streaming services from overseas or using it with point to point protocols, like SMTP/IMAP, etc...

But not for anything that requires any degree of operational security.

I implemented this a while back but considerably more efficiently. I wrote a DNS forwarder that adds the resolved IPs to an ipset. The kernel implements this as a hash table, so lookups are quick. The approach of this project does not scale well.

http://git.zx2c4.com/ipset-dns/about/

I wasn't satisfied with it being standalone and having to forward things to my real resolver, so I went ahead and wrote a patch for DNSMasq that got accepted:

http://lists.thekelleys.org.uk/pipermail/dnsmasq-discuss/201...

So in your dnsmasq config, just add:

ipset=/whatever.com/myipset

And then you can do the ordinary matches in iptables to adjust packets as you please, using fwmarks if you need to affect routing.

Both tools are included in OpenWRT now as well, if you want to run it on a device.

RPI really wouldn't be my first pick; even with the arm asm crypto, you end up with <10Mbps at 100% CPU, I believe.

I've been trying to find a super-cheap embedded board with better crypto performance. A silvermont atom might be the best choice, and use the crypto performance both for VPN and for some kind of NAS with good disk crypto.

I've been able to saturate my residential connection with an embedded atom board running pfSense. CPU usage was minimal and it even stayed in a low power state.

That's not surprising, the Atom is a proper CPU, whereas the RPi is a GPU that incidentally has a wimpy CPU attached to it. However, it's a lot easier to take a punt on a project at the RPi's price point.

I do this on Linux with ssh -w and a bit of routing.

On top of that the SSH tunnels provide more security to boot. I don't understand why people are still deploying PPTP today when SSH, SSL based and IPsec VPNs are generally trivial to get working appropriately. If nothing else than to move traffic to a specific geo location this is OK, but beyond this use case the solution is weak from a security point of view.

Support probably. PPTP is pretty widely supported.

Also, SSH tunnels are tunneling TCP over TCP (I assume that the VPN support operates in a similar way). See sshuttle for something better.

Is there anything equivalent for Windows? I heard of ProxyCap and Tunnelier, but I don't know the technical details of how those work - i.e. if they avoid TCP over TCP tunneling.

The OpenSSH VPN function opens a tun(4) network interface and tunnels layer 3 traffic.

VPN should be TCP over UDP (at least OVPN is)

Care to share more details?

My use case is the (presumably common one) of being able to ssh out of a corporate network to a machine on the public Internet (e.g. your home machine), from which you want to tunnel back to the corporate network.

On the server, set "PermitTunnel yes" in /etc/ssh/sshd_config, and run (as root):

    sysctl -w net.ipv4.ip_forward=1
    ip tuntap add dev tun0 mode tun
    ip addr add $SERVER/32 peer $CLIENT/32 dev tun0
    ip link set dev tun0 up
    arp -sD $CLIENT eth0 pub

On the client, run (as root):

    ip tuntap add dev tun0 mode tun
    ip addr add $CLIENT/32 peer $SERVER/$PREFIX dev tun0
    ip link set dev tun0 up

The above settings need only be run once (unless you reboot the machines).

Back on the server, as your normal user, run "ssh -w 0:0 user@$CLIENT" to establish the connection. The -N, -f, -oExitOnForwardFailure=yes, and -oServerAliveInterval=15 options may also be desired.

$SERVER is the IP of the computer in the network you want to tunnel into.

$CLIENT is the IP selected for the computer you want to tunnel from. Note: it is not the client's public IP! You should pick an unused one on the destination network. If you can't do this, then you can only tunnel to the server itself.

$PREFIX is the size of the prefix of the network you want to forward (typically 16 or 24).

If you only want to tunnel to the server itself, then $PREFIX should be 32, and you can skip the sysctl and arp commands on the server.

If you have other tunX devices in use, adjust the tunnel device numbers accordingly (don't forget about changing ssh's -w argument too).

This won't work if the client is also behind a NAT gateway or on a private network.

Thanks a lot for sharing this, highly appreciated!

(Personally I would put it into a script, because I usually don't remember things like that.)

Hmm, do you think this could be solved more elegantly on using a VM Containing a Cumulus Networks OS with a programmable Virtualized Network Stack?

Product: http://cumulusnetworks.com/product/overview/

Source: http://cumulusnetworks.com/product/open-approach/

Not a clue, I'm not really a networks guy! Though the setup in vanilla Linux is pretty straightforward I feel; not sure how much a VM would help with the use case I outlined above.

It's a DNS proxy that automatically adds routing table entries when queries/answers for "interesting" domains (associated with VPN connections) come in.

Adapting this to run on a host (which would be configured to use the DNS proxy running on itself) with VPN connections terminating on the host shouldn't be too difficult. There's certainly a use case for doing this on a router but I could definitely see wanting this on my laptop, too.

Don't VPN clients generally let you specify which traffic goes over the VPN and which goes out directly via the gateway? When considering to finally implement an OpenVPN running on my home server to provide remote access when I'm at a coffee shop, etc I always figured that I would have the ability to make this choice?

Hmm.. isn't PPTP essentially broken as far as crypto goes?

http://www.h-online.com/security/features/A-death-blow-for-P...

With that in mind, I'd say wait.

This is cool... but it's not entirely unlike split-tunnel VPN services, with lots of splits. And a bit of Dynamic Multipoint VPN thrown in...

That said, always great to see evolved routing techniques that can be controlled ("defined") by software.

just looked at the code, i was wondering about the reason for not choosing construct library (http://en.wikipedia.org/wiki/Construct_(python_library)) for parsing packets ?

edit : fwiw, i have used it for writing a rfc-3315 (and a few extensions) compliant dhcpv6 client, and it made the entire experience great fun.

would scapy be slower than construct?

What's the stability of this like? How much traffic can I send before the RPi falls to it's knees?

Awesome project.

pptp should be avoided at all costs. A better choice would be l2tp/ipsec or openvpn.

Reply on news.ycombinator.com