Currently I’m exploring the world of IPsec. In a VMware test environment I’ve created CentOS5 nodes and networks to simulate secure data exchange between two private networks via a public network.
Last week I’ve succesfully created a working IPsec tunnel with use of CentOS5 and the ipsec-tools package. This document describes how to create a IPsec Network-to-Network connection. I recommend to use paragraph 22.214.171.124 to create it manualy, instead of using a GUI.
Besides ipsec-tools, CentOS5 also includes OpenSWAN in its updates repository. While trying to setup an IPsec tunnel with use of OpenSWAN I quickly ran into problems. Following this tutorial one of the first steps is to create an IPsec public key using the ipsec newhostkey command. So, on one of my VMware Centos5 hosts I ran te command:
# ipsec newhostkey --output /etc/ipsec.d/ipsec.secrets
I waited and waited, but nothing seemed to happen. It just hung. Trying to figure out the problem, I ran the command on another non-virtualized CentOS5 host without any problems. After some more debugging I found out what was causing the problem. It seems that Virtual Machines have limited resources when it comes to the /dev/random device. And this device is being used when creating keys using the command ‘ipsec newhostkey’.
In this post the problem with /dev/random within Virtual Machines is described as follows:
“The root of the problem is actually that the Linux kernel relies heavily on interrupts for generating random numbers. In a virtualized environment a Linux kernel will be unable to generate random numbers due to being unable to access the hardware.”
In the same post you can also find some solutions to solve the problem. For me the workaround is simple; I’ll just create the keys on my none virtualized Centos5 box!