site to site VPNs. I'm confused

March 29, 2019 5:44 AM

I rate myself as fairly technically minded, but one thing over the years that I've never fully wrapped my head around is VPNs. That's the point to point VPN, mind. I've successfully connected up against a VPN provider using a desktop client before. So what I'd like to do, is effectively make a bridge between my work network and my home network so I can do things like: ssh into my Raspberry Pis from work Connect to my Asterisk/FreePBX setup from work Connect to my work samba shares from home.

I've got a TPLink TD-W9970 modem/router at home, and a Netgear DGN2200v4 at work. I know they both support VPNs. (For example here, page 103)

But I'm also wondering if there are other, simpler, more reliable ways to skin this cat. The DGN2200 is a real POS and the GUI is fairly often unavailable. Sometimes you can power cycle it and gain access to the GUI for a few minutes then it locks up again.

Like, would running OpenVPN on one of the Pis at home make all this possible or would I ALSO need OpenVPN running on a Pi at work? This is kind of where I come unstuck. Furthermore I'm kind of clueless as to whether I could just configure the Linksys PAP2T (for the SIP access) to connect to my (as yet non existant) home VPN instance, or whether VPN just doesn't work like this?

At one point I thought I'd get into PiVPN as it seemed simple and designed to be as user friendly as possible...but as I started to try to use it, I noticed it's actually a dead/dying project...!

I'm also concerned about security. I've seen reference to how some of the VPN technologies are no longer secure, but some router firmware etc doesn't "know" this and therefore you might make a tunnel that isn't at all secure whilst believing that you are secure.

HELP!!

(thanks!)

posted by dance to Computers & Internet (12 answers total)

When you connect to a VPN using your desktop client, you're making a temporary tunnel between the remote network & your machine. Often, that means you temporarily gain a new IP address in that remote network. For the lifetime of that VPN session (until you disconnect), it's like you're part of that remote network - so, addresses that only resolve via the remote network's DNS will resolve for you, you'll be able to route to their services that are not exposed publicly... etc.

That's great for cases where only one machine (your desktop) needs only temporary access to the remote network. But, in the case where >1 machine needs consistent access to the remote network, you can set up a site-to-site VPN that everyone can share. That means that a router at your side talks to a router at the remote side, and between them they negotiate a configuration for an encrypted tunnel. That would include agreeing a list of subnets or address ranges that should be able to see through the tunnel from either end, and exactly which encryption protocol to use, and... etc.

So - when I'm doing this with IPsec for work purposes - I set up a VPN gateway on my side, and talk to the network admin at the other side while they do the same. We share a whole bunch of config parameters, we both press the big green button, and then - boom, we have a tunnel (although usually, first we both trawl through our logs to find out why it didn't work first time, then we fix the errors). Once the tunnel is up, all the servers in e.g. 10.10.10.0/24 subnet on my side can talk to all the servers in e.g. 192.168.1.0/24 on the far side. There might be a bunch of other config we want too - like, some routing so that I tell my servers that their next hop when they want to go to 192.168.1.101 is via the gateway at my end of the tunnel - or, I might firewall it at my end so that only traffic on port 22 and port 443 is allowed through & anything else is dropped. Or whatever.

I'm not familiar with the routers that you mention - but, if they can both do IPsec then in principle you can have a go. Remember that it's the edge devices in each network (ie. devices that you can already expose with public IP addresses) that would need to create the tunnel.

I haven't used OpenVPN. Based on a very quick look, it seems like it works differently.
posted by rd45 at 6:19 AM on March 29, 2019

Generally, a VPN client requires a VPN server to connect to. However, I would strongly advise against setting up an unofficial VPN server on your work network; IT departments tend to take a very dim view on such things. Setting it up incorrectly means that you could be personally responsible for breaking the network for everyone at work, or that you could be personally responsible for giving the world access to confidential information from your employer's systems. Many places that I've worked at have paragraphs in the handbook explicitly calling out doing things like this as an immediate dismissal and walkout. If you really need a VPN server, ask your IT people if there is one already or if they could set one up for you.
posted by jordemort at 6:19 AM on March 29, 2019 [1 favorite]

