VPN over local wireless LAN for sharing files securely

[VirtualLarry]

Currently, I have a LAN set up with two machines. One has a USB 802.11g client NIC, and one is connected to a WRT54G, via a wired LAN connection via onboard mobo ethernet. The DSL modem is also connected to a LAN port on the router via a wired connection. (Wireless router functioning only as an AP, DSL modem is doing NAT, port-forwarding, DNS proxying, etc.) Internet sharing thus far works. There is also a software firewall on each machine.

Now, I want to also be able to share files/printers using Windows' built-in features, but be able to do so on a seperate subnet (maybe), or otherwise prevent someone from being able to: 1) sniff the wireless traffic, and see the files/data, and 2) hack into or otherwise access the shared files/printers directly. There are other WLANs in the vicinity, this is an apt. bldg.

I had the bright idea of unbinding the Windows' file/print sharing client and service from the wireless LAN adaptor's IP protocol (no NetBEUI installed either), and instead, I want to set up a VPN between the two machines on the LAN (wireless router supports VPN passthrough), and have the VPN endpoints be on a different subnet than the internet-sharing connection, so that I can firewall that traffic seperately from the internet traffic.

Does anyone have any good ideas/solutions for accomplishing this? Both machines are currently running W2K, although one occasionally could be booted into XP or Win98se.

 

[Xtremist]

Only a comment. I've noticed at my work's deployment that VPN through wireless can be real touch and go. Depending on the VPN server and how it handles the inherit issues with wireless (dropped packets, occasional 'line' interruptions) it may lose the VPN connection frequently. It all just depends on the quality/location of your equipment, and especially whether or not you'll be roaming around at all in this process.

 

[VirtualLarry]

Xtremist: I actually did consider that possibility, of dropped packets and such, but there isn't going to be any roaming thus far, just two computers located in different rooms of the same house. Installed wireless just so that people wouldn't be tripping over a giant run of CAT5.

I've also done some brainstorming, and think that I might have actually come up with a method of re-purposing the MAC address fields to do MAC-level packet authentication. I need to read up on WPA, in case I've just re-invented the wheel, but I don't think so. If this works (would require totally revised firmware to support it, both on APs and clients), this could actually be pretty big. It would prevent wireless spoofing, although it wouldn't prevent sniffing, because it doesn't do encryption of the data contents of the packet. However, it shouldn't be difficult to combine the two, to do both.

 

[freegeeks]

Openvpn

 

[VirtualLarry]

freegeeks, thank you! That sounds pretty-much just what I was looking for. Looks like you can compile it up for Windows too.

(Reminds me of the time that I used SLiRP, a user-space PPP daemon, to get Netscape working on my home PC, through my dialup shell acct. That was before PPP dialup accounts were common, and you have to pay $10/mo extra just for PPP. Those were the days..)

Edit: Have you actually used OpenVPN between two Windows boxes on either side of a WLAN? (One wired to AP, one with wireless client NIC.) I'm trying to figure out if I should use the "tap" or "tun" device version. "tun" is a routable IP tunnel, "tap" is a virtual bridged ethernet link, and supports ethernet broadcasts and non-IP traffic, according to the docs. I'm thinking the simplest way to set it up would be to use the "tun" device, and bind Windows' File/Print sharing client/service (over TCP/IP) to the "tun" interface, and then set up an LMHOSTS file on each machine, since they both have static private LAN IPs.

 

[freegeeks]

Originally posted by: VirtualLarry
freegeeks, thank you! That sounds pretty-much just what I was looking for. Looks like you can compile it up for Windows too.

(Reminds me of the time that I used SLiRP, a user-space PPP daemon, to get Netscape working on my home PC, through my dialup shell acct. That was before PPP dialup accounts were common, and you have to pay $10/mo extra just for PPP. Those were the days..)

