|« Site-to-site ethernet bridge over OpenVPN (2 of 2)||The hymn microformat (HMML?) »|
Our headquarters is in San Diego, CA, where I live and work. The last few days, however, I've been working in El Paso, TX, where we have a branch office. I had three tasks this week:
I'm going to provide a step-by-step for #2, bridged ethernet over a VPN. But I'll only lay out one-half of it now: the server side in San Diego, with roaming clients. The next post will discuss the El Paso side, since that has its own complexities.
To accomplish this, I used OpenVPN, an open-source, userspace VPN solution made by James Yonan. Give him some money if you can—this is the greatest networking tool since
You don't have to dedicate one solely to OpenVPN, but you probably should. I used a $400 Wal-Mart PC (with no OS). It needs two NIC's.
I used Sarge, which is currently the "testing" release, but will Very Soon Now become the "stable" release. I used the sweet new debian-installer with a 2.6 kernel, as sysadmin guru Greg Folkert advised.
Give eth0 a static IP. The configs will be easier if eth0 is the external NIC. You should have one cable hooked into your LAN switch/hub, and the other cable should be on the other side of your broadband router or firewall. It should look like this:
You don't have to have a T1, but you need multiple, static IP's (from your ISP). The firewall should already have one, and eth0 needs another. Also, be aware that your T1 box may have its own already (and don't use your broadcast address, either ).
apt-get install liblzo1 apt-get install liblzo-dev
apt-get install openssl apt-get install libssl-dev
cd /usr/src wget ??
?? with the URL of the OpenVPN sources. Go to the OpenVPN website to find out what the URL of the most recent release is. Modify the following commands to match whatever release you end up downloading. Also, do your best to use the same version on both the server and the clients.
gunzip openvpn-2.0_rc21.tar.gz tar xvf openvpn-2.0_rc21.tar cd openvpn-2.0_rc21 ./configure --with-ssl-headers=/usr/local/ssl/include/ --with-ssl-lib=/usr/local/ssl/lib/ make make install
apt-get install bridge-utils apt-get install tcpdump
mkdir /dev/net mknod /dev/net/tun c 10 200
cp /usr/src/openvpn-2.0_rc21/sample-config-files/firewall.sh /etc/openvpn/firewall.sh cd /etc/openvpn vi firewall.sh
iptables -A INPUT -p udp --dport 1194 -j ACCEPT
iptables -A INPUT -p udp --dport 4444:4449 -j ACCEPT
#!/bin/bash /usr/sbin/brctl addbr br0 /usr/sbin/brctl addif br0 eth1 TAPS="public rbre elpaso" for name in $TAPS do /usr/local/sbin/openvpn --mktun --dev tap$name /usr/sbin/brctl addif br0 tap$name done ifconfig eth1 0.0.0.0 promisc up for name in $TAPS do ifconfig tap$name 0.0.0.0 promisc up done ifconfig br0 192.168.0.235 netmask 255.255.255.0 broadcast 192.168.0.255 exit 0
Add a new name to the TAPS list for each tap (port) you wish to create.
The brctl commands make a new ethernet bridge, and then bind eth1 to that bridge. This means br0 is now acting like an unmanaged switch on your LAN, and eth1 is "plugged into" that switch. When each tap is bound to the same bridge, they become participants on that switch, and will receive any traffic which passes over eth1 (they're all "promiscuous", which means they will listen for traffic even if it's not directed specifically at them). The last
ifconfig line in the script makes our bridge behave like a managed switch by giving it an IP address.
Remember to make
opentuns.sh executable, using
This file provides a common config for all taps.
secret /etc/openvpn/static.key float ping 10 verb 5 comp-lzo persist-tun persist-remote-ip persist-key
Create the file
/etc/init.d/openvpn, to run everything at startup:
#!/bin/bash /etc/openvpn/firewall.sh /etc/openvpn/opentuns.sh VPN="/usr/local/sbin/openvpn --config /etc/openvpn/common.conf" $VPN --dev tappublic --port 1194 --daemon tappublic $VPN --dev taprbre --port 4444 --daemon taprbre $VPN --dev tapelpaso --port 4445 --daemon tapelpaso exit 0
Sorry, but you have to add a new line for each tap you create. This maps the port to the tap.
Remember to make this file executable, using
rc5.d, add symlinks to the file you just created. The "S number" you supply in the filename will determine the order in which your startup script is run (lowest first). I picked 19 a bit arbitrarily, based on other scripts in the rc folders.
ln -s ../init.d/openvpn S19openvpn
cd /etc/openvpn (mkdir the folder if necessary) openvpn --genkey --secret static.key chmod go-rwx static.key
All of my roaming clients are Windows 2k or XP; download the installer on each client. Each client needs a .conf file (the name doesn't matter) which matches the one on the server (for most items):
remote openvpn.aminus.org port 4444 dev tap dev-node my-tap secret static.key ping 10 verb 5 comp-lzo mute 10
remote parameter needs to point to eth0 on your server. My domain registrar has a nice DNS tool, so I added an A (host) record for openvpn.aminus.org and pointed it to the IP which I gave eth0. If you don't care to use DNS, you can just type the IP of eth0.
On Windows clients, remember to name the new network connection "my-tap", or whatever name you use in the client config.
Copy the static.key from the server into the
/config folder on each client.
On the server, type the following. Note that, for the most part, we are doing by hand what your init.d script does. We do it by hand so we can see the output at each step, in case something goes wrong:
cd /etc/openvpn ./firewall.sh ./opentuns.sh /usr/local/sbin/openvpn --config /etc/openvpn/common.conf --dev tappublic --port 1194
Notice we do not supply the
daemon argument to openvpn on the command line. This means your terminal will now be occupied running openvpn. If you need to check anything on the server while testing, Alt-F2 to another tty and login again.
Now start OpenVPN on a client; make sure the port is the same (1194, in our example). On the server side, you should start seeing traffic display in the openvpn process: it'll start spitting out w's and r's as it reads and writes data from the client. On the client side, if you start openvpn manually (in Windows, right-click on your .conf file and select "Start OpenVPN on this file") you should also see the connection as it happens. From the client, try accessing resources on the LAN (ping IPs, browse network shares, or access an internal website). If something goes wrong, fix it before proceeding to the next step.
The first thing that will most likely go wrong: you've got your server LAN running on the 192.168.0.x subnet, and you're running the client at home, also on a 192.168.0.x subnet. This doesn't work well, because your client doesn't know whether to send local packets through the tunnel or not. If your home was running on, say, 192.168.15.x, then there would be no conflict. Change your work or home subnet to something else.
Kill the openvpn process from step 16 using Ctrl-C. Reboot the server. Test a client again, manually. If that works, test the OpenVPNService (on Windows clients).
This should work for as many roaming clients as you like. OpenVPN 2.0 is supposed to have a way to set this up without having to specify a separate port per client; I simply haven't looked at that yet. I will when we get too many roaming clients.
Next time, we'll talk about a permanent bridge between two networks.
I too am setting up VPN with remote connections unsing linux at server site and winxp on client side. The sole purpose for us is the use of our IP Office phone system. I am having some issues..would like to talk with you about them...I too am in San Diego
thanks for any help you can provide
h0nda...fire away. fumanchu At amor dot org
Why are you telling people to compile their own openvpn server when you can get it easily as any other Debian package?
apt-get install openvpn
This will also make any other package needed for openvpn to work to be installed as well.
Why are you telling people to compile their own
openvpn server when you can get it easily as any
other Debian package?
apt-get install openvpn
Because the version of openvpn I wanted wasn't available in Debian unstable. Rather than re-publish this post every time openvpn and the debian package system get out-of-sync, I punted.
In addition, I found that the Debian package installed openvpn components in so many different places from the "norm" that most of the documentation on the OpenVPN site became useless to someone trying to set it up for the first time.
Either of those cases may have changed recently, but I probably won't rewrite this until I'm forced to rebuild one of my boxes. Hopefully that won't happen for several years. ;)
I have successfully set up a bridge based on your tutorial. The VPN channel is up and working but there are no data sent trough the tunnel and one side can't reach the other side. But route goes to br - so I dont know what to do now.
|<< <||> >>|