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
But if you're stuck with that
the phoneline often was still fine), but never go below 33.6K. Though the mice were annoying in causing a disconnect every half hour or so.