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
On Sun, Dec 14, 2008 at 7:20 AM, dhaval.thakar@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.
NiftyClusters T Mitchell wrote
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.
for large scale VPN networks like that, I'd evalulate the Juniper/Netscreen stuff before I'd go Cisco.
John R Pierce wrote:
NiftyClusters T Mitchell wrote
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.
for large scale VPN networks like that, I'd evalulate the Juniper/Netscreen stuff before I'd go Cisco.
Ah yeah? Could you tell us why you'd go Juniper before Cisco?
Not that i don't like Juniper, i'm just curious about the reason(s) you said that.
Guy Boisvert, ing. IngTegration inc.
_______________________________________________________________ Pre-Boxing Day Domain Sales: Hosting + Domain = US$4.95/year Offer Ends: Dec 31, 2008. http://www.doteasypromo.com
On 2008-12-17, 08:37 GMT, NiftyClusters T Mitchell wrote:
It is possible that dedicated Cisco hardware solutions will scale better.
Your mileage may vary, but I have terrible experience with Linux Cisco VPN clients, so I would strongly suggest OpenVPN. Of course, I don't know anything about needs for so huge installation etc. -- the only I have is very bad experience with Cisco VPN as its user.
Matěj
Matej Cepl wrote:
On 2008-12-17, 08:37 GMT, NiftyClusters T Mitchell wrote:
It is possible that dedicated Cisco hardware solutions will scale better.
Your mileage may vary, but I have terrible experience with Linux Cisco VPN clients, so I would strongly suggest OpenVPN. Of course, I don't know anything about needs for so huge installation etc. -- the only I have is very bad experience with Cisco VPN as its user.
thanks for the reply. I need vpn server to provide software connectivity to the clients. This is trading software.
I have installed & used OpenVpn on my test setup. It is working fine.
I prefer non-encryption vpn. If I use openvpn, it will require more processing power than poptop. I guess creating backup server might become difficult as it works on ssl cert. cert created on server1 might not work with server2. Whereas in poptop I need to copy single file (chap-secrets).
I am trying testing poptop, if there any better vpn server available kindly let me know.
Dhaval Thakar wrote:
I prefer non-encryption vpn. If I use openvpn, it will require more processing power than poptop. I guess creating backup server might become difficult as it works on ssl cert. cert created on server1 might not work with server2. Whereas in poptop I need to copy single file (chap-secrets).
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.
If you want to stick with commodity hardware, a couple of quad core amd's should also fit right in.
- KB
Karanbir Singh schrieb:
Dhaval Thakar wrote:
I prefer non-encryption vpn. If I use openvpn, it will require more processing power than poptop. I guess creating backup server might become difficult as it works on ssl cert. cert created on server1 might not work with server2. Whereas in poptop I need to copy single file (chap-secrets).
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).
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. Though, the throughput you need with 1500 users will already mandate a pretty beefy server - at least concerning I/O. Soekris, WRAP and Alix need not apply, I'm afraid....
Rainer
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.
- KB
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 :) 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.
Left before we could migrate to OpenVPN which I think would have slightly higher processing requirements. :)
Ray
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!
Robert Moskowitz wrote:
The OP did not want security, only tunneling.
use simple PPPoE perhaps?
I still think I'd recommend Juniper SSLVPN appliance hardware however. 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.
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.
Ray Van Dolson wrote:
How about lots of GRE tunnels? :-)
I've done that with a few connections - mostly connecting to Cisco routers to pass multicast streams. I'm not sure how it would scale up in terms of the interface numbers and managing routes but it should work.
Les Mikesell wrote:
Ray Van Dolson wrote:
How about lots of GRE tunnels? :-)
I've done that with a few connections - mostly connecting to Cisco routers to pass multicast streams. I'm not sure how it would scale up in terms of the interface numbers and managing routes but it should work.
What was the network environment like that the tunnels went over?
Robert Moskowitz wrote:
How about lots of GRE tunnels? :-)
I've done that with a few connections - mostly connecting to Cisco routers to pass multicast streams. I'm not sure how it would scale up in terms of the interface numbers and managing routes but it should work.
What was the network environment like that the tunnels went over?
Some over the internet, some private, but always with fixed src/dest addresses and nothing going over them that couldn't have run unencrypted over the internet.
on 12-19-2008 10:33 AM Les Mikesell spake the following:
Robert Moskowitz wrote:
How about lots of GRE tunnels? :-)
I've done that with a few connections - mostly connecting to Cisco routers to pass multicast streams. I'm not sure how it would scale up in terms of the interface numbers and managing routes but it should work.
What was the network environment like that the tunnels went over?
Some over the internet, some private, but always with fixed src/dest addresses and nothing going over them that couldn't have run unencrypted over the internet.
If it doesn't need to be encrypted, then why do you need tunnels?
Couldn't you just set a route on the remote machines and use that? Could be as simple as a batch file/shell script.
Scott Silva wrote:
How about lots of GRE tunnels? :-)
I've done that with a few connections - mostly connecting to Cisco routers to pass multicast streams. I'm not sure how it would scale up in terms of the interface numbers and managing routes but it should work.
What was the network environment like that the tunnels went over?
Some over the internet, some private, but always with fixed src/dest addresses and nothing going over them that couldn't have run unencrypted over the internet.
If it doesn't need to be encrypted, then why do you need tunnels?
There are two reasons.
Couldn't you just set a route on the remote machines and use that? Could be as simple as a batch file/shell script.
One reason is that I was distributing multicast with a Cisco router doing the fanout. With a tunnel, you put multicast in one end and it comes out the other even if the intermediate path doesn't handle multicast. The other is that the end points all had private addressing which the terminating equipment understood but not the intermediate routers.
Les Mikesell wrote:
Robert Moskowitz wrote:
How about lots of GRE tunnels? :-)
I've done that with a few connections - mostly connecting to Cisco routers to pass multicast streams. I'm not sure how it would scale up in terms of the interface numbers and managing routes but it should work.
What was the network environment like that the tunnels went over?
Some over the internet, some private, but always with fixed src/dest addresses and nothing going over them that couldn't have run unencrypted over the internet.
RED (Random Early Discard) was specifically developed and deployed to break flows that lacked congestion control. CeeUceeME was the big culprit at the time. Multicast streams could have a lot of data lose if RED is needed to manage congestion.
Robert Moskowitz wrote:
How about lots of GRE tunnels? :-)
I've done that with a few connections - mostly connecting to Cisco routers to pass multicast streams. I'm not sure how it would scale up in terms of the interface numbers and managing routes but it should work.
What was the network environment like that the tunnels went over?
Some over the internet, some private, but always with fixed src/dest addresses and nothing going over them that couldn't have run unencrypted over the internet.
RED (Random Early Discard) was specifically developed and deployed to break flows that lacked congestion control. CeeUceeME was the big culprit at the time. Multicast streams could have a lot of data lose if RED is needed to manage congestion.
Where would this happen - and would it happen to the encapsulating GRE packets or just bare udp multicast?
Les Mikesell wrote:
Robert Moskowitz wrote:
How about lots of GRE tunnels? :-)
I've done that with a few connections - mostly connecting to Cisco routers to pass multicast streams. I'm not sure how it would scale up in terms of the interface numbers and managing routes but it should work.
What was the network environment like that the tunnels went over?
Some over the internet, some private, but always with fixed src/dest addresses and nothing going over them that couldn't have run unencrypted over the internet.
RED (Random Early Discard) was specifically developed and deployed to break flows that lacked congestion control. CeeUceeME was the big culprit at the time. Multicast streams could have a lot of data lose if RED is needed to manage congestion.
Where would this happen - and would it happen to the encapsulating GRE packets or just bare udp multicast?
Any router could employ RED in a congestion situation. The buffer reaches n% full and m randomly selected packets in the buffer are silently dropped. The buffer is compressed and the router gets on with its life. This is better than the router stopping receiving incoming packets until its buffer empties a bit.
A protocol that has flow control, like TCP will deal with the packet loss. A couple packets will not disrupt an audio stream. But if the protocol is going gangbusters and just tossing out packets as fast as it can, then it could have a LOT of packets tossed out at the congested router, and BAM, the protocol breaks.
Back when Tony Li coded it for the backbone Cisco routers and it was deployed overnight with no testing (those were the Internet days), the CeeUceeMe programmers over at CMU refused to implement any flow control. It had gotten so bad, that the EU nets were ready to put a block on its protocol number. Then someone thought up RED, Tony coded it up, and all those CeeUCeeMe streams broke. The programmers at CMU finally got it....
A little Internet history there.....
So any UDP protocol that does not implement flow control can suffer big time. On a SIP call, you might see it as your voice breaking up like a cell call in a 'bad' area. Or with video it could be an image freeze.
GRE just sometimes would mess up a protocol's reaction to congestion that it was a worst response. Of course, this was 10 years ago, and lots of apps are much smarter. But some programmers still develop on a local LAN and expect to see the same dynamics on the broader Internet....
Ray Van Dolson wrote:
How about lots of GRE tunnels? :-)
RED can kill GRE tunnels over the net. Depends on the protocol they carry. If it is all TCP, you see a lot of slowstart. Of course if their path is free of congestion, then no RED.
Plus there is a lot of configuration for GRE, and most platforms come with 'managed' tunneling like IPsec, SSLvpn, PPTP.
On Fri, Dec 19, 2008 at 12:49:08PM -0500, Robert Moskowitz wrote:
Ray Van Dolson wrote:
How about lots of GRE tunnels? :-)
RED can kill GRE tunnels over the net. Depends on the protocol they carry. If it is all TCP, you see a lot of slowstart. Of course if their path is free of congestion, then no RED.
Plus there is a lot of configuration for GRE, and most platforms come with 'managed' tunneling like IPsec, SSLvpn, PPTP.
Yeah you'd definitely have to do some coding to make it manageable. They always came in 'handy' but sounds like PPTP might be the way to go for this particular question anyways.
PoPToP is rock solid in my experience and the maintainer is very responsive and helpful (James Cameron).
Ray
Ray Van Dolson wrote:
On Fri, Dec 19, 2008 at 12:49:08PM -0500, Robert Moskowitz wrote:
Ray Van Dolson wrote:
How about lots of GRE tunnels? :-)
RED can kill GRE tunnels over the net. Depends on the protocol they carry. If it is all TCP, you see a lot of slowstart. Of course if their path is free of congestion, then no RED.
Plus there is a lot of configuration for GRE, and most platforms come with 'managed' tunneling like IPsec, SSLvpn, PPTP.
Yeah you'd definitely have to do some coding to make it manageable. They always came in 'handy' but sounds like PPTP might be the way to go for this particular question anyways.
PoPToP is rock solid in my experience and the maintainer is very responsive and helpful (James Cameron).
same Cameron that maintains webmin?
And for your Windos clients the maintainer is pretty good too. Not so responsive, but they pretty much have a stable platform.... :)
On Fri, Dec 19, 2008 at 01:11:29PM -0500, Robert Moskowitz wrote:
Ray Van Dolson wrote:
On Fri, Dec 19, 2008 at 12:49:08PM -0500, Robert Moskowitz wrote:
Ray Van Dolson wrote:
How about lots of GRE tunnels? :-)
RED can kill GRE tunnels over the net. Depends on the protocol they carry. If it is all TCP, you see a lot of slowstart. Of course if their path is free of congestion, then no RED.
Plus there is a lot of configuration for GRE, and most platforms come with 'managed' tunneling like IPsec, SSLvpn, PPTP.
Yeah you'd definitely have to do some coding to make it manageable. They always came in 'handy' but sounds like PPTP might be the way to go for this particular question anyways.
PoPToP is rock solid in my experience and the maintainer is very responsive and helpful (James Cameron).
same Cameron that maintains webmin?
And for your Windos clients the maintainer is pretty good too. Not so responsive, but they pretty much have a stable platform.... :)
Hmm, not sure. He's from down under and works for HP (last time I checked).
Ray
On Dec 19, 2008, at 12:20 PM, Ray Van Dolson rayvd@bludgeon.org wrote:
How about lots of GRE tunnels? :-)
Well PPTP is PPP over GRE, so that's basically it.
PPTP can run without encryption too if the OP really doesn't care about encryption.
-Ross
On Fri, Dec 19, 2008 at 01:14:34PM -0500, Ross Walker wrote:
On Dec 19, 2008, at 12:20 PM, Ray Van Dolson rayvd@bludgeon.org wrote:
How about lots of GRE tunnels? :-)
Well PPTP is PPP over GRE, so that's basically it.
PPTP can run without encryption too if the OP really doesn't care about encryption.
The only thing I'll say in the world of using PPTP (via PoPToP) is to consider what happens when most or all of your clients reconnect at one time (network glitch, etc). This was my biggest challenge as the original configuration had PPP calling all sorts of perl scripts and such from its ip-up mechanism. The server would come to a complete crawl as 800+ of these ip-up scripts would fire off along with their associated tasks. This would result in clients timing out, links failing, etc -- the server could never "catch up".
The band-aid solution was to rate limit SYN packets that established the connection... the permanent solution was to write a plugin for PPPd in C that replaced most of the ip-up functionality with something a bit more efficient.
As long as you're not needing to do any sort of complex post login tasks for each user, this may not even end up being an issue. But something to keep in mind and plan for if you're talking 1500 users... :)
Ray
Ray Van Dolson wrote:
On Fri, Dec 19, 2008 at 01:14:34PM -0500, Ross Walker wrote:
On Dec 19, 2008, at 12:20 PM, Ray Van Dolson rayvd@bludgeon.org wrote:
How about lots of GRE tunnels? :-)
Well PPTP is PPP over GRE, so that's basically it.
PPTP can run without encryption too if the OP really doesn't care about encryption.
The only thing I'll say in the world of using PPTP (via PoPToP) is to consider what happens when most or all of your clients reconnect at one time (network glitch, etc). This was my biggest challenge as the original configuration had PPP calling all sorts of perl scripts and such from its ip-up mechanism. The server would come to a complete crawl as 800+ of these ip-up scripts would fire off along with their associated tasks. This would result in clients timing out, links failing, etc -- the server could never "catch up".
I was recommending it based on the protocol. I did mention that I have limited deployment experience.
OUCH. All that perl could really kill the user experience.....
Almost as bad as a D-H exponentiation!
The band-aid solution was to rate limit SYN packets that established the connection... the permanent solution was to write a plugin for PPPd in C that replaced most of the ip-up functionality with something a bit more efficient.
As long as you're not needing to do any sort of complex post login tasks for each user, this may not even end up being an issue. But something to keep in mind and plan for if you're talking 1500 users... :)
Ray _______________________________________________ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
On Fri, Dec 19, 2008 at 01:54:32PM -0500, Robert Moskowitz wrote:
Ray Van Dolson wrote:
On Fri, Dec 19, 2008 at 01:14:34PM -0500, Ross Walker wrote:
On Dec 19, 2008, at 12:20 PM, Ray Van Dolson rayvd@bludgeon.org wrote:
How about lots of GRE tunnels? :-)
Well PPTP is PPP over GRE, so that's basically it.
PPTP can run without encryption too if the OP really doesn't care about encryption.
The only thing I'll say in the world of using PPTP (via PoPToP) is to consider what happens when most or all of your clients reconnect at one time (network glitch, etc). This was my biggest challenge as the original configuration had PPP calling all sorts of perl scripts and such from its ip-up mechanism. The server would come to a complete crawl as 800+ of these ip-up scripts would fire off along with their associated tasks. This would result in clients timing out, links failing, etc -- the server could never "catch up".
I was recommending it based on the protocol. I did mention that I have limited deployment experience.
OUCH. All that perl could really kill the user experience.....
Almost as bad as a D-H exponentiation!
It gets even worse... whoever had set up the system first didn't now how to get the IP address correctly from a variable in the ip-up script. So what'd they do? They called grep on /var/log/messages to look for it.
You can imagine the fun this created.... :-)
On Fri, Dec 19, 2008 at 11:41 AM, John R Pierce pierce@hogranch.com wrote:
I still think I'd recommend Juniper SSLVPN appliance hardware however. 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
I was an end user of a Juniper SSLVPN appliance, and so were 1000's of my colleagues. I would definitely recommend doing their own verification of how many sessions these appliances require. I know my organization had to add a lot more appliances to get performance up to what they consider an acceptable speed. What they consider acceptable speed is not wire speed for many US broadband users.
I don't know what the exact numbers are, but I suspect they can handle closer to 100's of sessions than 1000's of sessions.
Sorry for going off-topic.
Mike
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@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.
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@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).
on 12-19-2008 7:49 AM Ray Van Dolson spake the following:
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 :) 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.
Left before we could migrate to OpenVPN which I think would have slightly higher processing requirements. :)
Ray
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? Maybe a hundred or so share an office, you could set up IPSec tunnels to each remote office and pass all 100 through that tunnel. It takes a lot less CPU to pass 100 combined then 100 separate connections.
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.
Maybe a hundred or so share an office, you could set up IPSec tunnels to each remote office and pass all 100 through that tunnel. It takes a lot less CPU to pass 100 combined then 100 separate connections.
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.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@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@gmail.com wrote:
Just out of my own curriosity have you gave the thought of using deadicated
Was that a freudian slip?
:-)
mhr
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@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@gmail.com wrote:
Just out of my own curriosity have you gave the thought of
using deadicated
Was that a freudian slip?
:-)
mhr
Thinking in one place typing in another. I need a dictionary!
JohnStanley
John wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@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.
On Sat, Dec 20, 2008 at 6:59 PM, Robert Moskowitz rgm@htt-consult.com wrote:
John wrote:
-----Original Message----- 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?
Since this is MONEY do not skimp on security in the design (including audit design).
Design it so you have the ability to change encryption prompt;y and to change out hardware and software at both ends.
In part a VPN into a machine room can establish links to a dedicated network inside of a machine room that can have different security.
In your design recall that a VPN extends your network out to boxes that you have little control over in numerous locations and viruses or other security breach way out there is now 'inside'. i.e. It is tempting to think that VPN provides access to a network where you have physical control of security via the hardware (switches and cables).
If this is an international operation verify that you do not cause yourself legal issues with 'illegal' encryption as you cross national borders.
You clearly will be under pressure to get it 'live' which is OK as long as you get to clean it up as needed. Simple things like +2048 bit keys can be reduced to 1024 if the CPU load is is mismatched because hardware failed. The reverse may prove intractable should you need to turn up or change security should the site come under targeted or random Cyber attack.
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 12-20-2008 11:52 PM Dhaval Thakar spake the following:
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.
I still think this would be best served with a web based application. The database connections could stay local to the web server and cut the bandwidth requirements and be more secure. The web apps would easily run over SSL and be secure and happy. The upfront work would be easily offset by not having to have the equivalent of a fractional DS3 connection to the internet.
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.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Dhaval Thakar Sent: Sunday, December 21, 2008 2:49 AM 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.
they need database access. I prefre providing database over vpn rather providing via internet on different tcp port.
---------- Without using a VPN, you can do this. Example if you use M$ SQL Server set "Force Protocol Encryption" and generate the ssl certificate. I have no prior experience with MySQL, so if someone can comment on being able to do the same with it go right ahead. The application also that is connecting to it has to support SSL also.
Like you said in this post you would rather do this by VPN, well you would come way cheaper this way. Also still it doesn't matter connecting over a VPN is still going over the internet NO Matter how you look at it. What you are lacking to see is that there is more ways to do this sort of thing and save a heck of a lot of cash in doing so and will be just as secure. You really have a simple Project at hand.
You asked my vpn experience? The local telephone office where I live at. ATM/FR with pptp ppp and l2tp terminating connections there then routing them to another provider. Also Backhauling connections from the local office to the main fiber distribution point. All isdn, dsl, and fiber are backhauled from 18 miles away to the main office. We still use PSTN and POTS in a few areas and we are 10 years behind in networking technology. Just got E911 finished.
Instead of leasing a line maybe check into Dark Fiber for the area you live in (fiber cable laid down but not in use). ATM/FR maybe getting old but the connections can be really consistent with a good Service Level Aggreement between you and your network provider. You have also had other really good ideas also about doing this.
JohnStanley
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.
Remote database access is often better handled through web forms than direct remote client access - depending on the application, of course.
A vpn will work, but it adds a lot of unnecessary overhead in terms of losing MTU for packet encapsulation and managing addressing and routing through the tunnels. Plus, if the remotes are in other company's offices you'll have to fight their corporate firewall policies to get your tunnel packets through, especially if you run over udp. And then you'll have to firewall all the other stuff on your end that the vpn would otherwise permit access to.
For any single application/port connection you could use stunnel - or use a database that does ssl on its own.
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@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.
On Sun, Dec 14, 2008 at 9:20 AM, dhaval.thakar@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@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.
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 connections
M$-Internet Exploder est le cancer de l'Internet, voyez pourquoi ici : http://www.aful.org/ressources/documentations/msie-problemes-securite/
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 connections
The 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 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....
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, 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. 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?
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.
Robert Moskowitz wrote:
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.
Seems odd that no one does it that way. How do you set up redundant tunnel routes as failovers for dedicated circuits if you can't run routing protocols through the tunnels?