Slashdot Mirror
Securing 802.11b with PPPoE?
no free lunches asks: "After giving up in disgust on layer 2 auth like *EAP/802.1x (which is a nightmare to configure properly and requires expensive access points and bleeding edge - flaky - firmware) I am considering controlling access to my wireless LAN (a small 50-user setup, with only one Linux user - me) using PPPoE, and would like to ask the Slashdot crowd their opinion."
Disadvantages:
Mind you, the usual procedures apply (disabling SSID broadcast, changing MTUs for PPPoE, investigating other data encryption methods) so on and so forth, but this approach strikes me as being quite 'clean', cheap and, most important of all, easy to implement NOW instead of waiting for the 802.1x crowd to get their act together (sure, some people will say you can get usable 802.1x now, but my experience with six different vendors indicates that full interoperability is a joke, and that you need all sorts of proprietary items and tweaks - you either use a single vendor for everything, or you're bust).
I know some ISPs are already doing this and I'm sure there are some people with PPPoE knowledge out there, so I'd like to know about similar experiences."
So far, the issues can be summarized as follows:
Advantages:
- Totally platform, NIC and AP independent - you can use any NIC, any OS, any access points.
- No IP addresses required on the PPPoE server or the APs - no DHCP, no nothing, so there is no easy way to have access without establishing a PPPoE session.
- Built-in crypto per session - using CHAP for auth and MPPE for data encryption.
- No client/proprietary auth software required on Windows XP (around 40 of my users, and the ones that will actually use this)
- Full session control (IP address assignments, traffic accounting, sessions only allowed during office hours, etc.), same as any remote access server.
- Cheap (server packages available for Linux and FreeBSD, any box can take the load)
- No proprietary IPSec tricks required - yes, I've considered it as an option, but remember, my users are Windows users, and PPPoE has the advantage of removing all IP addresses from the WLAN segment.
Disadvantages:
- No PPPoE clients for PDAs (yet)
- No published HOWTOs on PPPoE server setup under Linux (plenty of DSL/PPPoE client info and at least one HOWTO for FreeBSD, but since PPPoE servers are mostly commercial products, no one wants to give away info for free)
- MPPE encryption has some religious detractors (but it works fine for 98% of my users - the 49- strong Windows laptop crowd - and totally removes the need for WEP key management)
- Rogue PPPoE Servers - not really an issue if you can filter PPPoE frames on the radio interface - and I can, so you need wired access to set up one - but I'd like to know people's opinions on whether this is more than an urban myth fanned by 802.1x proponents.
- Freeloaders can still use the WLAN (even though there are no IP addresses) as a bridged segment (but I can sniff on the PPPoE server interface and/or poll every AP and kick out/ban any MAC addresses without an established PPPoE session - so MAC spoofing is of very limited use).
Mind you, the usual procedures apply (disabling SSID broadcast, changing MTUs for PPPoE, investigating other data encryption methods) so on and so forth, but this approach strikes me as being quite 'clean', cheap and, most important of all, easy to implement NOW instead of waiting for the 802.1x crowd to get their act together (sure, some people will say you can get usable 802.1x now, but my experience with six different vendors indicates that full interoperability is a joke, and that you need all sorts of proprietary items and tweaks - you either use a single vendor for everything, or you're bust).
I know some ISPs are already doing this and I'm sure there are some people with PPPoE knowledge out there, so I'd like to know about similar experiences."
Why not use a DHCP server that hands out IP addresses that aren't part of your internal network. e.g. if you're internal network is 192.168.0.x, then have it hand out 192.168.1.x addresses. Then use any sort of VPN to connect to the "real" network.
DHCP and VPN solutions exist for just about everything.
I would say your taking a big risk by doing this. MPPE is trivial to break, and is just downright bad by design....If you loose a single packet on the wireless connection, ppp is going to have to stop, and renegotiate encryption if you set it up to be stateless.... so then somebody is going to be able to sniff everything, and then use the nice packages out there to break it, then watch EVERYTHING that is going on with your clients... in about a 10th of the time that it takes with WEP.
Works for me (although I've not gotten encryption running yet), works for linux, works for Win 95 and higher without installing extra tools. Full authentication and encryption support. This should get you going. It's similar to PPPoE, except I suspect it's a little less hated by sysadmins.
If you could be told what you can see or read, then it follows that you could be told what to say or think - BoC
Why TCP Over TCP Is A Bad Idea
If you want to try it, consult the VPN PPP-SSH Mini-HOWTO