Point to point requires a device on both ends. You cold conceivably do this with a node like a Raspberry PI and open source IPSEC VPN software. For it to work like a true p2p VPN, that Raspberry PI node would need to also be either the default gateway for the network, or have all that VPN traffic routed through it. I don't know a whole lot about consumer grade modem/routers but I doubt they are capable of that kind of routing.

To build a point to point between those two network devices, my guess, is nearly impossible. I'm saying that based on the experience I have building many p2p VPN's between Cisco enterprise grade firewalls, which was always quite a pain in the ass. I have done it Cisco -> Other manufacturer, and that was even harder. Getting the encryption algorithms and routing and timeouts and all that to match, it can get hairy.

So the best advice I can give is, if possible, search for a router that explicitly does point to points, and ideally has great documentation and a user community. Buy two of them, one for each location. With ths configuration you will need to use the existing modems as pass through, and then configure the router as your network gateway. You might be able to find a device that can handle both modem and routing piece, but it must work as the modem for whatever kind of internet drop you have at each location.

Finally - the internet provider you use at each location should be issuing you a static external IP. If it isn't, anytime the outside IP switches, the VPN will have to be re-configured. You MIGHT be able to get around this with dynamic DNS.

And, on preview, jordemort is 100% correct. I am assuming that "work" is another location where you control the network. If it is a corporate network, then all the above won't help.
posted by pilot pirx at 6:29 AM on March 29, 2019

As others have said, the first thing we need to know in order to give you good advice here is whether or not your work IT infrastructure is under your personal control. Could you clarify?
posted by flabdablet at 6:35 AM on March 29, 2019

Response by poster: Sorry flabdablet, pilot and jordemort - I am the owner of the work network AND the "IT sysadmin guy". Reading with interest what you've all written, you too rd45 - thank you - just wanted to reply quickly with that info.
posted by dance at 7:01 AM on March 29, 2019

Bridging your home and work networks with a VPN is a very bad idea. I am a principal security architect and if you did this where I work you would receive an extraordinarily stern warning and possibly be let go.

If you wanna set up a VPN tunnel between your home and an AWS ec2 instance then somehow figure out how to securely get from your work network to your personal AWS account without VPN (TLS over the Internet, for instance?) you will be in a much more tenable position.

You can use any device on your home network behind your router to terminate the VPN tunnel. It doesn’t have to be on the edge routers.
posted by nikaspark at 7:02 AM on March 29, 2019 [2 favorites]

Personally I do this kind of thing by exposing an ssh server to the Internet at each end, then using ssh port forwarding to tunnel individual network streams. This is more restrictive than a VPN and I prefer it for that exact reason: I can be completely sure that nothing will go to any endpoint I didn't explicitly set up a TCP port forward and possibly a UDP adaptor for during the specific ssh session I'm working in.

The security of an ssh connection is about as good as can possibly be obtained by any means, and exposing an ssh server to the Internet doesn't need your router to do anything cleverer than forwarding incoming connections to some port on its Internet-facing IP address to port 22 on some box inside its LAN. I prefer not to use port 22 on the Internet-facing side; I'll use an obscure port number over 32768 instead because my fail2ban logs stay much less busy that way.

Windows RDP, including all the associated remote file and print access stuff, runs very nicely over ssh port forwarding. NoMachine works even better. Most ssh servers also have SOCKS5 and SFTP support built in, which is useful as well.
posted by flabdablet at 10:12 AM on March 29, 2019 [2 favorites]

The fact that your Raspberry Pi will already have sshd running on it makes it a natural endpoint for the home side. You mentioned Samba shares at work; if you actually mean Samba, as opposed to an actual Windows box running SMB, then whatever you're running Samba on is probably already running sshd as well.

SMB at Internet speeds is generally pretty miserable in my experience. If you actual end goal is simply getting home access to work files, doing that via the SFTP facility built into sshd works a lot more smoothly.
posted by flabdablet at 10:29 AM on March 29, 2019

