You are using FAT APs. How many APs are you planning on deploying? FAT
APs are great if you have a small setup. But once you start exceeding a
couple of hundred APs they tend to become a management nightmare just
for channel assignment and basic configurations.
Yes. You can always construct a highway with enough lanes and expansion
is always a possibility. My point was more along the lines of where you
want your entrances, exits and tolls on your highway. By properly
selecting those strategic points the cost of expansion may be avoided
unless absolutely necessary. 2500 connections is a pretty large amount
of connections to handle. But wireless is expanding very fast. It
starts as a luxury that turns into a commodity right before your very eyes.
JB
Foggi, Nicola wrote:
We are only using "FAT" AP's so we're not concerned with the
controller based problem of conectrating the traffic, but as for the
terminations on the VPN box, it's of course always a concern, however,
you obviously need to buy a scalable system. Many of the systems
these days (at least enterprise ones) will cluster to allow thousands
of simulanteous users. It's same same problem if you are running a
traditional IPSEC VPN, how many users do you want to put on one box.
In our scenario we are planning 1000 simultaneous users, the boxes we
are looking at support around 2500 simultaneous on one box and if you
cluster a second one in there 5000. I don't have that many users to
actually know how well it works, but I don't think I'll exceed 2000 in
the next couple of years...
Nicola
-----Original Message-----
From: Jorge Bodden [mailto:[EMAIL PROTECTED]
Sent: Wed 6/14/2006 8:48 AM
To: [email protected]
Subject: Re: [WIRELESS-LAN] SSL VPN over wireless
Stephen,
SSL vpn is used for remote users logging in to your network remotely.
Although it could solve some of your problems on the remote access side
as well as your wireless network side, it might not be the right
solution if you have a big enough network. I assume that the vpn
portion of of SSL stays the same in that all vpn traffic has to end up
at the vpn concentrator(s) at some point or another due to the fact that
the encryption will take place between the client and concentrator. (I
might be mistaken here on this since I do not work with the VPN
concentrator so much).
Using 802.1X the authentication will go from client to AP to Radius to
Authentication mechanism (LDAP, AD, etc) all of which are the same as
VPN. Once the authentication takes place the traffic will no longer go
to the concentrators for encryption purposes, which eliminates the
chance of a potential bottleneck at the concentrator. The encryption
now takes place between the AP and the client. You might still have the
potential for a bottleneck at the controller if you are implementing
LightWeight AP Protocol (lwapp) because then all your traffic now has to
go to the controllers. Although this solution might add overhead, but
one device will control traffic for internal users, while another
controls traffic for external users.
Please keep in mind that this solution is more scalable for larger
networks. If your network is small enough you should be able to get
away with SSL VPN.
Thanks.
Jorge Bodden
Stephen Holland wrote:
> I would like to know if anybody is using SSL vpn as an
> authentication/encryption mechanism for wireless and how successful they
> have been deploying it.
>
> Also, I would be curious to know what other folks think about
implementing
> 802.1x. Specifically do you believe this is something that will be
> required in the next couple of years to support evolving technology like
> VoIP phones?.
>
> I'm trying to decide if I should deploy an SSL vpn solution without
> deploying 802.1x. My instinct tells me to plan for 802.1x but I
would be
> curious to hear what others think.
>
> Thanks
>
> Stephen Holland
> Network Engineer
> Northeastern University
>
> **********
> Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/groups/.
>
--------------------
This electronic message is intended to be for the use only of the
named recipient, and may contain information that is confidential or
privileged. If you are not the intended recipient, you are hereby
notified that any disclosure, copying, distribution or use of the
contents of this message is strictly prohibited. If you have received
this message in error or are not the named recipient, please notify us
immediately by contacting the sender at the electronic mail address
noted above, and delete and destroy all copies of this message. Thank
you.
**********
Participation and subscription information for this EDUCAUSE
Constituent Group discussion list can be found at
http://www.educause.edu/groups/.
********** Participation and subscription information for this
EDUCAUSE Constituent Group discussion list can be found at
http://www.educause.edu/groups/.
--------------------
This electronic message is intended to be for the use only of the named
recipient, and may contain information that is confidential or privileged. If
you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution or use of the contents of this message is
strictly prohibited. If you have received this message in error or are not the
named recipient, please notify us immediately by contacting the sender at the
electronic mail address noted above, and delete and destroy all copies of this
message. Thank you.
**********
Participation and subscription information for this EDUCAUSE Constituent Group
discussion list can be found at http://www.educause.edu/groups/.
