[Openswan Users] Tunnel up but not routing - solved

[Tracy L Skaggs]

I hope this helps a few people.  I researched this issue for almost
three days before I put enough pieces together to solve it.

Here's the setup:

Private LAN1   ---   Linux FW   ---  Internet --- Linux FW --- Private
LAN2

Nothing fancy, nothing complete.

Initially, the two FW's were Mandrake 10.1 Official distros with each
Linux FW performing SNAT for its LAN (as well as other FW-related rules)
and was the OpenSWAN VPN endpoint for a tunnel between the two LANs.

I had this configuration working for several years and broke it when the
FW on LAN1 failed and was replaced.  The new FW had FC6 with kernel
2.6.18.

After the upgrade the tunnel would come up fine but we had an odd
asymmetric traffic flow issue.  Traffic initiated from LAN2 could get to
LAN1 and worked as expected.  However, traffic initiated from LAN1 would
fail to get to LAN2 - pings would come back with ICMP Destination Net
Unreachable errors.

I found a number of reports of similar issues on various OpenSWAN,
StrongSWAN, and other IPSEC-related sites.  None of the reported
solutions worked for me.  Many of these configurations included a
new(er) kernel 2.6.17 and above breaking a previously functional tunnel
setup.  Reports were many that there was a problem with these newer
kernels.

I tried updating the version of OpenSWAN to the latest (2.4.7) - didn't
help.
I tried reconfiguring the tunnel definitions (PSK, x509, rsasig, etc.) -
didn't help.
I tried KLIPS vs. NETKEY - didn't help.
I looked for IP protocol 4 (ipencap) traffic and modified the FW rules
to allow this traffic. - didn't help.
I found a bunch of mentions that as of kernel version 2.6.17, some
things had changed which broke IPSEC.
I ensured that I had ip_forward enabled  - didn't help.
I ensured that I had accept_redirects and send_redirects disabled on all
interfaces - didn't help

Eventually I found this blog:

http://johnleach.co.uk/words/archives/2006/11/02/243/#more-243

And from there researched changes made to netfilter and its ability (or
knowledge, or handling) of ipsec SA-related packets.  See this
discussion:

http://lists.netfilter.org/pipermail/netfilter-devel/2006-January/023130
.html

So, it isn't a bug in netfilter as the blog would indicate, nor is it a
bug in OpenSWAN (StrongSWAN, FreeSWAN, etc.), rather it is a problem
with the (apparently) common (and arguably improper) method of SNAT'ing
a small LAN with an iptables rule such as:

iptables -t nat -A POSTROUTING -o $EXTERNAL-IF -s $LAN1 -j SNAT
--to-source $EXTERNAL-IP

Because of changes to netfilter, those changes becoming part of the
2.6.17 kernel, packets which previously were NOT getting SNAT'd, do now.
Therefore, to fix this I needed to add a FW rule to explicitly get those
packets out of the netfilter chain before the SNAT rule.

I needed to add this rule before the SNAT rule:

itables -t nat -A POSTROUTING -s $LAN1 -m policy --dir out --pol ipsec
-j ACCEPT

I suppose I could also have changed the SNAT rule to something like:

iptables -t nat -A POSTROUTING -o $EXTERNAL-IF -s $LAN1 -d ! $LAN2 -j
SNAT --to-source $EXTERNAL-IP

which should NOT have matched packets which were address to the remote
side of the tunnel.

Anyway, I hope this description is clear enough to make some sense and
that it helps a few of you.

Tracy Skaggs
Director of Technical Services
DCS Computer Services