- CIPE is a lightweight software to create VPN's.
- If you are happy to use Cipe (1.4.x) that comes with RH 9.0, then don't use this step.
I wanted to try out the latest cipe verion (1.5.4) on RH 9.0 system. The rpm for this was not
available at the time of writing. Hence I tried compiling from
from the tarball available on the CIPE website. Everything went off well, except for the occasional error:
--SNIP-- ../cipe/device.c: In function `cipe_owner': ../cipe/device.c:223: structure has no member named `next_task' gmake[1]: *** [device.o] Error 1 gmake[1]: Leaving directory `/home/ronb/cipe-1.5.4/2.4.20-6custom- --SNIP--
This can be resolved by using modifying the $cipe_dir/cipe/device.c (line 223) as://p=p->next_task; //comment this out next_task(p); //Add this line
Also cipe 1.5.4 requires a kernel module compiled with the same compiler as the kernel (or some such weird requirement). Thus to use cipe 1.5.4, I had to download a stock kernel from kernel.org, and compile it using the steps given here. I did this only on mia. Thus mia uses cipe (1.5.4) and zidler uses cipe 1.4.5. - You can find lots of useful instructions in the online manual.
- All instructions from now onwards will assume that cipe is up and running.
- I am asssuming that we are using the following setup. mia
as the client and zidler as the server .
- If you are using the cipe version that comes with a fresh RH distro, then u need to copy some files.
Do the following:
shashank@mia:~> rpm -qil cipe Name : cipe Relocations: (not relocateable) Version : 1.4.5 Vendor: Red Hat, Inc. Release : 16 Build Date: Mon Feb 24 16:34:14 2003 Install Date: Thu May 29 15:35:31 2003 Build Host: sylvester.devel.redhat.com Group : System Environment/Daemons Source RPM: cipe-1.4.5-16.src.rpm Size : 74826 License: GPL Signature : DSA/SHA1, Mon Feb 24 18:04:12 2003, Key ID 219180cddb42a60e Packager : Red Hat, Inc.
Copy the files /usr/share/doc/cipe-1.4.5/samples/options to /etc/cipe/options.cipcb0. This has to be done on both the client and server. (Though there is no such thing as client and server in cipe). - I have used two different approaches to start the cipe'd tunnel. In my first approach, I start ciped-cb
from the command line, while in my second approach, I use the network scripts to bring up and tear down the
cipe tunnel. The second approach is much better, but for initial learning purpose, you might consider using the
first approach.
- STARTING ciped-cb FROM THE COMMAND LINE:
-
On MIA one should have the following options in /etc/cipe/options.cicpcb0:
[shashank@mia cipe]# cat options.cipcb0 ptpaddr 192.168.254.201 #Peer address of server after VPN is established. ipaddr 192.168.254.200 #My address after vpn is established. me 131.193.50.165:55555 #My public Internet Address and port (for incoming VPN connections) peer 131.193.50.184:55555 #Public Address of VPN server:port that I wish to connect. #ipup /etc/cipe/ip-up #Script to execute after the VPN is established. #ipdown /etc/cipe/ip-down #Script to execute after VPN is torn down. key f0....938dba607caf664bb83444QQee #128-bit secret key generated as shown below. arg 192.168.2.0 #Argument to be passed to ipup and ipdown scripts.
Similarly on ZIDLER we have the following options in /etc/cipe/options.cicpcb0 :shashank@zidler:/etc/cipe# cat options.cipcb0 ptpaddr 192.168.254.200 ipaddr 192.168.254.201 me 131.193.50.184:55555 peer 131.193.50.165:55555 #maxerr -1 #ipup /etc/cipe/ip-up #ipdown /etc/cipe/ip-down key f06742938dba607caf664bb8344415ee arg 192.168.0.0
NOTE: The reversal of IP addresses. - Use the following command to generate the 128 bit key.
[shashank@mia cipe]# ps -auxw | md5sum ad4436734feffdf32700f7d5411575b3 -
DO NOT COPY THE LAST "-". Only copy the first 32 characters (128 bits). In this case "ad4436734feffdf32700f7d5411575b3" to the key field - Change the /etc/cipe/ip-up script, so that it will automatically add routes to remote network.
Note, how the ip-up script calls the ip-up.local at the end. This script can be used for adding
configurations for firewall and other stuff. This will be explained in more detail later.
At this time, keep the ip-up.local script empty.
#!/bin/sh # ip-up
Similarly, change the ip-down script to remove the routes from the routing tables: Again note the ip-down.local script that is invoked at the end of this script# Sample of the ip-up script. # This is called when the CIPE interface is opened. # Arguments: # $1 interface the CIPE interface # $2 myaddr our UDP address # $3 daemon-pid the daemon's process ID # $4 local IP address of our CIPE device # $5 remote IP address of the remote CIPE device # $6 arg argument supplied via options # Purposes for this script: set up routes, set up proxy-arps, etc. # start daemons, logging... umask 022 PATH=/sbin:/bin:/usr/sbin:/usr/bin # If this becomes our default route... #route add default gw $5 # SK Add route to peer's network route add -net $6 gw $5 netmask 255.255.255.0 # just a logging example now=`date "+%b %d %T"` echo "$now UP $*" >> /var/log/cipe.log # many systems like these pid files echo $3 > /var/run/$1.pid # Trigger the key exchange procedure, useful when we're using SOCKS # This _must_ run delayed and in the background #(sleep 10; ping -c5 $5) & # If the system runs gated, tell it what has happened #gdc interface # The following are just ideas for further consideration # Interconnect two 10. subnets through the Internet! # Assuming $4 is in 10.1 and $5 in 10.2 #route add -net 10.2.0.0 netmask 255.255.0.0 gw $5 # Proxy-ARP the peer's address on eth0 #arp -i eth0 -Ds $5 eth0 pub # Evil tricks department: masquerade the CIPE peer's /24 network to our IP #NA=`expr $5 : '\([0-9]*\.[0-9]*\.[0-9]*\.\)'` #ipfwadm -F -a accept -m -b -S $NA.0/24 -D 0.0.0.0/0 # the usual way for this would be a case selection on $5 or $6, however # execute anything local [ -x /etc/cipe/ip-up.local ] && /etc/cipe/ip-up.local $* exit 0 #!/bin/sh # ip-down
Do the same on the server too.# Sample of the ip-down script. # This is called with the same arguments as ip-up after the device was # closed. It can be used for removing proxyarps, or (like here) # for logging purposes, etc. umask 022 PATH=/sbin:/bin:/usr/sbin:/usr/bin # SK Add route to peer's network route del -net $6 gw $5 netmask 255.255.255.0 # Logging example now=`date "+%b %d %T"` echo "$now DOWN $*" >> /var/log/cipe.log # remove the daemon pid file rm -f /var/run/$1.pid # If the system runs gated, tell it what has happened #gdc interface # execute anything local [ -x /etc/cipe/ip-down.local ] && /etc/cipe/ip-down.local $* exit 0 - Now execute the following command at the client and server:
(Note to myself: I have installed 1.5.4 from a tarball on mia, since earlier i built a stock kernel and which, I guess does not come with the necessary modules for cipe. I think the RedHat distro comes with the cipe specific module. Hence it becomes easy to to install from RPM. Anyway, on mia, if I am using kernel -2.4.20, I have to use the /usr/local/sbin/ciped-cb instead of /usr/sbin/ciped-cb.)shashank@zidler:/etc/cipe# /usr/sbin/ciped-cb -o /etc/cipe/options.cipcb0
IT IS VERY IMPORTANT TO GIVE THE FULL PATH NAMES. RELATIVE PATHS WILL NOT BE ACCEPTED. - Check if the interface has come up using
[shashank@mia cipe]# ifconfig cipcb0 Link encap:IPIP Tunnel HWaddr inet addr:192.168.254.200 P-t-P:192.168.254.201 Mask:255.255.255.255 UP POINTOPOINT NOTRAILERS RUNNING NOARP MTU:1442 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) - Also check if the routes have been established properly using netstat -rn commad and ping.
- To take down the connections use the following command on both mia and zidler.
shashank@zidler:/etc/cipe# ifconfig cipcb0 down
-
On MIA one should have the following options in /etc/cipe/options.cicpcb0:
- STARTING CIPE USING THE NETWORK CONFIGURATION SCRIPTS
- In RH 9.0, files that specify configuration for your network devices are kepts in
/etc/sysconfig/network-scripts/ directory under the name ifcfg-*. In our case, since we will
be using the network device cipcb0, we have to have the configuration file
/etc/etc/sysconfig/network-scripts/ifcfg-cipcb0, which looks like below(on both server and client):
shashank@zidler:/etc/sysconfig/network-scripts# cat ifcfg-cipcb0 DEVICE=cipcb0 #device that we are using ONBOOT=no #I don't want this device to be activated on boot USERCTL=no #Only root has control of turning this device on/off PEER=131.193.50.165:66666 #Peer public IP address. PTPADDR=192.168.254.200 #Peer private IP address IPADDR=192.168.254.201 #My own private IP address PEERDNS=no #Peer will not serve as a DNS server TYPE=CIPE #?? ME=131.193.50.184:66666 #My Own public IP address. ------------------------------------------------------------------- [shashank@mia network-scripts]# cat ifcfg-cipcb0 DEVICE=cipcb0 #device that we are using ONBOOT=no #I don't want this device to be activated on boot USERCTL=no #Only root has control of turning this device on/off PEER=131.193.50.184:66666 #Peer public IP address. PTPADDR=192.168.254.201 #Peer private IP address IPADDR=192.168.254.200 #My own private IP address PEERDNS=no #Peer will not serve as a DNS server TYPE=CIPE #?? ME=131.193.50.165:66666 #My Own public IP address.
Note the reversal of IP addresses. - Since most of the options have been specified in the above file, the /etc/cipe/options.cipcb0 has few options left.
Below I have produced them for server/client:
shashank@zidler:/etc/cipe# cat options.cipcb0 #ipup /etc/cipe/ip-up #ipdown /etc/cipe/ip-down #maxerr -1 key f06742938dba607caf664bb8344415ee arg 192.168.0.0 ------------------------------------------------- [shashank@mia:/etc/cipe]# cat options.cipcb0 #ipup /etc/cipe/ip-up #ipdown /etc/cipe/ip-down #maxerr -1 key f06742938dba607caf664bb8344415ee arg 192.168.2.0
- Generate the key in the same way as explained in the first approach:
Use the following command to generate the 128 bit key.
[shashank@mia cipe]# ps -auxw | md5sum ad4436734feffdf32700f7d5411575b3 -
DO NOT COPY THE LAST "-". Only copy the first 32 characters (128 bits). In this case "ad4436734feffdf32700f7d5411575b3" to the key field - Start the tunnel using the command (on both client and server):
[shashank@zidler cipe]# ifup cipcb0
- NOTE THAT: when you use the network configuration scripts, all options are read from /etc/cipe/options.$DEVICE or /etc/cipe/options.cipcb0 (in our case) and NOT FROM /etc/cipe/options.
- Check if the interface has come up using
[shashank@mia cipe]# ifconfig cipcb0 Link encap:IPIP Tunnel HWaddr inet addr:192.168.254.200 P-t-P:192.168.254.201 Mask:255.255.255.255 UP POINTOPOINT NOTRAILERS RUNNING NOARP MTU:1442 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) - Also check if the routes have been established properly using netstat -rn commad and ping.
- The interface can be bought down using the command
[shashank@zidler cipe]# ifdown cipcb0
- In RH 9.0, files that specify configuration for your network devices are kepts in
/etc/sysconfig/network-scripts/ directory under the name ifcfg-*. In our case, since we will
be using the network device cipcb0, we have to have the configuration file
/etc/etc/sysconfig/network-scripts/ifcfg-cipcb0, which looks like below(on both server and client):
- STARTING ciped-cb FROM THE COMMAND LINE:
- All logs can be checked in either /var/log/messages or /var/log/cipe.log. (If you have specified a seperate file in sysconf, then check that. Most probably you haven't).
- There is a utility call pkcipe, which can be used with public keys. But I will experiment with it later, but it appears that it doesn't do much.
- You might consder upgrading your iptables ruleset to allow cipe connections to pass through.
This can be done by adding commands to the /etc/cipe/ip-up.local and /etc/cipe/ip-down.local scripts that
are invoked at the begining and end of a cipe tunnel. Below I am reproducing the ruleset suggested by
Phil Scarratt (though it will need tweaking to fit individual needs.
For a great tutorial on iptables refer to
Oskar Andreasson's page).
I have not yet verified the below rules yet, and when i do this line will be removed.
########## /etc/cipe/ip-up.local ########## #!/bin/sh # ip-up.local # This is called when the CIPE interface is opened. # Arguments: # $1 interface the CIPE interface # $2 myaddr our UDP address # $3 daemon-pid the daemon's process ID # $4 local IP address of our CIPE device # $5 remote IP address of the remote CIPE device # $6 arg argument supplied via options MY_CIPE_PORT=`expr $2 : '[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*:\([0-9]*\)'` IFACE_LAN='eth0' IFACE_NET='ppp0' iptables -I INPUT -i $IFACE_NET -p udp --dport $MY_CIPE_PORT -j ACCEPT iptables -I INPUT -i $1 -j ACCEPT iptables -I OUTPUT -o $1 -j ACCEPT iptables -I FORWARD -i $1 -o $IFACE_LAN -s $5 -j ACCEPT exit 0 ########## end of /etc/cipe/ip-up.local ########## ------------------------------------------------------------------------ ########## /etc/cipe/ip-down.local ########## #!/bin/sh # ip-down.local # This is called when the CIPE interface is opened. # Arguments: # $1 interface the CIPE interface # $2 myaddr our UDP address # $3 daemon-pid the daemon's process ID # $4 local IP address of our CIPE device # $5 remote IP address of the remote CIPE device # $6 arg argument supplied via options MY_CIPE_PORT=`expr $2 : '[0-9]*\.[0-9]*\.[0-9]*\.[0-9]*:\([0-9]*\)'` IFACE_LAN='eth0' IFACE_NET='ppp0' iptables -D INPUT -i $IFACE_NET -p udp --dport $MY_CIPE_PORT -j ACCEPT iptables -D INPUT -i $1 -j ACCEPT iptables -D OUTPUT -o $1 -j ACCEPT iptables -D FORWARD -i $1 -o $IFACE_LAN -s $5 -j ACCEPT exit 0 ########## end of /etc/cipe/ip-down.local ##########
- The below diagram traces the path taken by a packet as it travels over the cipe formed UDP tunnel.
- Each layer of protocol adds some bytes of overhead. This is illustrated in the above diagram.
The cipe daemon bundles a packet as:
8-byte IV (Initialization Vector) n1-byte payload; n2-byte (0-7 Byte) random padding; to make [payload + padding + padding_len + CRC] a multiple of block_size used by the cipher(blowfish or Idea). 1-byte Padding Length. 4-byte CRC calculate over [payload + padding + padding_len] - Only the blowfish (blocksize 8) and IDEA (blocksize 8) ciphers are supported. However, if you want to just use a NULL cipher, you can do so be sypecifying the nokey option in /etc/cipe/options.cipcb0 file.
- Let us assume that we are using blowfish. Suppose that the input to the CIPE daemon is
a packet of length 128 bytes, then you can calculate the total overhead added by CIPE as follows:
- Just add 1(padding_len) + 4 (CRC) = 5 Bytes to 128, giving 133.
- Find out what block size is used by the cipher. In our case, since we are using blowfish the block size is 8 Bytes.
- Calculate 133 % 8 = 5. Hence in order to make the packet an even multiple of 8, you will have to add 3 bytes of padding.
- Now add 8 bytes of IV to the sum to get the total packet length.
- Thus we conclude that the Cipe daemon adds a minimum of (8(IV) + 0(padding) + 1(padding_len) + 4(CRC) = 13 bytes) and maximum of (8(IV) + 7(padding) + 1(padding_len) + 4(CRC) = 20 bytes
- We conducted a series of experiments with varying application input sizes.
The input data for this experiment was totally random.
An example of such data is shown below:
seq_no: 0 Y%*i%|\NU]\Dw-5jOba4Q@D8`?5t#"iBFna^M1OF)t?6++f)m6ZIR:aOY3EvO1Tu!7UhI&0R6O%\uked#BIpvGARZfd+3; "Olq9Q3J@J5E(,2m,5KVA^}bLse2 4gcVI}C\ccB4*J[VTg(;YIyr.Gg/Z#C]Y)OBs{AXYU}&2Ut6w1+CG kn#zdA?D6H/ U&$lGwG9vgeg]7a+C@R]-\z)]=b=nGLEMQ31dtJ\^K_Wc\b(|Pe+I{N(;3EEtqjC^9nD/:)"|aeZ_)s2n ['i}\8D#.7)k2B\Vl2su4qThis data was generated using modudpgen, a synonym for Modified UDP generator and sniffed using ethereal.
The results are presented below: It is observed that the UDP/IP/link layer headers, in our application amount to a total of 70 Bytes (UDP (8) + IP (20) + UDP (8) + IP(20) + Ethernet (14)) , which is fixed. The rest is the overhead attached by the Cipe Daemon.-------------------------------------------------------- Application Data Data on wire Overhead (No comp) -------------------------------------------------------- 100 186 86 275 363 88 350 434 84 502 586 84 613 698 85 750 834 84 849 938 89 917 1002 85 1010 1098 88 1200 1290 90 -------------------------------------------------------- Average Overhead: 86.3 --------------------------------------------------------
- CIPE does not support compression of any kind. Hence average overhead with compression is the same as that without compression.
- Cipe formed VPN tunnels, do not have inbuilt routing mechanisms. As a result the user
has to take care of establishing routes to remote networks. This can be done in the following two ways:
- Static routes can be set up within the script itself (as we have done) using the command:
route add -net network/netmask gw gateway-ip
Although this method is simple for small networks, it becomes exceedingly difficult to maintain such routes one your network reaches a decent size (> 5 nodes, say). Hence one should avoid using this method, unless you have a very small network. - Another way is to use a routing software that will set up/tear down the routes automatically. One such software to consider is Gnu Zebra with one of its components: OSPF. At the time of this writing, I could not find much documentation on how to configure zebra, and since I was not working with any complex network architectures, I preferred to use the first method. However, I do plan to include the steps to set up zebra in future.
- Static routes can be set up within the script itself (as we have done) using the command:
- Cipe does not support any cipher algorithms other than blowfish and IDEA. Also it does not use a MAC or compression algorithm. Hence if one needs to add proprietary algorithms to cipe formed tunnels, then he/she has to hack the source code.
- The Cipe solution for forming VPN's is highly unscalable. (This may not be true)
- For e.g. If a company has 'N' different sites, then it would be necessary to have O(N^2) point-to-point PPP-over-SSH links and each site will have to maintain an entry in the routing table for (N-1) other sites. I think a full mesh will be necessary in this case, as the complexity of maintaining any other network infrastructure will be prohibitively high.