A p2p VPN generally links two disparate networks with different subnets. Along with those links come a host of complications including DNS, routing, and permissions. These are not extremely difficult problems (in the larger scheme if such things), but they can be daunting if you’ve never set them up. if you are truly trying to share services between networks, then you need will to take them into account, particularly the routing on each side.
If you really want to roll your own, check out strongSwan for creating long-term, stable, open-source IPSec tunnels. A pi on each end should work but the configs will take some time to figure out and the secondary work will be not-inconsequential. Definitely do not use consumer-grade routers
All that being said: this sounds like fun to me. Good luck and feel free to holler if you’ve more questions.
posted by mfu at 7:37 PM on March 29, 2019

Actually, you can use ssh to tunnel an entire device. It takes some setup (I might still have some scripts around). I only know the Linux side of things... The client uses 'ssh some-flags remote' and a new 'tun0' device appears on the client and server side. This is just roughly an ethernet bridge. You then have to put your own IP network info onto both ends and setup routing. Then if you want you can setup forwarding and NAT masquerading on either side as desired. And then you can use 'dnsmasq' on the client side to manage routing '*.server.com' DNS request over to the server side DNS (in case the server networks DNS isn't public).

Before that I did OpenVPN on the server and used a ovpn client... It was sorta sucky and finicky sometimes (as is the ssh tunnel).

After that... If you can... You install the kernel space WireGuard: fast, modern, secure VPN tunnel and basically have an always working tunnel ala IPSec but much easier to get working. I believe there's talk of putting this into the Linux kernel proper (last I checked you had to build a loadable module). WireGuard was vastly superior to the ssh and OpenVPN in speed and ease of use. But it still requires the same 'playing with the routing and iptables if you want to NAT forward out of the other end.

You'd have to open/forward some ports on your routers to the endpoints, and hopefully the server side has a static external IP on the router. I'm not sure the PtP type tunnels deal well with dynamic public IPs to get that initial connection going.

But really, just try the 'set of ports to ssh forward' that flagdablet suggests. You can do a lot with ssh options. They only become a PITA when you have programs that don't quite work when you try to tell them 'this local port' is this 'remote side'. Sometimes you need to route a whole network range (ssh tunnel device or OpenVPN or WireGuard or IPSec/etc on the routers).
posted by zengargoyle at 11:01 AM on March 30, 2019

you can use ssh to tunnel an entire device

Yes you can, but that doesn't mean you should.

Apart from negating the entire point of using ssh port forwarding, i.e. the warm fuzzies you get from knowing exactly what you've tunneled to where and why and how, it's easy to end up inadvertently running encapsulated TCP streams inside the overall TCP connection maintained for ssh. And that's really not a good idea.

OpenVPN also allows itself to be misconfigured in this way.

If you really really need a VPN (and I continue to maintain that for most use cases you simply don't) then you will get far more reliable results from using software specifically designed for the purpose than from cobbling together some half-assed thing over ssh.
posted by flabdablet at 8:21 PM on March 30, 2019

They only become a PITA when you have programs that don't quite work when you try to tell them 'this local port' is this 'remote side'.

The only use case where I've ever struck serious resistance is trying to run Windows file sharing over ssh port forwarding on a Windows client. It works just fine on Linux and Mac clients.

Windows can't be persuaded to connect to a remote SMB server on any TCP port other than 445; and every Windows box with file sharing enabled binds its own SMB service to port 445 on every network interface at startup, which makes it impossible for ssh to set up a forwarding listener there. There are workarounds, and I've used them, but they're always at least two out of three of ugly, fragile and unacceptably restrictive.

Remote desktop protocols work OK via ssh port forwarding, though I have seen terrible file transfer performance over Windows RDP that suggests to me that RDP might be doing something that boils down to TCP-over-TCP tunneling internally.

If file transfer is the goal and ssh port forwarding is the available tool, then using SFTP instead of SMB is working with the grain instead of across it.
posted by flabdablet at 8:37 PM on March 30, 2019