Edit: Have you actually used OpenVPN between two Windows boxes on either side of a WLAN? (One wired to AP, one with wireless client NIC.) I'm trying to figure out if I should use the "tap" or "tun" device version. "tun" is a routable IP tunnel, "tap" is a virtual bridged ethernet link, and supports ethernet broadcasts and non-IP traffic, according to the docs. I'm thinking the simplest way to set it up would be to use the "tun" device, and bind Windows' File/Print sharing client/service (over TCP/IP) to the "tun" interface, and then set up an LMHOSTS file on each machine, since they both have static private LAN IPs.

I don't have experience with openvpn between 2 windows boxes (I use it between my laptop (Windows Xp - wireless NIC and my linux box - wired to my AP).

the setup you described shoud work

good luck :beer:

 

[VirtualLarry]

I had some more crazy ideas - since this OpenVPN thing runs on Linux, why not compile up a module or whatever of it, and load it onto those LinkSys WRT54G(S) routers, and allow them to be an OpenVPN endpoint, not just VPN passthrough.

I thought of two possible uses for doing that - perhaps make the wireless basically like a DMZ network, and have each internet-using client VPN into the AP. That would actually (theoretically) prevent unauthorized wireless clients from both connecting to other secure clients, and to the internet/WAN connection. They could, perhaps, hack on the AP's config menu pages/password though. I wonder how much of an overhaul it would be to actually "hide" the router/APs config menu pages (web server) behind a VPN tunnel endpoint as well. (This is starting to look like a complex and expensive network topology, in terms of CPU cycles on the router for all the encryption for the VPN endpoints...)

