- It seem's like there is no active development on this project. However one can download the tarball from vpnd site. Installation is very easy and can be done within minutes.
- However, before using it, one should realize that the VPN daemon uses its own implementation of cipher (blowfish, CFB mode) and MAC's (MD5, SHA1 and rimpemd-160), instead of using OpenSSL's implementation. Also only static key encryption is supported, which does not scale well.
- NOTE: If you want to enable debug support, you will have to edit the configure script manually to
uncomment the line (#117):
--SNIP-- 116. echo '# uncomment the following line for debug code' 117. echo 'DEBUG=-DDEBUG' --SNIP--
- I am asssuming that we are using the following setup with mia
as the client and zidler as the server .
- I have placed all the vpnd related files in /etc/vpnd/. The defaults for many options are different. Hence, when in doubt always do vpnd -h. No man page is available.
- If you use the simple secret key method (basic-master-key-file) to acheive link encryption,
then generate the basic-master-key-file using the command (at either the client or server):
[shashank@mia vpnd]# vpnd -m /etc/vpnd/vpnd.key New key file /etc/vpnd/vpnd.key created.
Transfer this file to the peer and place it in /etc/vpnd/. - If you use the extended-master-key-file) to acheive link encryption,
then generate the extended-master-key-file using the command (at either the client or server):
shashank@mia:/etc/vpnd# vpnd -x /etc/vpnd New key file /etc/vpnd/vpnd.lcl.key created. New key file /etc/vpnd/vpnd.rmt.key created.
Keep the file vpnd.lcl.key at the local terminal and send the file vpnd.rmt.key to the peer. - Place the following configuration files at the server and the client.
To get an idea about all the functions of all available options read the
original configuration file that came with the
distribution.
shashank@zidler:/etc/vpnd# cat vpnd.conf keysize 5 keyttl 0 #keepalive 60 nocompress # threshold 512 # rxmax 5 # txmax 5 # linkup /etc/vpnd/ip-up # linkdown /etc/ip-down # # -------------------- # basic operation mode # -------------------- mode server client 0.0.0.0 22222 server 131.193.50.184 22222 keyfile /etc/vpnd/vpnd.key #keyfile /etc/vpnd/vpnd.rmt.key # hmac
[md5|sha1|ripemd160] #facility local7 # # ---------------- # SLIP parameters # ---------------- # local 192.168.254.201 remote 192.168.254.200 # mtu 1600 nocslip # autoroute # route1 192.168.0.0 255.255.255.0 192.168.254.200 # slipup /etc/vpnd.slipup # slipdown /etc/vpnd.slipdown # # # ----------------------- # serial line parameters # ----------------------- # # speed 38400 # localline # nortscts # xfilter # modemchat /etc/vpnd.chat # # ----------------- # TCP/IP parameters # ----------------- # # linktest 30 # oobfix # suspend 110 # ipopts 10 # sendbuf 4096 # connwait 30 # ------------------------------------------------- [shashank@mia vpnd]# cat vpnd.conf # ------------------ # General parameters # ------------------ # pidfile /var/run/vpnd.pid # randomdev /dev/urandom keysize 5 keyttl 0 #keepalive 60 # noanswer 3 # retry 5 nocompress # threshold 512 # rxmax 5 # txmax 5 # linkup /etc/vpnd/ip-up # linkdown /etc/ip-down # # -------------------- # basic operation mode # -------------------- mode client client 131.193.50.165 22222 server 131.193.50.184 22222 keyfile /etc/vpnd/vpnd.key #keyfile /etc/vpnd/vpnd.lcl.key # hmac [md5|sha1|ripemd160] #facility local7 # # ---------------- # SLIP parameters # ---------------- # local 192.168.254.200 remote 192.168.254.201 # mtu 1600 nocslip # autoroute # route1 192.168.2.0 255.255.255.0 192.168.254.201 # slipup /etc/vpnd.slipup # slipdown /etc/vpnd.slipdown # # # ----------------------- # serial line parameters # ----------------------- # # speed 38400 # localline # nortscts # xfilter # modemchat /etc/vpnd.chat # # ----------------- # TCP/IP parameters # ----------------- # # linktest 30 # oobfix # suspend 110 # ipopts 10 # sendbuf 4096 # connwait 30 # - Start the vpnd process at the server/client using the command: The -n option is used to keep
the process in the foreground and -d 7will print all the debug messages.
shashank@zidler:/home/shashank# vpnd -f /etc/vpnd/vpnd.conf -n -d 7 --SNIP-- ---------------------------------------------------------------- [shashank@mia vpnd]# vpnd -f /etc/vpnd/vpnd.conf -n -d 7 --SNIP--
- Check out if the slip interface has started using ifconfig:
papers@mia:> ifconfig --SNIP-- sl0 Link encap:VJ Serial Line IP inet addr:192.168.254.200 P-t-P:192.168.254.201 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 compressed:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 compressed:0 txqueuelen:10 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) - Also check if the routes have been established properly using netstat -rn command and ping.
- The interface can be disable by killing the vpnd process.
- The below diagram traces the path taken by a packet as it travels over the ppp-over-ssh tunnel.
- The TCP/IP/Ethernet layers adds known amount of header/trailer which are trivial to find out. Hence, I will not explain them here. I will concentrate only on the overhead added by the SLIP interface and VPND below.
- To find out the overhead added by SLIP, one can read the following paragraph from
RFC1055:
The SLIP protocol defines two special characters: END and ESC. END is 0xc0 and ESC is 0xdb not to be confused with the ASCII ESCape character; for the purposes of this discussion, ESC will indicate the SLIP ESC character. To send a packet, a SLIP host simply starts sending the data in the packet. If a data byte is the same code as END character, a two byte sequence of ESC and 0xdb is sent instead. If it the same as an ESC character, an two byte sequence of ESC and 0xdd is sent instead. When the last byte in the packet has been sent, an END character is then transmitted.
Thus at a minimum, the SLIP protocol adds 2 bytes of overhead. - A quick lool at the function datasend in crypto.c of the source tree for vpnd, reveals
the packet format:
m-byte MAC (message authentication code); e.g. SHA1 (20B), MD5 (16B), ripemd-160 (20B), CRC (2B) 2-byte Payload length n1-byte payload;
If you use the basic-master-key-file, then the MAC is just a 2 byte CRC. On the other hand, the extended-master-key-file allows one to use SHA1, MD5 and ripemd-160.
NOTE: No padding bytes are reqiured here, even if blowfish is a block cipher, as Cipher Feedback or CFB mode is used, which essentially converts a block cipher to stream-cipher. - Asuming no compression is used by SLIP (using noslip option) or vpnd (using nocompress option), we conducted a series of experiments. The results can be accessed here. Thus we can say that with basic-master-key-file the average overhead is 102 bytes, while with extended-master-key-file + HMAC the overhead is 120 Bytes.
- The input data for this experiment was totally random, using ASCII values from decimal 32 to 125.
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.
- As a result of this, the SLIP protocol layer could not add any extra escape sequences within the data.
However the IP header did have some charaters (2) that needed to be escaped, which increased the size of the
slip frame by 4 bytes in all our experiments. Thus if the input frame was 128 bytes, the Slip frame would be
(128 + 2(start + end flags) + 2(escape characters)) = 132 Bytes.
Now if the basic-master-key-file method was used using 2 byte CRC and 2 byte length, then the vpnd outputs a packet of (132 + 4 =) 136 bytes. Add to this the 66 bytes of TCP/IP/ethernet header and you will get a frame of 202 bytes on the wire, as confirmed by the results.
- There is a bug in the compression part of the software and it gives error whenever compression is enabled.
- Thus we were not able to experiemt with compression enabled.
- VPNd helps set up point-to-point routes. This can be helpful only if the number of nodes is small enough.
With increase in the number of nodes, we have two choices:
- 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:
- VPNd uses its own implementation for the cipher (blowfish), MAC's (MD5, SHA1, ripemd-160) and compression (zlib). Hence in order to use any propritary cipher/MAC/compression algorithm, a person will have to modify appropriate changes to the source code, which, in my opinion is very simple.
- The vpnd solution for forming VPN's is highly unscalable.
- For e.g. Static key distibution.
- 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.