My Unenlightened View of VPN Tunnels

[Klueless]

These are my unenlightened ramblings. Please feel free to correct anything I wrote and/or offer advice and ideas.

I have a part time job as a driver at a used car lot. The owner actually has two lots; the main lot has about 100 cars and the second lot has about 25 cars. They are five miles apart. He mostly keeps the second lot because that’s where his service center is.

Most of our support systems are “in the cloud” such that we all have access. Unfortunately our Dealer Management System (a database of all our cars, sales, costs, etc.) resides at our main lot thus, when the second car lot sells a car the boss has to drive to the main lot to enter it into our database. Our service center database resides at the second lot such that when the main lot has a question about a vehicle in service they have to call or drive down for a status.

Recently we got a new ISP in town such that we were able to upgrade Internet from 15 x 1.5 Mbps to 400 x 20 and 100 x 10 Mbps respectively (for about the same price as what we were paying). As part of that we needed to upgrade our old routers so we replaced them with an Asus RT-AC86U, one for each lot. Our goal was to use the Asus routers to tunnel both lots together such that we’d be able to see each other’s data systems. We wanted to host the tunnels at the router so we wouldn’t have to load the tunnel software on all of the computers and data systems.

We started by setting up the router at the main lot to be a tunnel host and setting up a single PC at the second lot to be the client. We used “TUN” under OpenVPN. Because “TUN” is a layer 3 connection (a genuine make-believe router) we set both lots to use different network numbers? If this worked then our next step would be to make the 2nd Asus Router a tunnel client to the first (thus mitigating the need for tunnel software and overhead on the client PCs).

Well it kind of worked and kind of didn’t. First off the “split tunnel” was working. Internet traffic went straight to the Internet and car traffic went to the car lot. We could ping to some (but not all) of the devices at the main lot, we could print to the main printers and we could even log into the main printers' web portals but we could not connect to our database server.

It seems we have two layers of firewalls; one at the router and the other on the PC/computing device itself. The fact that we were able to get to some devices suggests that the tunnel was getting us through the router’s firewall? It further suggests that some PCs/computing devices were blocking us at their firewall?

I guess one thing we could try is to make sure all our Windows 10 devices are defined as “Private” rather than “Public” networks. The easier test to try would be to turn off the firewall on our Windows 10 database server. When that didn’t work we looked closer, the boss was running three (who runs three?) firewalls and we only turned off one of them. It will be awhile before I get another crack (as the two lot managers don’t get along all that well).

I then toyed with trying OpenVPN with “TAP” which I thought might get through her firewall as a layer two / genuine make-believe bridge to the “same” network but it wasn’t clear to me as to how to set it up. Do both networks have to use the same network number? Who/how hands out the IP addresses? Would the main lot have to be the DHCP server for both lots?

On a lark I looked at PPTP. One big plus was it also worked at layer two so there was a better chance of it dealing with firewalls. Another big plus was that it came already installed with Windows. Yet another plus was I understood it. You simply handed the server side (the router) a small pool of IP addresses that are outside of the pool of addresses you currently use.

For example the network number at our main lot is 192.168.1.X, my router is 192.168.1.1 and my DHCP pool is 192.168.1.10 – 192.168.1.99 so I simply gave my PPTP server the addresses 192.168.1.200 – 192.168.1.209 which were outside of anything I was already using.​

And it worked! I could ping, I could print and I could run my client app against the DMS database server. Two major downsides;

1. It was not split tunnel; all my Internet traffic went through the main car lot.
2. It was capital SLOW! A five second transaction over Ethernet was now taking several minutes over the tunnel.

At first I thought that the PC must be getting bogged down with encryption duties but as I played around some it hit me! Our Internet services are Asymetrical! Our main lot is 400 x 20 Mbps. Our secondary lot is 100 x 10 Mbps. Since the main lot can only send to me at 20 Mbps then that is all I can download. Since all I can send is 10 Mbps then that is all the main lot can pull. Said differently I can only talk to the main lot at 20 x 10 Mbps and the main lot can only talk to me at 10 x 20 Mbps. Then - couple that with something like 10X the latency and an interactive client/server app can get really slow!

Anyway, to test that, I ran an Internet speed test, sure enough, 20 x 10 Mbps. I disconnected my tunnel and sure enough, 100 x 10 Mbps. Since it ran as predicted I can now assume my PC (and tunnel) ain’t slowing anything down. It's the uplinks limiting the downlinks. (And the 10X latency.)

