dslreports logo
 
    All Forums Hot Topics Gallery
spc
Search similar:


uniqs
7235
parachuter2b
join:2008-11-06

parachuter2b

Member

limit on the # of people can connect to a VPN server?

Hi there,

I'm using dd-wrt and right now I have the following in the Client IP(s) of the PPTP server tab of vpn:
192.168.1.200-255

but I was wondering what's the maximum number of clients that could connect to the server at the same time? would 255 be the max?

Also, what is the max # of connections without compromising the connection speed for every client?

Thanks a lot!

hurdle7

leibold
MVM
join:2002-07-09
Sunnyvale, CA
Netgear CG3000DCR
ZyXEL P-663HN-51

leibold

MVM

said by parachuter2b:

I'm using dd-wrt and right now I have the following in the Client IP(s) of the PPTP server tab of vpn:
192.168.1.200-255

Are you sure that you want to assign the broadcast address 192.168.1.255 to a vpn client ?
said by parachuter2b:

would 255 be the max?

No, you configured a pool of 156 IP addresses for vpn clients, so that is your limit.
said by parachuter2b:

Also, what is the max # of connections without compromising the connection speed for every client?

1 (worst case scenario where the client has a faster Internet connection then the server).

There are 3 main factors that determine how many VPN clients a server can support before service degrades for the already connected clients. For residential Internet connections it is not unusual to see 2 clients impacting each other.
The factors are:
- network bandwidth: unless the bandwidth at the VPN server exceeds the sum of the bandwidth for all connected VPN clients it will be possible for the clients to saturate the bandwidth of the Internet connection. Because of the asymmetric nature of most residential Internet connections the bandwidth calculation needs to be done twice (in upload and download direction). You could configure a bandwidth limit for each VPN tunnel that would ensure that no single VPN client can use up the entire bandwidth at the VPN server.
- cpu power: encrypted VPN connections are typically very CPU intensive. The amount of CPU power needed increases with the length of the key used to encrypt the session. When using a residential broadband router as VPN server this can be even more limiting then the network bandwidth. Depending on your security needs you can use shorter key length (or even unencrypted VPN tunnels) to reduce CPU load.
- memory: each VPN tunnel requires memory to store session keys, state information as well as sufficient packet buffers to reassemble fragmented packets and to reorder packets that arrived out of order (required for successful decryption). With residential broadband routers that amount of memory can be very limited.

Of course any configuration settings in the VPN server (max sessions, IP pool size) also limit the number of connections.

eibgrad
join:2010-03-15
united state

1 recommendation

eibgrad to parachuter2b

Member

to parachuter2b
Leibold did such a good job explaining it, that I only have one quibble/clarification regarding his comments.

The CPU requirements of encryption vary greatly depending whether you're using symmetric or asymmetric solutions. A symmetric system uses a single key and some algorithm (e.g., XOR) to encrypt bulk data, and is generally very fast, w/ negligible demands on the CPU. OTOH, an asymmetric system uses public/private key pairs and is MUCH slower and more CPU intensive, and grows exponentially w/ key length. Also, symmetric systems don’t provide any means of authentication/repudiation, while asymmetric do (+1).

That’s why when the WEP (symmetric) routers of years ago were cracked and replaced w/ WPA/WPA2 (asymmetric), you almost always needed a new router. Your current router typically couldn’t handle it. A firmware update from the manufacturer was insufficient.

So the type of encryption greatly determines the impact to the CPU. In some cases, both are used. The bulk data is encrypted symmetrically, while the symmetric key is encrypted asymmetrically, giving you the best of both worlds, a hybrid. So the impact to the CPU has been mitigated w/ some clever design.

Since the OP is using PPTP, he’s only using MPPE (symmetric) encryption anyway. And that (along w/ the lack of authentication/repudiation) makes it more vulnerable than most VPN solutions. In fact, to “bolster” MPPE a bit, PPTP offers the MPPE STATEFUL option, which uses the prior encrypted block as salt to the next encrypted block (the thought being you can’t decrypt any single block in isolation). While certainly an improvement, it falls far short of VPN alternatives based on asymmetric encryption.

To make matters worse, not all PPTP servers support stateful encryption, and so many times you’re forced to turn it off (aka, MPPE STATELESS) for compatibility reasons. Or as was suggested, perhaps turn encryption off completely. But give the miniscule CPU requirements of MPPE, and PPTP’s already questionable security, I see no good reason to do this. Only compatibility issues would make me even consider it (and even then, I’d probably move to OpenVPN or similar systems based on asymmetric encryption).

So at least as far as PPTP goes, the CPU (imo) is a non-issue. It’s such a weak VPN solution that you have far greater things to be concerned about. PPTP continues to be used not because it’s good, but because it’s ubiquitous. And while ubiquity has its advantages, just don’t be fooled/lulled into thinking it’s appropriate for those situations where security threats should be taken more seriously. But for home users? Eh, probably not a big deal.

Other than that one (admittedly narrow) point, leibold has nicely detailed many of the things to consider for any VPN, all of which could impact performance.

leibold
MVM
join:2002-07-09
Sunnyvale, CA
Netgear CG3000DCR
ZyXEL P-663HN-51

leibold

MVM

Thank you for the additional clarification.

What you said about PPTP and MPPE is technically correct but you imply that STATELESS mode is less secure then STATEFUL mode. As far as I know (and I admit not to be a cryptography expert) it is actually the other way around. In stateless mode the encryption key must be changed for every single data packet that is transmitted:
said by RFC3078 :

7.1. Stateless Mode Key Changes

If stateless encryption has been negotiated, the session key changes
every time the coherency count changes; i.e., on every packet. In
stateless mode, the sender MUST change its key before encrypting and
transmitting each packet and the receiver MUST change its key after
receiving, but before decrypting, each packet (see "Synchronization",
below).

This constant re-keying in stateless mode (many PPTP servers are configured to refuse stateful mode) adds to the cpu load and impacts network throughput (additional packets for key exchange).

The big weakness of PPTP is that predictable content in a packet allows anybody listening on the encrypted communication to reconstruct the encryption key used. If security is a concern then PPTP compression should be enabled since this makes the packet content unpredictable. However compression/decompression too add to the CPU workload of the VPN gateway.

eibgrad
join:2010-03-15
united state

1 edit

1 recommendation

eibgrad to parachuter2b

Member

to parachuter2b
Yeah, I may have that stated backwards, I never remember which is which.

But while a changing key (and compression) unquestionably adds to the CPU load, I still thinks it's relatively minor compared to the impact of asymmetric encryption. After all, we were using PPTP well enough w/ those old, crappy WEP-based routers years ago. It was only WPA/WPA2 that drove up the specs. But in terms of the impact to throughput, for sure. Again, CPU impact was my major consideration in those comments. Your comments about compression are good as well (I had forgotten about that option).

Let’s face it, PPTP sucks, and it looks worse and worse the more you examine it.