| 1 |
Congestion isn't the only reason to use TCP and a VPN. |
| 2 |
|
| 3 |
3G smartphone network (Optus in Oz) has a large number of duplicate and dropped packets - openvpn performance over TCP is much better. Similar case with a cheap French network while on holiday there. This was an extreme case though with non VPN traffic very poor as well. |
| 4 |
|
| 5 |
Otherwise use openvpn with fqdn's and not IP numbers then use ospf across them with suitable route metrics to either share or prefer a route. Works well with dynamic IP's from my ISP so should be ok in your scenario. You could also use openvpns route push if you dont need complex dynamic routing - this works better than ospf on bad links anyway. |
| 6 |
|
| 7 |
BillK |
| 8 |
|
| 9 |
On 11/02/2012, at 2:36, Michael Orlitzky <michael@××××××××.com> wrote: |
| 10 |
|
| 11 |
> On 02/10/12 13:05, Pandu Poluan wrote: |
| 12 |
>> |
| 13 |
>> No, no, no. What I meant was running TCP and UDP *on top of* OpenVPN |
| 14 |
>> (which uses UDP). |
| 15 |
>> |
| 16 |
>> HAproxy seems to be able to perform its magic with TCP connections. |
| 17 |
>> |
| 18 |
> |
| 19 |
> I was about to say that we use it over UDP, but... we don't. We have a |
| 20 |
> small number of clients, maybe ten(?) that use the VPN for remote |
| 21 |
> administration. |
| 22 |
> |
| 23 |
> UDP is recommended, references[1] are easy to google. Why we're running |
| 24 |
> it over TCP I don't know. I must have had a good reason =) |
| 25 |
> |
| 26 |
> It performs fine anyway, but now I'm considering flipping it to UDP to |
| 27 |
> see what happens. At least I'll be in the office when it breaks. |
| 28 |
> |
| 29 |
> |
| 30 |
> |
| 31 |
> [1] http://sites.inka.de/sites/bigred/devel/tcp-tcp.html |
| 32 |
> |
Archives