[CentOS] regarding vpn server for 1500 clients

[Robert Moskowitz]

DISCLAIMER:

I work for ICSAlabs, an Independent Division of Verizon Business 
Systems. We are the UL of security product testing.

I co-chaired the IPsec work in the IETF back in the late '90s.

I am the creator of the HIP protocol.

I have lots of standards experience, lots of testing experience, and 
limited deployment experience.

The following IS NOT the position of my employer. I just benefit from a 
lot of help on this list, and rarely can give back....

dhaval.thakar at networthdirect.com wrote:
> Hi list,
>
>
> I have to build vpn server for 1500 clients. No encryption necessary.
> can anyone please recommend me vpn server.
>
> I do not have experience on vpn.
>
> I have tested openvpn on my test setup, & its working fine.
>
> I want to check if there any other vpn server available.
> I have not checked but can pptp vpn be usefull?
>
>
> My requirement is to connect 1500 clients on vpn server.
> Need frontend to manage vpn clients.

I am going to recommend PPTP to you, the reason is low setup cost and 
the encryption stinks (and thus does not cost much CPU).

You see even if you run IPsec with ESP NULL (RFC 2510, read it for all 
the US-centric jokes we stuffed in it), you have to pay for IKE and 
actually the session handshake can be more the killer for a VPN server 
than the actual per-packet-encryption. Why? Becuase to do ANY decent VPN 
protocol that has encyrption available, the handshake MUST use 
asymmetric (ie public-key) encryption. At least Diffie-Hellman, perhaps 
some RSA or ECC thrown in there. Oh, 802.11i Four-Way-Handshake DOES 
avoid this when running with a pre-shared key (OUCH, I wrote the paper 
on the attack on that after I helped develop the protocol including all 
of its compromises).

So every morning when those 1500 users log in, you eat dust while all 
the public-key work goes on. Without hardware to do the work, your 
server just dies. I don't care if your run IPsec, SSLvpn, HIP, or SSH, 
you will have public key crypto running for the handshake. The actual 
cost of AES in a counter-mode operation (like CCMP that was created for 
802.11i, or GCM that was created for 802.1AE) is actually quite 
reasonable. And if you run RC4 with SSLvpns, boy are you running a low 
overhead (and easy to attack) cipher.


But PPTP????

Microsoft invented it to get connected and of course no one would bother 
to attack it... So the handshake is really light weight and won't kill 
your server.

There are variants of PPTP (eg L2PPTP) that have some real crypto in 
them in an attempt to fix what was broken, but then Microsoft got the 
'religion' and went full throttle with IPsec, and did a decent job of 
it. So decent in fact that many corporations turn it OFF becuase they 
can't do internal traffic shaping when all the Microsoft traffic is 
running in ESP!


So to conclude.

Find a tunnelling protocol that has a CHEAP setup cost, like PPTP. This 
can be a bigger deal breaker than the actual tunnel encryption method.