IP Forwarding is on

- your box will serve as gateway for other boxes? if not - skip it.

	# cat /proc/sys/net/ipv4/ip_forward
	1

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.

• from gateway ping other gateway and get responce;
• tracepath/traceroute to other gateway and get responce at least from remote gateway's next-hop;
• get confirmation from other gateway's admin that there is no obstacles for the two gateways to communicate.

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 @(#) ipsec-tools 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
6. iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
7. iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE

Connected But Cannot Access LAN Behind The Gateway

- this is typical misconfiguration. I found this out when I build a dedicated Openswan server. This will fix the issue.

	# iptables -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
	# iptables -t nat -A POSTROUTING --out-interface eth0 -j MASQUERADE

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
	192.168.1.0/24[any] 192.168.2.0/24[any] udp
		in ipsec
		esp/transport//unique#16393
		created: Mar 11 18:10:58 2010  lastused: Mar 11 18:21:24 2010
		lifetime: 0(s) validtime: 0(s)
		spid=1264 seq=7 pid=17054
		refcnt=2
	192.168.2.0/24[any] 192.168.1.0/24[any] udp
		out ipsec
		esp/transport//unique#16393
		created: Mar 11 18:10:58 2010  lastused: Mar 11 18:20:58 2010
		lifetime: 0(s) validtime: 0(s)
		spid=1273 seq=6 pid=17054
		refcnt=2

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.

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!.