IPsec-Tools Checklist

SourceForge.net Logo
IP Forwarding is on
your box will serve as gateway for other boxes? if not - skip it.
# cat /proc/sys/net/ipv4/ip_forward
Dito IPv6, if you use it
Clients can talk with gateway
from client ping gateway and get responce
Gateway can talk to other gateway
In general, any method which shows that packets could go to other gateway and return back is good. Depending on firewall rules some of the following methods may not work. But you should achieve for at least one of them to work.
Kernel has af_key/ esp/ ah/ ipcomp compiled-in/loaded as module
How do we check this?
ipsec-tools are recent enought
for kernels 2.6.10 and up, you have to use ipsec-tools version 0.5.rc1 or later;
0.4 or later is recomended
$ setkey -V
setkey 0.3.3 http://ipsec-tools.sourceforge.net
If you get error messages - you are using version earlier than 0.3.3
ESP/ AH/ IPComp is not firewalled
Below is minimal list of rules what are needed for IPSec to work. Ensure that they are placed high enought and are not blocked by earlier rules.
  1. iptables -A INPUT -p udp -s other-gateway -d my-external-address --dport 500 --j ACCEPT (for IKE traffic)
  2. iptables -A INPUT -p udp -s other-gateway -d my-external-address --dport 4500 --j ACCEPT (extra port for IKE traffic if you will use NAT-T)
  3. iptables -A INPUT -p esp -s other-gateway -d my-external-address -j ACCEPT (if outermost packet will be ESP)
  4. iptables -A INPUT -p ah -s other-gateway -d my-external-address -j ACCEPT (if outermost packet will be AH)
  5. the same for OUTPUT, just arguments for -s and -d swaped, and --dport changed to --sport
Anything missing? forwarding of traffic to be encapsulated/decapsulated?
ESP/ AH/ IPComp traffic is not NATed/ Masqueraded at gateway
if you do SNAT/ DNAT/ MASQUERADE on gateway, insert rules which allow to pass through protocols you intend to use (esp=50, ah=51) before rules with -j SNAT/ DNAT/ MASQUERADE.
iptables -t nat -I POSTROUTING 1 -p 50 -j ACCEPT
Policies are added into SPD
There should be 2 rules -- one in and one out for every pair of network objects you want to secure traffic.
$ setkey -DP|less[any][any] any
        in ipsec
        created: Mar 21 20:53:50 2004  lastused:                     
        lifetime: 0(s) validtime: 0(s)
        spid=96 seq=7 pid=12159
        refcnt=1[any][any] any
        out ipsec
        created: Mar 21 20:53:50 2004  lastused:                     
        lifetime: 0(s) validtime: 0(s)
        spid=89 seq=6 pid=12159
Parameters in the policies are in right order
order of parameters and direction are very important!
remote_object local_object -P in ipsec esp/tunnel/remote_gw-local_gw/unique;
local_object remote_object -P out ipsec esp/tunnel/local_gw-remote_gw/unique;
racoon is running
$ ps ax|grep racoon|grep -v grep|wc -l
gateway's traffic goes from secure interface
This could be achieved by routing local traffic via internal (secure) interface:
ip route add other.network/mask via default.gw src gateway's.private.addr
or alternatively, it is possible to set up extra policies for gateway-remote_networks, gateway-gateway and local_networks-gateway traffic.
kernel requests racoon to negotiate SA
racoon is negotiating Phase 1
racoon is negotiating Phase 2
tcpdump shows plain text traffic!
If you tcpdump on gateway, and you see both incoming ipsec packets and incoming plain text packets - it is normal behavior.
In linux incoming ipsec packets enters interface, ipsec headers are checked and removed and plain text packet enters kernel code one more time as if it just come from network hardware. This is why tcpdump shows it twice.
To be sure, sniff traffic from third box in between of security gateways and you will see just encapsulated traffic!
FreeS/WAN: traffic for just one of many policies go through
FreeS/WAN requires different SA for every policy/tunnel.
Change require to unique in your policies.