[OpenVPN home] [Date Prev] [Date Index] [Date Next]
[OpenVPN mailing lists] [Thread Prev] [Thread Index] [Thread Next]
Web openvpn.net

[Openvpn-users] Re: OpenVPN Server Performance (real experience) and Virtual IP address managment

  • Subject: [Openvpn-users] Re: OpenVPN Server Performance (real experience) and Virtual IP address managment
  • From: Dale <d.schultz@xxxxxxxxxx>
  • Date: Wed, 22 Feb 2006 01:47:58 +0000 (UTC)

Jon Bendtsen <jon.bendtsen <at> laerdal.dk> writes:

> > - 3 LAN interfaces, 1 to the core LAN, 1 to a frame relay network  
> > and 1
> > (currently not used to the big bad Internet)
> How fast is a frame relay? Last time i used that it was 64k
We have a 128kbps.  Which at best will help throttle the incoming traffic.  
Unfortunetly not enough to releive the pressure on the CPU.  No packets were 
even leaving the server when it was swamped.

> The rest of your mail tells me that you use certificates and not  
> keys, 
Oops, yes Certs not keys

> > When we started implementing the network the population of remotes  
> > was low,
> > about 30.  In the server we are using the following IP related  
> > parameters to
> > keep the remote VPN IP addresses as static as possible:
> Why is it that you want static ip addresses? could DNS not be a possible
> solution?
> Besides that, if you really want a static ip address, consider using
> --client-config-dir and a file with the name of the common name from
> the certificate. This way you WILL have full control over what ip  
> address
> a client gets.
I'm not sure how I missed that option in the man page, but thanks for pointing 
it out.  We do use DNS.  It is mapped to the static IP that I want the remote 
to have.  There are *other* non-technical reasons for this and it has to do 
with people who don't understand how networks really work.
As an after thought, if I had the server trying to send Dynamic DNS updates to 
the DNS server, it would just be another load on the server at network startup 
that apparently I can't afford right now.

> > Some other server config options:
> > daemon
> > mssfix
> > fragment 1200
> Is this because of the frame relay ?
Man page suggestions and my own experience with apps frezzing when the MSS is 
not forced down to account for the additional overhead of the secure UDP 

> > keepalive 60 300
> > comp-lzo
> I found that this one adds considerably load to my server when i  
> transfer files.
We may be disabling lzo, but I have to touch all the client too and disable it 
there.  I tried setting the server off but then nothing connected.

> My guess is that the frame relay is filled, and thus the packets used  
> to authenticate
> the clients are not received in time, making the server start over  
> the auth.
> Besides what you did, consider using some of the suggestions in the  
> bottom of
> my mail.
The frame relay stats do not indicate full saturation.  They do show no 
traffic coming out of the CPU loaded server :-(

> [cuuuuuut]
> > So it would seem that (and Iâm not a programmer) that the openvpn
> > process/application needs to be multi-threaded to spawn off  
> > processes to
> > utilize more processors?  So along this line of thought, what about
> > artificially splitting the client load by running two openvpn  
> > daemons and set
> > each to a different UDP port bound to the same IP address and then  
> > split the
> > remote network in half (via IP subnet) and assign each subnet half  
> > to one of
> > the processes?  I have plans to test this theoryâmaybe next weekend.
> Good thinking. Yes the programs needs to be multithreaded to use more
> than one cpu, or you need to run multiple instances of openvpn. But that
> is rather easy to do. What not is so easy is using a static ip  
> address across
> multiple daemons, but it is not impossible.
> Which data are in the routing table?
The route table contains the route to the remotes via the tunnel.
The locally connected networks of course and the two internal LAN networks 
that the remotes need to reach via my core router.  It's the two internal ones 
that get trashed.  I suppose a default gateway would do the trick, but I'm not 
found of that idea, espeacially from a sever breach point of view.

> > 2)	openvpn has to be started after the BACKUP takes the MASTER role  
> > and
> > manages the virtual IP (VIP) address, until it is MASTER the VIP on  
> > the backup
> I see 3 possible solutions with different pro's and con's.
> 1. Solution:
> Using mostly one server, the central routers know which ip address
> to get to the outside clients, namely the inside of the openvpn server.
> The outside clients dont care, because they have multiple --remote
> entries in their client.conf, and will just try to connect.
> Once the server goes down, switch to the other server by letting the
> backup server takeover the ip address of the master server. And then
> bring up the openvpn daemon on the same machine.
> Cons:	lots of clients kills the openvpn server(s).
> 		all clients will have to reconnect
> 		one server bares all the load.
> Pro:		easy to setup openvpn
> 		tun and routing are efficient
This is my current mode, with manual backup server startup.

> 2. solution:
> Choosing tap and bridging should allow seamlessly switching from
> one openvpn server machine to another, because the inside routers
> will just send out packets to another machine on the local LAN. They
> will just do an ARP request who has 10.101.x.y and there should be
> a reply. (i dont have any bridging experience). This should even allow
> you to run both openvpn servers actively at the same time, making it
> load balancing.
> Cons:	tap and bridging are not as efficient as tun and routing
> 		Which MAC address will be in the reply to a ARP request?
> 		the one from the ethernet card in the openvpn server, or
> 		an individual from the real client?
> Pro:		half of the clients will have to reconnect if one server dies
> 		easy routing?
Definitely easy to setup and may be the end solution, even though it is less 

> 3. solution:
> advanced routing using various routing protocols. There are alot of
> protocols	http://en.wikipedia.org/wiki/Routing		has IGRP,
> But basically the idea was that when a client has connected to a
> openvpn server, something simply just tells the central router how
> packets should be routed pr. client.
> Cons:	big routing tables
> pro:		easy openvpn configuration
> 		tun and routing are efficient
> 		can use multiply openvpn servers simultainly
I had nightmares about this setup so I didn't even try to go this route.  The 
problem is the route to the tunnel is active even if there are no remotes on 
the server, if openvpn is running.

> > UCARP:
> Does ucarp support udp? because ssh is TCP, and ping icmp, and icmp
> does always need to work, so maybe the scrapped UDP support?
Well that's a good question.  I'm pretty sure that I tested SNMP queries 
against the VIP address and had no issues with that.  I'll need to double 
check that.

> > So this is my long sad tail, send tissues toâ   
> It is a good read, i have written some more suggestions to options  
> that might
> be usefull for you. Take a look at them in the manpage.
> --tls-auth
> --persist-remote-ip
> --fast-io
> --ccd-exclusive
> --bcast-buffers n
> --tcp-queue-limit n
> --max-clients n
> --reneg-bytes n
> --reneg-pkts n
> --reneg-sec n
> --hand-window n
> --tran-window n
> --sndbuf size
> --rcvbuf size
> --txqueuelen n
> --tls-timeout n
> --shaper n
> 	notice that --shaper does not work on the server side, only the  
> client side.

I'll re-review them...there are so many, and some of the description are a 
little cryptic until you understand them all.  Good bedtime reading though ;-)
Thanks again.

> JonB

Openvpn-users mailing list