IPIP and OpenVPN Combined For Amprnet Tunnels
IPIP is a stateless tunneling protocol, it cannot transverse a firewall. These types of tunnels need no central point, cutting down on bandwidth and single point of failure issues.
OpenVPN is a statefull tunneling protocol that can transverse a firewall.
Each have their place and are useful. In this example we will combine to the two.
In our examples above we have two radio gateways. #1 is at a hams house, where he has access and full control of the firewall. He allows protocol 4 though his firewall for IPIP to work.
Gateway #2 is a location where the internet connection is donated by a business, and a matter of their security policy they do not allow provisions for port/protocol forwarding.
We use OpenVPN to interconnect them as pictured until one day a radio link might be able to be established.
At the OpenVPN client connection, the default route is to pass traffic out eth0 toward the internet. The default route could be changed to route all traffic over the tunnel, but this would bottle-neck things.
When an originating packet comes toward this gateway from something other than the OpenVPN server address, the reply follows the clients default route. This is no good.
It will be dropped somewhere along the line, mostly likely by the ISP. That's because these packets have a source address that is not part of the network that they are being routed from -- they look like they've been forged. Indeed, such forged packet headers are often used in DOS attacks. We need to ensure the reply goes back out over the tunnel, the way it came in regardless of it's source address.
We will use advanced routing rules to do this, detailed later.
Installing and Setting up OpenVPN
Theory and background:
If your openvpn server is behind a firewall, you'll need to open/forward the default port of 1194 UDP. Obviously the client(s) needs no firewall modifications. The client creates and maintains an active (stateful) connection to the server at all times. This allows the server to track a reverse way back to the client. (Handshakes are about every 5 seconds, yet it only amounts to about 14 MB per month for an idle connection per client)
The following are my install notes for OpenVPN 2.2.1 on a Debian Linux system.
Installation:
Install openvpn and it's dependencies.
apt-get install openvpn openssl
After the install finishes, you need to generate keys for the server and the client(s). OpenVPN ships with the 'easy-rsa'-tool. It's easiest to copy the example folder and work from there.
cp -R /usr/share/doc/openvpn/examples/easy-rsa /etc/openvpn cd /etc/openvpn/easy-rsa/2.0
The 'easy-rsa'-tool has a file called 'vars' that you can edit to set some defaults. That will save you time later on but it's not required to do so.
Load the vars like this (note the two dots):
. ./vars
Then we need to generate keys:
./clean-all ./build-ca ./build-key-server server ./build-key client1 ./build-dh
The first line makes sure we start from scratch. The second generates a key for the Certificate Authority. The key for the server itself is generated on the third line. Repeat the forth line for each client that needs to connect. Finally, we need the Diffie Hellman key as well, which is generated on the fifth line.
When creating the keys and certificates most parameters can be left to their default values. The only parameter which must be explicitly entered is the Common Name. So for each client, make sure to type the appropriate Common Name when prompted, i.e. "client1", "client2", or "client3". Always use a unique common name for each client.
kb9mwr:easy-rsa # ./build-ca Generating a 1024 bit RSA private key ............++++++ ...........++++++ writing new private key to 'ca.key' ----- You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [KG]: State or Province Name (full name) [NA]: Locality Name (eg, city) [BISHKEK]: Organization Name (eg, company) [OpenVPN-TEST]: Organizational Unit Name (eg, section) []: Common Name (eg, your name or your server's hostname) []:OpenVPN-CA Email Address [[email protected]]:
We need to copy the keys to the OpenVPN folder. (You'll need to copy ca.crt, ca.key, client1.crt, client1.csr, client1.key that you generated on the server to your client(s))
cd /etc/openvpn/easy-rsa/2.0/keys cp ca.crt ca.key dh1024.pem server.crt server.key /etc/openvpn
Last step is to configure the server. You can copy the example config and make sure it points to the certs you just created. (Example client config: /usr/share/doc/openvpn/examples/sample-config-files/client.conf)
cp /usr/share/doc/openvpn*/examples/sample-config-files/server.conf.gz /etc/openvpn gunzip /etc/openvpn/server.conf.gz vim /etc/openvpn/server.conf
When you're done, start OpenVPN like this:
/etc/init.d/openvpn start
On a Centos 5.x machine you start it a bit different, as you must specify path to a config:
openvpn /etc/openvpn/client.conf
Modifying the server config to hand out 44 addresses
Once you have an understanding of it using the default configuration, customizing it to use 44 net addresses is pretty simple. It is all controlled on the server side configuration file. The "server" parameter usually be default uses the 10.8.0.0 private network address space.
server 10.8.0.0 255.255.255.0
Aside from changing this parameter, nothing else is done on the server end.
The server will take 10.8.0.1, and draw client addresses within the netmask defined. (Note that the smallest subnet mask that it will allow is 255.255.255.248) The client will to IP mapping will be stored in /etc/openvpn/ipp.txt
The default client config does not change your default route. Thusly only the necessary traffic will go over the tunnel. However; as mentioned in the start when you point outside traffic in using IPIP and openvpn, the client will not be able to route reply packets over the tunnel properly. (They will follow your default route, and be dropped by your ISP). Once again we set a rule to cure this:
First we make and entry in /etc/iproute2/rt_tables"
10 gw1
We set a route:
/sbin/ip route add default via 44.92.21.1 dev tun0 proto static onlink table 10
(openvpn server tun0 IP)Then we set a rule:
/sbin/ip rule add from 44.92.21.134/25 table 10
(client tun0 IP)In layman's terms, this is source routing instead of destination routing. Anything originating here (at the client) from a 44 address (reply packets or otherwise) will follow a rule tied to a specific default route and gateway. In our case, the server.
Aside from this nothing else is done on the client end.
Here is a look at the default routing with OpenVPN (automatic when the client and server are started.)
Client1 (Raspi) 10.8.0.10
root@voip-pi:/etc/openvpn# ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.6 P-t-P:10.8.0.10 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
root@voip-pi:/etc/openvpn# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0 10.8.0.1 10.8.0.9 255.255.255.255 UGH 0 0 0 tun0 10.8.0.9 * 255.255.255.255 UH 0 0 0 tun0 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 root@voip-pi:/etc/openvpn#
Client2 (CentOS 5.3) 10.8.0.14
[root@kb9mwr ~]# ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.14 P-t-P:10.8.0.13 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:5 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:596 (596.0 b)
[root@kb9mwr ~]# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 10.8.0.1 10.8.0.13 255.255.255.255 UGH 0 0 0 tun0 10.8.0.13 * 255.255.255.255 UH 0 0 0 tun0 192.168.1.0 * 255.255.255.0 U 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth0 default router.localdom 0.0.0.0 UG 0 0 0 eth0
Server (automatic) 10.8.0.1
root@darkpi-ice:/var/www/keys# ifconfig tun0 tun0 Link encap:UNSPEC HWaddr 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00 inet addr:10.8.0.1 P-t-P:10.8.0.2 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:2 errors:0 dropped:0 overruns:0 frame:0 TX packets:2 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:168 (168.0 B) TX bytes:168 (168.0 B) root@darkpi-ice:/etc/openvpn# route Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface default CPE-75-87-208-1 0.0.0.0 UG 0 0 0 eth0 10.8.0.0 10.8.0.2 255.255.255.0 UG 0 0 0 tun0 10.8.0.2 * 255.255.255.255 UH 0 0 0 tun0 75.87.208.0 * 255.255.240.0 U 0 0 0 eth0 root@darkpi-ice:/etc/openvpn#
To determine IP's check the servers log: (also see ipp.txt)
root@darkpi-ice:/etc/openvpn# more openvpn-status.log OpenVPN CLIENT LIST Updated,Sat Apr 27 00:37:55 2013 Common Name,Real Address,Bytes Received,Bytes Sent,Connected Since client2,174.103.199.16:52479,11312,11104,Sat Apr 27 00:22:42 2013 client1,174.103.199.16:48728,14393,15682,Sat Apr 27 00:16:32 2013 ROUTING TABLE Virtual Address,Common Name,Real Address,Last Ref 10.8.0.14,client2,174.103.199.16:52479,Sat Apr 27 00:36:16 2013 10.8.0.10,client1,174.103.199.16:48728,Sat Apr 27 00:37:44 2013 GLOBAL STATS Max bcast/mcast queue length,0 END