(As an aside I now better understand the appeal of bit torrent [besides to steal video], it's because the aggregate of slow uploads pool together to give you a great download speed.)​

And, I guess, even if I did figure out how to configure “TAP”, and even if it did work, that no one is going to use our client/server app because it’s just too too slow. It’s almost quicker to drive the five miles and just avoid all the frustration. Besides the guys at work tell me that they’re pretty happy when the boss has to leave for an hour!

 

[PolarBear]

I am gradually working towards something similar, but making slow progress since real life keeps getting in the way You are already much further advanced than I am.

I decided to go with OpenVPN as implemented in the Merlin builds, since there is a lot of information and experience represented on this site.

One thing I have figured out is to avoid TAP. With TAP there is only one DHCP server (at one end of the link), so if the link goes down, there is nothing at the other end to give out IP addresses.

Further, I seem to remember reading here somewhere that TAP generates a lot of "housekeeping" network traffic, so slows things down if the link is not really fast.

As you suggest, each end of the link should use a different address range. For example, at one end of the link, the DHCP server should distribute addresses (say) 10.100.111.x and at the other end the other DHCP server should distribute 10.100.222.x.

The VPN tunnel should be set up as UDP - no need for TCP as the contents flowing through the tunnel are already error-checked by TCP. Using TCP over TCP just introduces unecessary overhead and slows things down. Someone here (sorry, I can't remember who) wrote that sometimes TCP over TCP leads to a perfect storm and so everything grinds to a halt.

Split tunnel is good - any Internet traffic from either site should go directly to the Internet, not through the tunnel which may already be carrying a lot of traffic and therefore rather slow. This makes sense as you mention that you have some applications in the cloud. Much better to access them directly from each site.

Another point that has been mentioned here is that device discovery does not work well due to recent changes in Windows. So for example, a shared network drive at the other end of the link should be mapped using its IP address, rather than using the device or server name.

I am also using a non-standard port number, as a found in the system logs someone came port knocking at least once a day. Since changing, I have seen nothing in the logs.

So far, I have OpenVPN server running on an RT-AC86U, with corresponding OpenVPN client on my laptop. I find it works very well. Occasionally when I am working away from home I forget about the connection and leave it up for days at a time - no problems. The next step will be a install OpenVPN on a router at the other end and use that rather than OpenVPN on the laptop.

Good luck with getting this all set up - please keep us informed how it works out !

PB

 

[Klueless]

I am gradually working towards something similar

Thank you so much for taking the time to reply! You are indeed the "light at the end of the tunnel" so to speak : -)

One thing I have figured out is to avoid TAP. With TAP there is only one DHCP server (at one end of the link), so if the link goes down, there is nothing at the other end to give out IP addresses.

Ugh! That's kind of what I was afraid of. That also implies that both networks use the same network number?

Further, I seem to remember reading here somewhere that TAP generates a lot of "housekeeping" network traffic, so slows things down if the link is not really fast.

I've a reasonable number of devices on each side such that broadcast traffic should be manageable.

The VPN tunnel should be set up as UDP

Great point!

Another point that has been mentioned here is that device discovery does not work well due to recent changes in Windows

If you're talking about the file share I mount on my router I absolutely agree. If you're talking about a Windows 10 file share then that's pretty disappointing news (and could well explain some of the trouble I was having with "TUN").

I am also using a non-standard port number

I was toying with that after if/when I get things working. (Not sure I'll bother yet since the core app is so horribly slow!)

So far, I have OpenVPN server running on an RT-AC86U, with corresponding OpenVPN client on my laptop. I find it works very well.

What kind of stuff are you doing that is working so well? Do you have any Windows 10 machines connecting remotely to any Windows 10 file shares?

And, thanks again!

 

[ColinTaylor]

I can't really add much as you seem to have worked it all out yourself. But just by way of confirmation...

And, I guess, even if I did figure out how to configure “TAP”, and even if it did work, that no one is going to use our client/server app because it’s just too too slow. It’s almost quicker to drive the five miles and just avoid all the frustration. Besides the guys at work tell me that they’re pretty happy when the boss has to leave for an hour!

If the application does indeed perform that poorly then any further discussion is moot.

One thing I have figured out is to avoid TAP. With TAP there is only one DHCP server (at one end of the link), so if the link goes down, there is nothing at the other end to give out IP addresses.

This is the main point to emphasise. Relying on "normal" internet connections to create a network bridge is a disaster waiting to happen.

Regarding "Device Discovery", that only works on the local subnet so it's never going to work over a routed (i.e. TUN) connection. But that's not usually a problem. Any "server" machines should be using fixed IP addresses and can therefore have their names manually added to the DNS server on the other network if you don't like using IP addresses.

Allowing clients to access devices on the remote network is simply a matter of modifying the firewall rules on those machines.

 

[L&LD]

I hope the following link adds some important info to this thread.

https://www.snbforums.com/threads/u...o-asus-routers-via-openvpn-in-tun-mode.54868/

 

[RMerlin]

Running an application with its database accross a VPN tunnel will almost always be painful. Tried that a few years ago with my accountant (data on my NAS, application on his home PC), and the performance was horrible.

It's usually best to have a computer running local to the database, and then accessing it from your remote site using Remote Desktop. That's the setup I'm using with my accountant now, a Qotom PC running a virtual Windows machine, which he accesses remotely. You could either open RDP itself to the WAN (make sure to move to a non-standard port, and if you do have a static IP then filter its access by that IP), or having a VPN tunnel used to run RDesktop through it.

 

[Klueless]

If the application does indeed perform that poorly then any further discussion is moot

I'm still in denial but, ultimately, that's what I'm thinking.

Regarding "Device Discovery", that only works on the local subnet so it's never going to work over a routed (i.e. TUN) connection ... should be using fixed IP addresses ... have their names manually added to the DNS server on the other network if you don't like using IP addresses

Thanks, that'll come in handy.

 

[Klueless]

Running an application with its database accross a VPN tunnel will almost always be painful.

Awesome! I feel much less the failure now : -)

It's usually best to have a computer running local to the database, and then accessing it from your remote site using Remote Desktop

That was last years failure. It worked but my users found it "confusing" and went back to driving the five miles. But! Now that I've increased bandwidth by tenfold it might be worth another try ...

Thanks for bringing it up. I am going to give it another try!

1. I now have 10X the bandwidth.
2. I now have an extra laptop I can dedicate to being the remote access host this time around.
3. I can now locate it on Ethernet (rather than the slow [as in only 25 Mbps] wireless link I used last time).

Yes! I think I can make it work this time around.

 

[PolarBear]

What kind of stuff are you doing that is working so well?

I am using Excel and Word to create / edit / save small spreadsheets and documents. They take a few seconds to save (over a 5 / 0.5Mb/s link) but apart from that it seems to work perfectly.

Windows Explorer also works fine, and a file management program called Ztree. (Off Topic: Ztree is like Xtree completely re-written for 32 or 64-bit versions of Windows. I think it's GREAT and could enthuse about it for several pages, but that would derail this thread.)

Do you have any Windows 10 machines connecting remotely to any Windows 10 file shares?

No Windows 10 yet. I am using a Windows 7 laptop to print remotely, and also to access a Synology NAS which I think runs a version of Linux. I don't think there are any complications with Windows 10, apart from having to specify the server IP address explicitly, and making the appropriate firewall adjustments (which you need to do anyway for Windows 7).

Running an application with its database accross a VPN tunnel will almost always be painful. .... It's usually best to have a computer running local to the database, and then accessing it from your remote site using Remote Desktop.

Absolutely agree. In a previous life, I looked after a database application which was known to move a great deal of data across the network. Using Citrix I was able to use it very successfully over a slow 2 / 0.2 MB/s link. No problems once we set it up correctly. (If the user has a home drive which receives temporary files from the application, make sure the home drive is at the application end of the link.) RDP is a first cousin of Citrix, so I would expect similar performance.

@Klueless: Applications can find out if they are accessing a local or remote disk. It might be that the author of your database deliberately stopped it running if sees the data is not on a local disk, to avoid performance or data corruption problems, and unhappy customers. If this is the case, you may have to put RDP on the machine which is actually running the database.

(Remote Desktop) worked but my users found it "confusing" and went back to driving the five miles.

I have used Citrix on XP, Windows 7 and RDP on Windows 10. RDP on Windows 10 seems somehow more seemless and less likely to cause confusion.

You could either open RDP itself to the WAN (make sure to move to a non-standard port, and if you do have a static IP then filter its access by that IP), or having a VPN tunnel used to run RDesktop through it.

A number of vulnerabilities in RDP have recently been publicised. There have also been a few high-profile hacking cases, where RDP has been the way in. (Lanarkshire Hospitals in Scotland, for example.) So IMHO RDP or similar should be used only through a VPN tunnel, never exposed directly through an open WAN-facing port.

I hope the following link adds some important info to this thread.

https://www.snbforums.com/threads/u...o-asus-routers-via-openvpn-in-tun-mode.54868/

Thanks for pointing this out. It looks like an excellent resource.

PB

 

[Klueless]

Thank you very much for the update @PolarBear ... it's starting to look like "dump and run" apps work well while interactive apps (like database grab a record, think, grab another record ad infinitum) not so much so.

A number of vulnerabilities in RDP have recently been publicised ... So IMHO RDP or similar should be used only through a VPN tunnel, never exposed directly through an open WAN-facing port.

Darn! Just when I thought I could do without a bloody tunnel I get pulled back in <lol>

 

[RMerlin]

Darn! Just when I thought I could do without a bloody tunnel I get pulled back in

If you have a static IP (or your IP is always within the same range), you could whitelist access to that port to that specific IP. I've done that for a few customers where I had to expose RDP or FTP (for backup purposes), restricting access by IP range.

 

[Klueless]

If you have a static IP (or your IP is always within the same range), you could whitelist access to that port to that specific IP

Thank you, I think that is the approach I will take!

 

[Klueless]

Point:

The VPN tunnel should be set up as UDP - no need for TCP as the contents flowing through the tunnel are already error-checked by TCP. Using TCP over TCP just introduces unecessary overhead and slows things down. Someone here (sorry, I can't remember who) wrote that sometimes TCP over TCP leads to a perfect storm and so everything grinds to a halt.

Counter point:

For some people, TCP actually gives better performance than UDP (that was my case last time I did some benchmark tests).

SUCCESS! ... So this is interesting! Changing to TCP ... now am seeing speeds of 130mbps!!!

Guess the answer is "it depends". If you have trouble with one then try the other.

 

[Klueless]

Just wanted to take a moment to thank everyone for helping me out!

Summary:

• I started with OpenVPN using "TUN" (layer 3). It worked but I had trouble with device discovery and getting through the Windows 10 firewall.
  • I'm sure I could have gotten around these issues but I'm lazy so;
• I tried a PPTP tunnel (layer 2) and everything just worked!
  • But my client/server database was miserably slow!
• So I ran some benchmarks. My server is on 1 Gbps Ethernet. I picked a "transaction" and ran it across different scenarios:
  • Client on Gigabit Ethernet.
    • Speed: about 600 Mbps x 600 Mbps *
    • Latency (round trip ping): < 1 ms
    • Transaction time: 5 seconds
  • Wireless Client on range extender in the building next door.
    • Speed: 30 Mbps x 30 Mbps
    • Latency: 4 ms (about 8X)
    • Transaction time: 60 seconds (about 12X)
  • Client over PPTP VPN five miles down the road
    • Speed: 20 Mbps x 10 Mbps
    • Latency: 30 ms (about 60X)
    • Transaction time: 255 seconds (about 50X)

* Yes, Gigabit Ethernet "should" be closer to 1,000 Mbps but we've some old machines and I see closer to 6 and 700 Mbps

Conclusion:

• It would appear, in an interactive client/server application, latency effects performance as much, or even more so, than speed. (The tip off was going from wireless to tunnel. The speed degradation was only 30% while the latency was 7X which more closely matches the performance degradation of 5X.)
  • In my case, the answer will be a remote control app to a dedicated PC connected to the server over Ethernet.
• For other things like printing, looking at a file share or logging into my remote printers' web portals (to configure remotely), the tunnel performed well.

 

[RMerlin]

You shouldn't even consider PPTP as an option. It's cryptography has been considered broken for a few years now.

 

[Klueless]

You shouldn't even consider PPTP as an option. It's cryptography has been considered broken for a few years now

I agree. It was just a quick and easy way to test what I wanted to test. I mean really easy.

BTW: The boss really liked the tunnel. Yes, it was slow but fast enough that he could see the vision and got really excited. He even wanted me to explore upgrading our Internet uplinks to 100 Mbps. Now around here that is an expensive proposition but thanks to you, polar et al I'm going to recommend against it,

1. None of you had a good experience with an interactive database app through a tunnel.
2. My testing suggests that latency is the bigger issue and a bandwidth upgrade ain't gonna fix a latency issue.

So, thanks again everyone! I'm going to recommend RPD instead.

 

[PolarBear]

None of you had a good experience with an interactive database app through a tunnel.

Yes, we tried accessing the database base application *in the same building* through half a dozen switches (back in the days of 100 Ethernet), and the performance was terrible! So we used Terminal Services and that worked very well.

Later on we had very good experience with Citrix (very closely related to RDP) connecting the same large database application hosted in Europe to remote users with slow connections in places like the Far East, Sao Paulo and South Africa.

Of course, the above connections all went through the corporate-approved VPN tunnel.

Now that you have whetted the boss's appetite for working remotely, is he going to see you as obstructive if you don't deliver the vision ?

 

[Klueless]

Now that you have whetted the boss's appetite for working remotely, is he going to see you as obstructive if you don't deliver the vision ?

<lol> Good point! And for a car dealer to offer up money it means he really liked it!

 

[RMerlin]

Check how much RAM that server has. If it has enough, you could run that RDP system in a virtual machine on it.

Otherwise, either reuse an older PC, or if space is short, go for a small Quotom PC.

 

[L&LD]

Check how much RAM that server has. If it has enough, you could run that RDP system in a virtual machine on it.

Otherwise, either reuse an older PC, or if space is short, go for a small Quotom PC.

RMerlin, I like the NUC range of tiny PC's, are the Quotom PC's at the same level of reliability as the Intel offerings?