We worked through this issue with our brand C rep. He suggested, and we agreed, to disable split-horizon. Which is what you are speaking of. If you are not doing this then yes you are leaving your clients vulnerable. One thing we also did was to "require" our pre-configured VPN client. The VPN client has a group and group password to prevent anyone trying to make a connection with the client of their choice.
So far it has worked very well. And to bump my own hit stats: http://www.jmu.edu/wireless Brad > For those using a VPN to control the WLAN, what measures do you have > in place to defend the systems from one another? > > For example, with Cisco VPN client, you can have it disable the > system's interface to its actual LAN while tunneled to the VPN > address. But with others (e.g. MS-PPTP), the system's "real" LAN > interface remains accessible, so a weakly defended system becomes prey > for LAN neighbors (maybe some walk-by's who never bother to > authenticate to the VPN), even if they're busy working over their VPN > tunnel. > > -- > > ------------------------------------------------------------ > Gary Dobbins, CISSP -- [EMAIL PROTECTED] > Director, Information Security > University of Notre Dame, Office of Information Technologies > Voice: 574.631.5554 > ------------------------------------------------------------ > > > > Bradford B. Saul wrote: > >>> Okay: >>> >>> we've seen some discussion on 802.1x usage (is there more out there?) Some >>> PEAP, some LEAP, and TLS seems to be out unless you have an existing PKI >>> infrastructure (yeah, right). >>> >>> We saw one mention of Bluesocket. How many other schools are opting for >>> WLAN >>> edge treatment using Bluesocket or Reefedge products? Are you happy with >>> the >>> performance? Client issues? Cost/value? >>> >>> Then there's the tried & true firewall/VPN solution. Client issues? Do you >>> permit your cloud to be open in private address space or do you control >>> somehow control association with your APs Do you pemit limited access to >>> resources (without the benefit of the VPN session) to those services that >>> have >>> strong AuthN support (e.g. SSL enabled Webmail for instance)? >>> >>> Finally -- how many schools have opted not to broadcast SSIDs? >>> >>> come on folks -- the list is only as good as those who take time to >>> contrubute >>> meaningful dialogue. >>> >>> -d >>> >>> >>> ********** Participation and subscription information for this EDUCAUSE >>> Constituent Group discussion list can be found at >>> http://www.educause.edu/cg/. >> >> >> OK, Dewitt has thrown down the gauntlet...... >> >> The setup at JMU is as follows: >> >> 1) We broadcast the SSID's >> - Simply a support issue. We wanted to make the wireless >> network as "user" proof as possible >> 2) Address space is private (10.x.x.x) >> - No other reason than why burn real addresses. >> 3) Anyone can associate with an AP. >> - We only have ~35 at this point >> - Our goal was to cover large common areas and move >> slowly into all areas >> 4) Access to resources is controlled by the resource >> - ie. Passwords etc.... >> 5) VPN Client free to all users >> - Currently: Win 2K/XP and MacOSX >> - Working on Linux >> - Working on PDA's (Need help, hint to Bill Paraska!) >> 6) VPN Concentrator >> - Brand C >> 7) Auth is proxied through RADIUS to LDAP >> 8) No public access >> - Only users with valid JMU LDAP credentials can >> use the wireless network >> - This does at times, although limited, create support >> issues for visitors. But most of the time there is >> a member of the JMU community in the crowd that can help. >> >> I realize what we have done is not exactly cutting edge, but we have had >> great success and with the wireless Vlan being propagated campus wide we >> have a single procedure for the users. I think that is the single biggest >> reason it has gone so well so far.... >> >> Brad >> ----------------------------------- >> Bradford B. Saul >> Lead Network Engineer >> IT - Network Engineering >> Hoffman Hall Room 10, MSC 1401 >> James Madison University >> Harrisonburg, VA 22807 >> V: (540) 568-2379 >> F: (540) 568-1696 >> M: (540) 435-3079 >> [EMAIL PROTECTED] >> >> ********** >> Participation and subscription information for this EDUCAUSE Constituent >> Group discussion list can be found at http://www.educause.edu/cg/. > > -- > > ------------------------------------------------------------ > Gary Dobbins, CISSP -- [EMAIL PROTECTED] > Director, Information Security > University of Notre Dame, Office of Information Technologies > Voice: 574.631.5554 > ------------------------------------------------------------ > > ********** > Participation and subscription information for this EDUCAUSE Constituent Group > discussion list can be found at http://www.educause.edu/cg/. > ----------------------------------- Bradford B. Saul Lead Network Engineer IT - Network Engineering Hoffman Hall Room 10, MSC 1401 James Madison University Harrisonburg, VA 22807 V: (540) 568-2379 F: (540) 568-1696 M: (540) 435-3079 [EMAIL PROTECTED] ********** Participation and subscription information for this EDUCAUSE Constituent Group discussion list can be found at http://www.educause.edu/cg/.
