Chapter 4
The previous figure is of a typical LAN-to-LAN setup. The networks Sunset and Sunrise are connected by the IPsec servers East and West. South is an independent hop that involved with IPsec that can be used to SSH from East to West when its IPsec configuration has been incorrectly configured.
Pre-Flight Check
Now, before we configure our first tunnel, we have two tests that we can run to confirm that our setup should work if we configure it correctly. First we start Openswan, which is unfortunately rather distribution specific. See the following table:
Distribution |
Start command |
|
|
RedHat (and Mandrake) |
service ipsec start |
SuSE |
/sbin/rcipsec start |
Debian |
/etc/init.d/ipsec start |
Gentoo |
ipsec setup start |
|
|
The ipsec verify Command
We can now run our first pre-flight check command: ipsec verify. This command will check a few basic settings of the Linux kernel and its network configuration.
# ipsec verify |
|
Checking your system to see if IPsec got installed and started correctly: |
|
Version check and ipsec on-path |
[OK] |
Linux Openswan 2.2.0dr4 (klips) |
|
Checking for IPsec support in kernel |
[OK] |
Checking for RSA private key (/etc/ipsec.secrets) |
[OK] |
Checking that pluto is running |
[OK] |
Two or more interfaces found, checking IP forwarding |
[OK] |
Checking NAT and MASQUERADEing |
[N/A] |
Checking for 'ip' command |
[OK] |
Checking for 'iptables' command |
[OK] |
Opportunistic Encryption DNS checks: |
|
Looking for TXT in forward dns zone: west.testlab.xelerance.net |
[OK] |
Does the machine have at least one non-private address? |
[OK] |
Looking for TXT in reverse dns zone: 30.157.110.193.in-addr.arpa. |
[MISSING] |
Looking for TXT in reverse dns zone: 84.230.126.80.in-addr.arpa. |
[MISSING] |
77
Configuring IPsec
The ipsec verify command tells us that our software has been correctly set up. Our kernel supports IPsec, in this case using the KLIPS stack. The ipsec command is properly installed somewhere in the path for scripts that call it. There is at least one RSA key generated for this host, generated when the IPsec service is started.
The Gentoo startup services scheme is not yet supported by Openswan, so generating an RSA hostkey must be done manually:
# ipsec newhostkey --output /etc/ipsec.secrets
Some Gentoo distributions might expect this file to be in a subdirectory called /etc/ipsec/.
The verify command further tells us that Pluto, the Openswan IKE daemon, is running. It finds two network interfaces, which in general means that someone is trying to set up a LAN-to-LAN tunnel. For this to properly work, the kernel must be configured to use IP forwarding. If this test fails you can manually enable IP forwarding with the command:
# echo "1" > /proc/sys/net/ipv4/ip_forward
On most distributions, you can edit the /etc/sysctl.conf file and change the setting net.ipv4. ip_forward to 1. This will cause IP forwarding to be automatically enabled during the boot process.
While you are editing /etc/sysctl.conf, it is also a good idea to disable net.ipv4.conf. default.rp_filter by setting it to 0. The rp_filter setting controls the built-in spoof protection of the Linux kernel. It is a very simplistic protection that discards packets that appear to have arrived at the machine from the wrong network device, as is the case in some IP spoofing attacks. However, when using KLIPS, the packets suddenly appear from ipsec0, while rp_filter deems they should have come in on the external physical interface (for instance eth0) and concludes these packets are spoofed and the Linux kernel will thus drop them. Openswan used to warn about rp_filter when running the ipsec verify command, but this test has been removed in more recent versions because Openswan will just detect and disable rp_filter automatically.
NAT and Masquerading
The next test that the ipsec verify command performs tries to determine whether any iptables rules are present that rewrite packets. If so, it tries to determinate whether these rewriting rules would actually rewrite IPsec packets. IPsec packets may never be rewritten or mangled, as this invalidates the cryptographic signature on these packets and breaks the encrypted payload.
For instance, if we added the following (unwise!) iptables rule on West to enable NAT for its LAN network 192.0.1.0/24:
# iptables -t nat -I POSTROUTING -s 192.0.1.0/24 -j SNAT --to 193.111.228.1 -o eth0
then verify would correctly warn us that this would break the IPsec tunnel between Sunset and Sunrise:
. . .
Checking NAT and MASQUERADEing
Checking tun0x1070@193.111.228.1 from 205.150.200.209/32 to 193.111.228.1/32 [FAILED] SNAT from 192.0.1.0/24 to 0.0.0.0/0 kills tunnel 192.0.1.0/24 -> 193.111.228.1/32
. . .
78