On Apr 21, 2011, at 12:55 32PM, Ben Whorwood wrote:
Dear all,
Can anyone share any thoughts or experiences for VPN links running over slow Internet connections, typically 2kB/s - 3kB/s (think 33.6k modem)?
We are looking into utilising OpenVPN for out-of-office workers who would be running mobile broadband in rural areas. Typical data across the wire would be SQL queries for custom applications and not much else.
Some initial thoughts include...
* How well would the connection handle certificate (>= 2048 bit key) based authentication?
You're doing this rarely; it shouldn't be a problem.
* Is UDP or TCP better considering the speed and possibility of packet loss (no figures to hand)?
For your application or for the VPN? For the VPN, I *strongly* suggest you use UDP, or you're going to get dueling retransmissions and spend a lot of time sending many copies of the same thing. Consider: if a packet is dropped, either due to line noise or queuing delay for the slow link, the sending TCP will resend. If you're using TCP for OpenVPN, that session's TCP will resend. Of course, the TCP running on top of it will resend as well, so you'll get two copies of the data sent to the application's TCP, wasting precious bandwidth. If, on the other hand, OpenVPN is running UDP, it won't resend; the application's TCP will, so you'll only get one copy. I should note: IPsec, being datagram-based, will also work well. PPTP, which runs over TCP as far as I know, will suffer all of the ills I just outlined. I'm assuming that your application is using TCP. Unless the data characteristics are such that you're able to fit every query and every response into a single packet, you'll spend more effort (and probably bandwidth) doing your own retransmissions, backoffs, segementation, etc.
* Is VPN over this type of connection simply a bad idea?
If you do it correctly, a VPN is actually better: you can assign a static internal IP address to each certificate. If the modem connection drops, when you reconnect the applications will still have the same IP address, so their connections won't be interrupted. You do have to watch out for queue limits -- as Jim Gettys has reminded us, many of today's queues are far too long, so we're not getting the very beneficial effects of early drop and consequent TCP slow-down. This will require tuning your end nodes OS and/or the router at your head end. Use active queue management (e.g., RED), and consider a priority queueing scheme. Watch out for other applications -- I've had trouble with MacOS's Mail.App on slow links; it's gotten very confused and more or less forgotten about my mail folders, with the consequent need to rebuild them, reactivate my sorting rules, etc. (Note that this paragraph applies whether or not you're using a VPN; it's the effect of a slow connection, not the crypto.) The real VPN question is what the overhead is. I've never calculated it for OpenVPN; I did for IPsec some years ago (long enough ago that IPsec was still using DES or 3DES because AES and its 16-byte blocksize didn't exist); using average packet size distribution, it came to (as I recall) about 12%. That's unlikely to make or break your system. However, there's no substitute for real data -- what do your packets look like? Fairly obviously, the shorter the packet, the higher the overhead percentage. Someone suggested trying it using a FreeBSD flakeway; that's a good idea. In short -- if your VPN is set up properly, any ill effects are much more likely to be from the link speed itself, not the VPN. --Steve Bellovin, https://www.cs.columbia.edu/~smb