dhaval.thakar at networthdirect.com
2008-Dec-14 15:20 UTC
[CentOS] regarding vpn server for 1500 clients
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. Regards Dhaval
NiftyClusters T Mitchell
2008-Dec-17 08:37 UTC
[CentOS] regarding vpn server for 1500 clients
On Sun, Dec 14, 2008 at 7:20 AM, <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. >1500 clients at the same time is a lot and "No encryption necessary" sounds like a contradiction. OpenVPN should be as good as any vpn solution... and since it works for you benchmark it and plan on multiple servers as traffic performance measures indicate. It is possible that dedicated Cisco hardware solutions will scale better. At a minimum they can set a cost base line to validate the value of your Linux solution. Management of clients needs to be expanded. Point-to-point tunneling protocol does not make sense based on your email address. -- NiftyCluster T o m M i t c h e l l
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.
Ray Van Dolson wrote:> On Fri, Dec 19, 2008 at 03:42:08PM +0000, Karanbir Singh wrote: > >> Rainer Duffner wrote: >> >>>> 1500 clients is quite a lot, but not hard to handle from a single >>>> machine if you select a cpu capable of doing ssl quickly. eg a power6 >>>> machine with a few cores would handle that without any problems. >>>> >>> And what is the suggested RRP of such a thing? >>> (If one may ask). >>> >> I am sure if you ask someone who sells them, they will tell you :D >> >> >>>> If you want to stick with commodity hardware, a couple of quad core >>>> amd's should also fit right in. >>>> >>> Or use an SSL-offloader. >>> Then, you can handle the same load with much less CPU-power. >>> >> Can get fiddly, with specific drivers and patches required to various >> bits.. But thats a solution that could work too. >> >> > > To OP; anecdotal evidence only -- and I certainly wouldn't recommend > using PPTP for a secure VPN solution :)The OP did not want security, only tunneling. His desire. Definitely not mine. My work for the last 14 years has been to make communication on the Internet unassailable, at least along the data path (I make no attempts with the OS or apps). I would like to see ALL communications be encrypted. D*MN the torpedos!> At my previous job we ran > PoPToP (PPTP) on CentOS and the older HP DL140 G1 1U servers and were > handling up to 1000 clients pretty comfortably per machine. This was > with 1GB of RAM per server and a single 2.4GHz Xeon processor. >I have heard of similar numbers.> Left before we could migrate to OpenVPN which I think would have > slightly higher processing requirements. :)Sure would have!
John R Pierce wrote:> Robert Moskowitz wrote: > >> The OP did not want security, only tunneling. >> > > use simple PPPoE perhaps? >PPPoE does not have good behaviour over the broader Internet. Works find for the last mile.> I still think I'd recommend Juniper SSLVPN appliance hardware however. >The CTO over there is an old friend of mine....> one of their midsized boxes can easily handle 1000s of sessions at wire > speeds up to 100baseT at the server side, and has really good > managability. if these clients are in fact field offices, I'd instead > use one of their ipsec hardware appliances (such as whatever has > replaced the Netscreen 208) and put the baby version (netscreen 5xl) at > each site so its LAN to WAN connectivity, transparent to all clients.. > > 1500 clients connected to this server, I do hope they are going to have > a high speed symmetric internet connection... even 128kbps per user > and half the users active, thast still 10 megabit symmetric pretty much > saturated.
How about lots of GRE tunnels? :-) Ray
William Warren wrote:> Robert Moskowitz wrote: > >> Ray Van Dolson wrote: >> >> >>> On Fri, Dec 19, 2008 at 03:42:08PM +0000, Karanbir Singh wrote: >>> >>> >>> >>>> Rainer Duffner wrote: >>>> >>>> >>>> >>>>>> 1500 clients is quite a lot, but not hard to handle from a single >>>>>> machine if you select a cpu capable of doing ssl quickly. eg a power6 >>>>>> machine with a few cores would handle that without any problems. >>>>>> >>>>>> >>>>>> >>>>> And what is the suggested RRP of such a thing? >>>>> (If one may ask). >>>>> >>>>> >>>>> >>>> I am sure if you ask someone who sells them, they will tell you :D >>>> >>>> >>>> >>>> >>>>>> If you want to stick with commodity hardware, a couple of quad core >>>>>> amd's should also fit right in. >>>>>> >>>>>> >>>>>> >>>>> Or use an SSL-offloader. >>>>> Then, you can handle the same load with much less CPU-power. >>>>> >>>>> >>>>> >>>> Can get fiddly, with specific drivers and patches required to various >>>> bits.. But thats a solution that could work too. >>>> >>>> >>>> >>>> >>> To OP; anecdotal evidence only -- and I certainly wouldn't recommend >>> using PPTP for a secure VPN solution :) >>> >>> >> The OP did not want security, only tunneling. His desire. Definitely not >> mine. My work for the last 14 years has been to make communication on >> the Internet unassailable, at least along the data path (I make no >> attempts with the OS or apps). >> >> I would like to see ALL communications be encrypted. D*MN the torpedos! >> >> >> >>> At my previous job we ran >>> PoPToP (PPTP) on CentOS and the older HP DL140 G1 1U servers and were >>> handling up to 1000 clients pretty comfortably per machine. This was >>> with 1GB of RAM per server and a single 2.4GHz Xeon processor. >>> >>> >>> >> I have heard of similar numbers. >> >> >> >>> Left before we could migrate to OpenVPN which I think would have >>> slightly higher processing requirements. :) >>> >>> >> Sure would have! >> >> >> _______________________________________________ >> CentOS mailing list >> CentOS at centos.org >> http://lists.centos.org/mailman/listinfo/centos >> >> >> > openvpn doesn't hit a modern cpu that hard anymore(unless you dialup > something higher than 128 bit). I routinely do 5-10 users an sub 1ghz > machines with openvpn. Leave the encryption in place..it's not going to > make a huge difference.Like I said, it is the setup that is the killer. If the users all come on within a short time frame, they can fail. 5-10 users is nothing. D-H, and RSA are killers for CPUs. ECC can be too, it depends on which curve and whos code (some of it patented).
Dhaval Thakar wrote:>> If you could use a lower CPU intensive crypt like blowfish, it would be easier. >> >> Are all these trading partners in different locations or are there semi large >> groups in the same locations? >> > all these are end users. > they connect software from home / offices.Do they actually need a generic VPN? If they only run a few applications you might be able to use https or similar ssl based connections and avoid the routing/addressing/MTU issues. You can still use certificate based authentication in one or both directions if you want. Also if the application(s) can be made to run over normal https (i.e. a web interface) you get the advantage of working though most existing proxies and firewalls, plus on the host end you have the option of scaling up with a load balancer that handles the ssl processing and reverse-proxies to a pool of backend servers. -- Les Mikesell lesmikesell at gmail.com
> -----Original Message----- > From: centos-bounces at centos.org > [mailto:centos-bounces at centos.org] On Behalf Of Les Mikesell > Sent: Saturday, December 20, 2008 1:20 PM > To: CentOS mailing list > Subject: Re: [CentOS] regarding vpn server for 1500 clients > > Dhaval Thakar wrote: > >> If you could use a lower CPU intensive crypt like > blowfish, it would be easier. > >> > >> Are all these trading partners in different locations or > are there semi large > >> groups in the same locations? > >> > > all these are end users. > > they connect software from home / offices. > > Do they actually need a generic VPN? If they only run a few > applications you might be able to use https or similar ssl based > connections and avoid the routing/addressing/MTU issues. You > can still > use certificate based authentication in one or both > directions if you want. > > Also if the application(s) can be made to run over normal > https (i.e. a > web interface) you get the advantage of working though most existing > proxies and firewalls, plus on the host end you have the option of > scaling up with a load balancer that handles the ssl processing and > reverse-proxies to a pool of backend servers.--------- Just out of my own curriosity have you gave the thought of using deadicated or virtual circuits for the VPN implimentation? Like Frame Relay or ATM? Are you passing off the connections to a secondairy network access server? Or how do you plan on rolling this out, configuration wise? JohnStanley
On Sat, Dec 20, 2008 at 10:50 AM, John <jses27 at gmail.com> wrote:> > Just out of my own curriosity have you gave the thought of using deadicatedWas that a freudian slip? :-) mhr
> -----Original Message----- > From: centos-bounces at centos.org > [mailto:centos-bounces at centos.org] On Behalf Of MHR > Sent: Saturday, December 20, 2008 6:33 PM > To: CentOS mailing list > Subject: Re: [CentOS] regarding vpn server for 1500 clients > > On Sat, Dec 20, 2008 at 10:50 AM, John <jses27 at gmail.com> wrote: > > > > Just out of my own curriosity have you gave the thought of > using deadicated > > Was that a freudian slip? > > :-) > > mhrThinking in one place typing in another. I need a dictionary! JohnStanley
John wrote:>> -----Original Message----- >> From: centos-bounces at centos.org >> [mailto:centos-bounces at centos.org] On Behalf Of Les Mikesell >> Sent: Saturday, December 20, 2008 1:20 PM >> To: CentOS mailing list >> Subject: Re: [CentOS] regarding vpn server for 1500 clients >> >> Dhaval Thakar wrote: >> >>>> If you could use a lower CPU intensive crypt like >>>> >> blowfish, it would be easier. >> >>>> Are all these trading partners in different locations or >>>> >> are there semi large >> >>>> groups in the same locations? >>>> >>>> >>> all these are end users. >>> they connect software from home / offices. >>> >> Do they actually need a generic VPN? If they only run a few >> applications you might be able to use https or similar ssl based >> connections and avoid the routing/addressing/MTU issues. You >> can still >> use certificate based authentication in one or both >> directions if you want. >> >> Also if the application(s) can be made to run over normal >> https (i.e. a >> web interface) you get the advantage of working though most existing >> proxies and firewalls, plus on the host end you have the option of >> scaling up with a load balancer that handles the ssl processing and >> reverse-proxies to a pool of backend servers. >> > --------- > Just out of my own curriosity have you gave the thought of using deadicated > or virtual circuits for the VPN implimentation? Like Frame Relay or ATM? Are > you passing off the connections to a secondairy network access server? Or > how do you plan on rolling this out, configuration wise? >have you and FR or ATM rollout experience? Mine is 15 years old and it was NOT for end user applications. Small offices was hard enough.
> Dhaval Thakar wrote: >>> If you could use a lower CPU intensive crypt like blowfish, it would be >>> easier. >>> >>> Are all these trading partners in different locations or are there semi >>> large >>> groups in the same locations? >>> >> all these are end users. >> they connect software from home / offices. > > Do they actually need a generic VPN? If they only run a few > applications you might be able to use https or similar ssl based > connections and avoid the routing/addressing/MTU issues. You can still > use certificate based authentication in one or both directions if you > want. > > Also if the application(s) can be made to run over normal https (i.e. a > web interface) you get the advantage of working though most existing > proxies and firewalls, plus on the host end you have the option of > scaling up with a load balancer that handles the ssl processing and > reverse-proxies to a pool of backend servers.they need database access. I prefre providing database over vpn rather providing via internet on different tcp port.
> Just out of my own curriosity have you gave the thought of using > deadicated > or virtual circuits for the VPN implimentation? Like Frame Relay or ATM? > Are > you passing off the connections to a secondairy network access server? Or > how do you plan on rolling this out, configuration wise? >user will connect vpn using isp leased line. vpn server in dmz. application server is in inside network. no planing for atm / frame relay.
On Sun, Dec 14, 2008 at 9:20 AM, <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. > > > > Regards > Dhaval > > > > > _______________________________________________ > CentOS mailing list > CentOS at centos.org > http://lists.centos.org/mailman/listinfo/centos >The open source tinc-vpn which is like Hamachi. Could use a tun / tap layer with 5.0.0.0/8 addresses. Would never recommend PPTP because of the security issues and the clients can't have the same subnet as the corporate lan for it to work well. Even if you do not need encryption, but just authentication, pptp could be blown wide open.
> 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.Have you looked at Mikrotik.com router OS? It has PPTP server. Very fast and easy to setup.
Bernard 'Tux' Lheureux wrote:> Matt wrote: > >>> I have to build vpn server for 1500 clients. No encryption necessary. >>> can anyone please recommend me vpn server. >>> >>> Have you looked at Mikrotik.com router OS? It has PPTP server. Very >>> fast and easy to setup >>> > But PPTP is very weak in terms of security... > IPsec or SSL VPNs should be used to ensure security on the VPN connectionsThe OP did not want per packet encryption. Did not even want per packet authentication. Just tunneling. ERGO something like PPTP. Of course if the Linux implementation of the PPTP server is so ineffcient (written in PERL), that you have to buy a PPTP server, now you have to compare it to an IPsec or SSLVPN server. I have never liked the SSLvpn architecture. Never really liked the SSL handshake; just too chatty. I wear my biases quite plainly on my arm sleeve (I chaired the IPsec workgroup during the time the RFCs came out). You want security, go with IPsec. Even ESP NULL gives you per packet authentication and thus proof of server and client. Just pay the price for IKE, which I never liked. Part of the reason I invented HIP.... Of course if the OP goes with an SSL application, and moves away from tunneling, then YES just go with SSL on the server and add an SSL acceleration board.
Robert Moskowitz wrote:> > I have never liked the SSLvpn architecture. Never really liked the SSL > handshake; just too chatty. I wear my biases quite plainly on my arm > sleeve (I chaired the IPsec workgroup during the time the RFCs came > out). You want security, go with IPsec. Even ESP NULL gives you per > packet authentication and thus proof of server and client. Just pay the > price for IKE, which I never liked. Part of the reason I invented HIP....But ssl vpns work though just about any firewall/proxy/nat that already permit https. Traversing those can be painful or impossible for ipsec. -- Les Mikesell lesmikesell at gmail.com
Les Mikesell wrote:> Robert Moskowitz wrote: > >> I have never liked the SSLvpn architecture. Never really liked the SSL >> handshake; just too chatty. I wear my biases quite plainly on my arm >> sleeve (I chaired the IPsec workgroup during the time the RFCs came >> out). You want security, go with IPsec. Even ESP NULL gives you per >> packet authentication and thus proof of server and client. Just pay the >> price for IKE, which I never liked. Part of the reason I invented HIP.... >> > > But ssl vpns work though just about any firewall/proxy/nat that already > permit https. Traversing those can be painful or impossible for ipsec.The problem is NATs (so speaks a co-author of RFC 1918!). SSL vpns tunnel networking over Transport. Gee I wonder why that works through NATs? Part of the NAT traversal mess contributed to my drive for HIP which the actual developers realized needed a different ESP mode: BEET. Of course even HIP needs ICE to find things out there and to be found....
Les Mikesell wrote:> Robert Moskowitz wrote: > >>>> I have never liked the SSLvpn architecture. Never really liked the SSL >>>> handshake; just too chatty. I wear my biases quite plainly on my arm >>>> sleeve (I chaired the IPsec workgroup during the time the RFCs came >>>> out). You want security, go with IPsec. Even ESP NULL gives you per >>>> packet authentication and thus proof of server and client. Just pay the >>>> price for IKE, which I never liked. Part of the reason I invented HIP.... >>>> >>>> >>> But ssl vpns work though just about any firewall/proxy/nat that already >>> permit https. Traversing those can be painful or impossible for ipsec. >>> >> The problem is NATs (so speaks a co-author of RFC 1918!). SSL vpns >> tunnel networking over Transport. Gee I wonder why that works through NATs? >> > > Or, given the near-universal use of NATs, you have to wonder about the > viability of anything that doesn't traverse them gracefully. > > >> Part of the NAT traversal mess contributed to my drive for HIP which the >> actual developers realized needed a different ESP mode: BEET. Of course >> even HIP needs ICE to find things out there and to be found.... >> > > I'm not sure what any of those acronyms means,For HIP (Host Identity Protocol) check out RFCs 4423 adn 5202 - 5207. For BEET (Bound End to End Transport), it is an Internet Draft: www.ietf.org/*internet*-*draft*s/*draft*-nikander-esp-*beet*-mode-09.txt ESP has challenges going through a NAT as the outer IP addresses of the tunnel are bound to the Security Association. With BEET, that is removed, the outer IP addresses are not used in calcuating the authentication. More differences than that, but in a nutshell... BEET is now part of the 2.6.27 kernel. I want to finish some testing then get a bug report into Redhat to get them to add it to the 2.6.18 kernel for RHEL/Centos 5.> but the other problem > with IPsec is that the usual tools don't provide an interface for > routing and they need some other mechanism to decide what goes through > them.This has always been my issue with IPsec tunnels. What to use and do you know if what you want secured is? Thus the policy always is all or nothing; very broken per the RFC. FreeSWAN tried doing it better, but kind of sputtered out (Hugh really wanted to do it right). This was thus another issue I had with tunnel mode over transport that led to BEET mode.> On Ciscos I've always set up GRE tunnels to get something the > routing protocols can see, then crypto-mapped the GRE packets. Is there > a common computer implementation that would mesh with this? >No. At least that I know of.