Home VPN Solution for Wi-Fi
As I have been mentioning, I would like a little more security for my home wireless (Wi-Fi) network. I have implemented my solution using OpenVPN. Assuming you have a topology similar to the following:
...my solution may be of use to you.
As you may see from the above diagram, I have hosts on my network that use both Windows (WinXP) and Linux. The Linux machine is an always-on "server" installation of Fedora Core 3, that serves many other purposes for me. One benefit of OpenVPN is that it works well, regardless of operating system. So, if you have two Windows hosts, or two Linux hosts, or use Linux on your laptop and Windows on the "always-on" system -- you should have no problems installing and configuring OpenVPN.
First of all, you're going to have to download and install OpenVPN. Obviously, for any Linux installation, you'll have to read the install documentation for the procedure that works best for you. The Windows installation procedure is located here.
Now that you have OpenVPN installed, let's look at what we are trying to accomplish. Hopefully you have WEP enabled on your Wi-Fi connection. While WEP does encrypt data, it is possible (though very time consuming) to crack WEP. In addition, once the WEP key has been obtained -- the network packets can be "replayed" with the key, thus exposing any sensitive information that traveled wirelessly during the attacker's assault. If a network protected by OpenVPN is attacked, another layer of 2048 bit RSA encryption will protect you. (Read this article if you'd like to understand how much protection 2048-bit RSA encryption gives you.)
Without going into too much detail, the terms client and server don't usually apply to VPN networks. Think of two large corporate peer networks that tunnel to each other over a VPN via the public Internet. It's doesn't really make sense to call one a server or a client if they are both peers, so they are generally referred to as left or right. However, for our application, and for the clarity of this article, we will refer to the wireless device (laptop) as the client and the desktop (always-on) as the server.
Looking at the above diagram, we'd like to route all Internet/Intranet traffic from the wireless client directly to the always-on computer, and we'd like it to be encrypted. The topology would resemble the following:
Note that in this diagram, traffic can still flow unencrypted directly from the client (192.168.1.14) to the gateway (192.168.1.1) by way of the dotted line, but we will force traffic to go the encrypted route through the always-on server (192.168.1.15).
You'll also notice in this second diagram that the client and server have assumed additional IP Addresses (10.4.0.1 for the server, and 10.4.0.2 for the client). Once you start the OpenVPN installation on each machine, "virtual network adapters" will assume the addresses as dictated by the configuration file. In WinXP, you should see it under "Network Connections". Using Linux, it will be available by doing an ifconfig with no parameters.
Note that if you have a firewall enabled on either the wireless client or the server, you'll need to ensure that UDP port 1194 is open on both sides between the two machines that you wish to connect. The procedure for this will vary for both platforms. For Windows, you'll have to manipulate the built-in firewall or ZoneAlarm if you have either installed and enabled. For Linux, depending on your version of kernel, you will need to manipulate iptables or ipchains. Fortunately, for those of you using kernels 2.4 and later, I have a version of an iptables shell script that will help you. This is a slightly modified version of the firewall script included in the OpenVPN 1.x HowTo documentation.
We will also have to ensure that IP forwarding on our always-on/server machine. If you need help setting this up for a Windows XP machine, Practically Networked has a good article. For Linux, you'll need to enable Kernel IP forwarding. In the standard Fedora Core 3 install, and most likely other 2.6.x based kernels (as root)...
echo 1 > /proc/sys/net/ipv4/ip_forward
I also have sample server and client configuration files you may find of use. Once you have edited these configuration files to your needs, you'll need to place them in the appropriate configuration directory. On a Linux machine, this is usually /etc/openvpn. A standard Windows install should include a start menu shortcut to the configuration file, if you can't recall the drive and path you installed OpenVPN to.
Note the appropriate extension for Windows is
.ovpn and for Linux, I use .conf. You'll need to locate and name these files according to your installation.
Now we'll need to start up the OpenVPN on both sides of the networked tunnel. Fortunately -- for both Windows and Linux, the OpenVPN command is installed in the global search path. The Windows installation comes with an option to install OpenVPN as a service. However, we'll want to make sure we have all output information available to us in the command line, which will make troubleshooting any problems easier. In my example, the "server" (always-on) is the Linux machine, and my wireless laptop uses Windows XP. Please note that the configuration filenames need to be saved and named appropriately as mentioned above. For my Linux server side of the VPN, I would start OpenVPN by the command:
openvpn --config /etc/openvpn/server.conf &
This command provides the location of the configuration file to the openvpn binary. All parameters can be entered as command line options, but that would be a little awkward. The ampersand backgrounds the process, returning your terminal interface (screen) to a command line prompt. Output from the openvpn process should output to your terminal. You'll likely see that openvpn is complaining that it cannot currently speak to your client. This is normal, as you probably haven't started the client yet. On my Windows laptop, I would use the command:
cd E:\Program Files\OpenVPN\config
openvpn --config client.ovpn
Note that the path for your OpenVPN installation will likely vary. Note that if you wish to shutdown or restart either the server or client process, you'll need to so either with kill on Linux or taskman on Windows.
At this point, we are near complete with initial installation and testing. In Linux, issuing the ifconfig command should reveal a new tun1 interface. In Windows, you'll possibly notice a new tray (system notification) icon blinking activity. You may also see "connected" status in Windows "Network Connections". In fact, you should be able to ping each side of the tunnel from either host at this point. Hopefully you have any firewall issues out of the picture as mentioned above. Assuming you used the same numbering scheme as me (10.4.0.x), from either host: (use control-c to stop pinging on Linux)
ping 10.4.0.1
ping 10.4.0.2
You should see a series of response data if the ping is a success. Otherwise, you'll receive an "unreachable" or "timed out" message with each ping.
The client configuration that I mentioned above contains an option near the bottom to redirect all traffic through the "server" machine as a gateway. This, in combination with turning on IP forwarding (also above) should force all Internet traffic to pass encrypted through the "server", at which point the traffic is decrypted and forwarded as normal Internet traffic. However, I have noted some instances where for whatever reason the Windows client cannot alter the routing table. If this is an issue while you are testing your installation, you can issue a command line instruction to correct this problem. There shouldn't really be any need to modify routing on the "server", so all routing modifications should be performed on the client. Again, assuming you are using similar addresses:
route add 0.0.0.0 mask 0.0.0.0 10.4.0.1 (Windows as client)
route add default gw 10.4.0.1 (Linux as client)
Note that if problems arise, you can delete the erroneous default gateway and replace it with the correct one using commands like the following (assuming 192.168.1.1 as your gateway):
route delete 0.0.0.0 mask 0.0.0.0 10.4.0.1 (Windows)
route add 0.0.0.0 mask 0.0.0.0 192.168.1.1 (Windows)
You may wish to be careful with the routing commands. Depending on your setup and your familiarity with routing, recovering from erroneous commands can be frustrating.
Note: If for some reason things aren't working well for you at this point, be sure to check the obvious first (bad addressing, syntax, look at the OpenVPN output for clues). My problems in testing this setup were caused by failure to turn on Linux IP Forwarding (preventing "server" from relaying traffic) and firewall issues.
At this point, you should be able to pull up a web browser on your client machine, and ALL wireless traffic is protected by 2048-bit RSA encryption. The 2048-bit encryption is in addition to the inherent encryption of the WEP or WPA you may already have on your network. When someone sniffing out a WEP key wants to crack WEP, they collect a few days worth of Wireless traffic (quite a few megabytes of information). Once the cracking program has found the key, they can "replay" the packets and see plaintext information you may not wish be shared. Enabling this VPN solution reveals only encrypted data.
To illustrate here you can see an Ethereal screen shot that displays captured packets. In the bottom half of the screen, you can see a (hexadecimal notation) plain text capture of a telnet session. I issued a simple ls command, and you can plainly see the output. Any unencrypted protocol (unsecure HTTP, SMTP, POP3, FTP, etc) would be vulnerable to this eavesdropping also. This does assume however, that a WEP key has been obtained by the hacker.
Below is the same command, this time sent over the VPN. Realize that because of the encryption, packet sizes will vary. We can see the traffic over UDP port 1194, but it's not plainly readable. (Again, you should read the RSA Article)
I hope this information may be of use to you. If you note any errors or have any suggestions, please feel free to contact me.
Update: March 8, 2005 9:51pm ... I recently tried this using Linux on the wireless laptop. Using the redirect-gateway directive in the client configuration file in Linux seems to cause some sort of problem, causing the wireless adapter to drop its connection. I am speculating that openvpn uses antiquated information for "eth0" rather than "eth1" for the wireless adapter. After starting OpenVPN, I checked my routing table and saw a gateway IP address that I hadn't used since I installed Linux on this laptop. The problem is resolved by manually issuing the appropriate routing commands, described above. I'm sure this could be resolved in the form of a shell script, or investigating the defunct settings for eth0.
Syndication