(Maybe implement hiding of the router's config pages, behind a "port knocker"? I've recently read about those, sounds kind of interesting. It would most likely keep out unwanted wireless visitors from ever even attempting to authenticate to the router's config pages.)

The second, alternative idea, would be to allow a client PC running OpenVPN to connect to a VPN endpoint on the router/AP, and that VPN connection, once up, would act as a DMZ. I'm not sure how easy or possible that would be to implement. I was thinking of a way for a client PC behind the router to dynamically set the DMZ to point to its IP, possibly for playing online games. However, the more that I think about this idea, the more useless it becomes. Better would be to enabled UPnP on the router and let DirectPlay do its thing. That solution would actually be superior, because theoretically, it would allow two different client PCs to connect to the same online game at the same time.

(The least-desireable solution, in this case, being static port mapping that has to be re-mapped in the router config pages every time a different client PC wants to play that particular online game.)

I just want my WLAN to be just as secure as my physical LAN, if not more so. (Due to more layers involved, possibilities for firewalling/NAT, etc.) Is that too much to ask?

Thanks for all your help so far, OpenVPN has given me a very big lead to look into implementing some of these things.

 

[n0cmonkey]

portknockers suck. Why not build a WAP? Modern Windows versions have an IPSEC client built in, that should be able to communicate with other available IPSEC servers out there.

Building a WAP is a bit more expensive, but with VIA technology (yeah, I'm being serious ) it doesn't have to eat up much more space, power, and peace of mind (quiet technology rocks) than the soho devices out there.

 

[VirtualLarry]

Build my own WAP? That's waaay overkill for my application. Hacking the HTTP server to use a portknocker in the router's source shouldn't be all that hard, I don't think, and it would probably keep the the unauthorized wireless clients guessing.

(Not to mention, my severe distaste of Via, but that's another story. Via should be in the "poor-quality engineering hall of shame" for many years in a row.)

 

[n0cmonkey]

Originally posted by: VirtualLarry
Build my own WAP? That's waaay overkill for my application. Hacking the HTTP server to use a portknocker in the router's source shouldn't be all that hard, I don't think, and it would probably keep the the unauthorized wireless clients guessing.

(Not to mention, my severe distaste of Via, but that's another story. Via should be in the "poor-quality engineering hall of shame" for many years in a row.)

They're much better these days. Atleast, they have been for me. And you can't beat their newer C3's.

 

[VirtualLarry]

I have to admit, the new crypto-processing features did catch my eye, but the fact that the C3 is just a 486 on steroids, kind of put me off on the idea. Plus, while it might be a fun exercise likewise, there really isn't budget nor room for an entire additional machine in this config. The original reason for putting in wireless was just to avoid running CAT5 across the floor, and I'm just trying to secure the wireless the best (and cheapest, space/price-wise) that I know how.

 

[n0cmonkey]

Originally posted by: VirtualLarry
I have to admit, the new crypto-processing features did catch my eye, but the fact that the C3 is just a 486 on steroids, kind of put me off on the idea. Plus, while it might be a fun exercise likewise, there really isn't budget nor room for an entire additional machine in this config. The original reason for putting in wireless was just to avoid running CAT5 across the floor, and I'm just trying to secure the wireless the best (and cheapest, space/price-wise) that I know how.

Pumped up 486? Like the pentium pro?

CPU: VIA C3 Samuel 2 (800.03-MHz 686-class CPU)

I can't blame you for the budget, but they don't take up much space. I'll leave you alone about it though, it was just a suggestion, and I don't want to crap in the thread much.

 

[VirtualLarry]

Originally posted by: n0cmonkey
Pumped up 486? Like the pentium pro?

CPU: VIA C3 Samuel 2 (800.03-MHz 686-class CPU)

They only say that because they (only partially) support (emulate?) 686-class opcodes via microcode. Unless things have improved, their CPU core is still little more than a scalar 486 derivative, with highly-boosted clock speeds and bigger caches. That's all. (Plus, their CMOV opcode is buggy, some things don't run on a Via C3 that should on a "real" 686-class CPU.)

IIRC, a PII-233 is around the same speed as a Via C3 600Mhz or 800Mhz chip for most things. (Maybe a PII-300? I should dig up that review.)

But the bottom line is that the Via C3 core is no-where near that of a P6-class "dynamic execution" core, like the PPro/P-II/P-III. I guess I still consider it largely a toy in the CPU dept. Power-savings are nice, but they're not that advantagous over, say, a 1.2v low-power mobile Athlon.

Originally posted by: n0cmonkey
I can't blame you for the budget, but they don't take up much space. I'll leave you alone about it though, it was just a suggestion, and I don't want to crap in the thread much.

Nah, don't worry, I didn't take it as a thread crap. If I had a bigger budget, it might be an idea. I have enough spare boxen lying around already though, I'd probably use those rather than put together a new Via-based mini-ITX.

 

[n0cmonkey]

Originally posted by: VirtualLarry

Originally posted by: n0cmonkey
Pumped up 486? Like the pentium pro?

CPU: VIA C3 Samuel 2 (800.03-MHz 686-class CPU)

They only say that because they (only partially) support (emulate?) 686-class opcodes via microcode. Unless things have improved, their CPU core is still little more than a scalar 486 derivative, with highly-boosted clock speeds and bigger caches. That's all. (Plus, their CMOV opcode is buggy, some things don't run on a Via C3 that should on a "real" 686-class CPU.)

IIRC, a PII-233 is around the same speed as a Via C3 600Mhz or 800Mhz chip for most things. (Maybe a PII-300? I should dig up that review.)

But the bottom line is that the Via C3 core is no-where near that of a P6-class "dynamic execution" core, like the PPro/P-II/P-III. I guess I still consider it largely a toy in the CPU dept. Power-savings are nice, but they're not that advantagous over, say, a 1.2v low-power mobile Athlon.

Unless you're doing encryption. In which case the newer C3s just blow everything else out of the water.

Originally posted by: n0cmonkey
I can't blame you for the budget, but they don't take up much space. I'll leave you alone about it though, it was just a suggestion, and I don't want to crap in the thread much.

Nah, don't worry, I didn't take it as a thread crap. If I had a bigger budget, it might be an idea. I have enough spare boxen lying around already though, I'd probably use those rather than put together a new Via-based mini-ITX.

Cool.

EDIT: The quotes got messed up and it was kickin' in the OCDs.

 

[ToeJam13]

Now, I want to also be able to share files/printers using Windows' built-in features, but be able to do so on a seperate subnet (maybe), or otherwise prevent someone from being able to: 1) sniff the wireless traffic, and see the files/data, and 2) hack into or otherwise access the shared files/printers directly. There are other WLANs in the vicinity, this is an apt. bldg.

802.11 already has functionality built into it to prevent unauthorized access to your WiFi network. Its called WEP, and for SOHO users, it does the job quite well.

A VPN solution might be a bit overkill. At one point, I considered it for my own network. However, I just decided to go with an 802.11a solution with 152-bit WEP enabled and SSID broadcasting disabled. The logs on my firewall have never detected any other clients (or MACs) entering the network.

In fact, Microsoft even has a word about IPSec over wireless:

Securing traffic over wireless 802.11 networks: You can use IPSec transport mode to protect traffic sent over 802.11 networks. However, IPSec is not the recommended solution for providing security for corporate 802.11 wireless LAN networks. Instead, it is recommended that you use 802.11 Wired Equivalent Privacy (WEP) encryption and IEEE 802.1X authentication. Support for IPSec, configuration management, and trust are required on client computers and servers. Because many computers on a network do not support IPSec or are not managed, it is not appropriate to use IPSec alone to protect all 802.11 corporate wireless LAN traffic. Additionally, IPSec tunnel mode policies are not optimized for mobile clients with dynamic IP addresses, nor does IPSec tunnel mode support dynamic address assignment or user authentication, which is needed for remote access VPN scenarios. To secure remote access traffic to organization networks when that traffic is sent over public wireless networks that are
connected to the Internet, use L2TP/IPSec VPN connections.

If you are considering the $100-$200 for a MiniITX system for a VPN endpoint, look at a corporate WiFi AP instead. Many offer better encryption, authentication and authorization services.

 

[n0cmonkey]

Originally posted by: ToeJam13

Now, I want to also be able to share files/printers using Windows' built-in features, but be able to do so on a seperate subnet (maybe), or otherwise prevent someone from being able to: 1) sniff the wireless traffic, and see the files/data, and 2) hack into or otherwise access the shared files/printers directly. There are other WLANs in the vicinity, this is an apt. bldg.

802.11 already has functionality built into it to prevent unauthorized access to your WiFi network. Its called WEP, and for SOHO users, it does the job quite well.

A VPN solution might be a bit overkill. At one point, I considered it for my own network. However, I just decided to go with an 802.11a solution with 152-bit WEP enabled and SSID broadcasting disabled. The logs on my firewall have never detected any other clients (or MACs) entering the network.

In fact, Microsoft even has a word about IPSec over wireless:

Securing traffic over wireless 802.11 networks: You can use IPSec transport mode to protect traffic sent over 802.11 networks. However, IPSec is not the recommended solution for providing security for corporate 802.11 wireless LAN networks. Instead, it is recommended that you use 802.11 Wired Equivalent Privacy (WEP) encryption and IEEE 802.1X authentication. Support for IPSec, configuration management, and trust are required on client computers and servers. Because many computers on a network do not support IPSec or are not managed, it is not appropriate to use IPSec alone to protect all 802.11 corporate wireless LAN traffic. Additionally, IPSec tunnel mode policies are not optimized for mobile clients with dynamic IP addresses, nor does IPSec tunnel mode support dynamic address assignment or user authentication, which is needed for remote access VPN scenarios. To secure remote access traffic to organization networks when that traffic is sent over public wireless networks that are
connected to the Internet, use L2TP/IPSec VPN connections.

If you are considering the $100-$200 for a MiniITX system for a VPN endpoint, look at a corporate WiFi AP instead. Many offer better encryption, authentication and authorization services.

I think the thought is to use the hackable Linux based linksys wireless router. Linux has some mighty nifty authentication, encryption, and authorization utilities. (and OpenBSD has them + some )

 

[VirtualLarry]

Originally posted by: ToeJam13

Now, I want to also be able to share files/printers using Windows' built-in features, but be able to do so on a seperate subnet (maybe), or otherwise prevent someone from being able to: 1) sniff the wireless traffic, and see the files/data, and 2) hack into or otherwise access the shared files/printers directly. There are other WLANs in the vicinity, this is an apt. bldg.

802.11 already has functionality built into it to prevent unauthorized access to your WiFi network. Its called WEP, and for SOHO users, it does the job quite well.

Really? I was under the impression that WEP was largely trivially crackable, not due to key lengths, but that the actual implementation of the cryptographic protocol was flawed. There are already two WLANs operating in the vicinity that I picked up. Given that even 128-bit WEP is supposedly crackable within a week, I don't trust it, in light of the fact that persistent neighboring WLANs could easily do that. I'm not talking about drive-by wardrivers here, they'll just move along until they find an open WLAN. I'm more worried about some neighbor's 16-year-old kid cracking into my WLAN for sport. (Heck, I did those kinds of things too, when I was that age, so I kind of understand, but I still want to ensure that the data on this network stays secure.)

Originally posted by: ToeJam13
A VPN solution might be a bit overkill. At one point, I considered it for my own network. However, I just decided to go with an 802.11a solution with 152-bit WEP enabled and SSID broadcasting disabled. The logs on my firewall have never detected any other clients (or MACs) entering the network.

How do you know that they didn't sniff the MACs of the valid clients, used that to crack the WEP, and have been sniffing all of your traffic in the clear for some time now? Without another layer, you don't know.. that's the problem. I'm actually contemplating setting up an "open" honeypot wireless router, to log possible "curious" rogue MACs, and to use as an IDS for the main wireless system.

Btw, I've been convinced that disabling SSID broadcast does absolutely nothing in terms of security, and simply just slows down the operations of your network. I leave my SSID broadcast in the clear.

Originally posted by: ToeJam13
In fact, Microsoft even has a word about IPSec over wireless:

To secure remote access traffic to organization networks when that traffic is sent over public wireless networks that are connected to the Internet, use L2TP/IPSec VPN connections.

That's why I was looking at VPN technology. Let's face it, wireless links are inherently insecure. WEP is an insecure solution to the issue. An encrypted VPN tunnel between both hosts on each side of the wireless link, should at least provide minimal security for allowing access to Windows' file-sharing without worrying about direct intrusion attempts or sniffing the contents of the shared files in the clear.

If you are considering the $100-$200 for a MiniITX system for a VPN endpoint, look at a corporate WiFi AP instead. Many offer better encryption, authentication and authorization services.

The plan was to do this in my spare time, "on the cheap". This is a home setup, not one with a corp. budget behind it. But that's no reason to leave it insecure. I'm trying to implement this solution as "professionally" as I can, to gain the experience, but keep it under budget. So far, LinkSys WRT54G - $50 AR, WUSBG - $40 AR, and a Network Everywhere NWK11B kit, with a 'b' router and 'b' CardBus NIC - $50. Both routers run Linux, but cannot find source to the 'b' one, LinkSys is hiding the fact that they ever made this model. :| I haven't really dug into this OpenVPN thing yet, I installed it yesterday on my main rig, but then Windows' crashed with the strangest error that I've ever seen. The mouse would only move horizontally, not vertically, and the keyboard and UI wouldn't respond at all. I blame my ATI drivers, but I'm not really sure. I hope that someone didn't try a 'sploit via my wireless NIC. I'm still not sure, if a wireless NIC operating in client infrastructure mode, can accept packets from other "rogue" wireless NICs. Anyone know? How "secure" is the "infrastructure" connection mode, or is it just an access-policy feature of the protocol, and doesn't actually affect security at all?

One possible additional plan that I had, was, depending on the firmware that I can find for the 'b' router, to use that running in WDS or client infrastructure mode wired to my host machine, instead of the wireless NIC, thus providing one more layer of security between my rig and the WLAN. (Plus, this USB wireless NIC doesn't support Win9x, so I won't be able to multi-boot with it and still access the DSL internet connection.)