[Openswan Users] OpenSWAN on OpenWRT not working

[Paul Wouters]

On Tue, 13 Feb 2007, Nels Lindquist wrote:

> Subject: [Openswan Users] OpenSWAN on OpenWRT not working

> Anyway, I'm trying to use the OpenSWAN package distributed with OpenWRT
> WhiteRussian RC6, connecting to a standard Linux installation of
> OpenSWAN on the other end.

I went to whiterussian 0.9, but R6 should work fine too:

 WHITE RUSSIAN (0.9) -------------------------------
  * 2 oz Vodka   Mix the Vodka and Kahlua together
  * 1 oz Kahlua  over ice, then float the cream or
  * 1/2oz cream  milk on the top.
 ---------------------------------------------------
root at OpenWrt:~# ipsec --version
Linux Openswan 2.4.6 (klips)


> Everything looks like it's configured properly--though I can't run
> "ipsec verify" due to the lack of exec support.

Rather, perl not being installed on openwrt. ipsec verify is a perl
script.

> Nevertheless, certs are loaded, tunnels come up, routes are created, and
>  then... nothing.  No packets are sent out over the ipsec0 interface at
> all.  Using tcpdump I can see them come in to the internal interface,
> but nothing goes out at all.
>
> I tried eliminating the firewall as a potential blocker by flushing all
> the rules, to no avail. ip_forward is set.

I always remove all the DROP rules from their configs. I don't need a
firewall :P

Did you change the MASQ rule to exclude MASQ'ing ipsec destined packets?

openwrt comes with:
	iptables -t nat -A POSTROUTING -j postrouting_rule
	iptables -t nat -A POSTROUTING -o $WAN -j MASQUERADE -s 192.168.1.0/24
which will kill your tunnels. Do something like:
	iptables -t nat -A POSTROUTING -j postrouting_rule
	iptables -t nat -A POSTROUTING -o $WAN -j RETURN -s 192.168.1.0/24 -d remote_lan1/24
	iptables -t nat -A POSTROUTING -o $WAN -j RETURN -s 192.168.1.0/24 -d remote_lan2/24
	iptables -t nat -A POSTROUTING -o $WAN -j MASQUERADE -s 192.168.1.0/24

> Has anyone gotten this configuration to work?

Yes:

root at OpenWrt:~# ipsec eroute
167206     193.110.157.16/28  -> 0.0.0.0/0          => tun0x100a at 194.109.7.250
201        193.110.157.16/28  -> 10.112.44.0/24     => tun0x101a at 24.36.180.146
0          193.110.157.16/28  -> 192.168.88.0/24    => tun0x101c at 74.101.114.221

> I'm hoping I'm missing something silly and obvious.  I've attached a barf.

Lets have a look:

Unable to find KLIPS messages

so since there is no proper syslog, add to config setup in ipsec.conf:

	plutostderrlog=/tmp/pluto.log

then i see:

Kernel IP routing table
Destination     Gateway         Genmask         Flags   MSS Window  irtt Iface
192.168.53.0    0.0.0.0         255.255.255.0   U         0 0          0 br0
192.168.50.0    0.0.0.0         255.255.255.0   U         0 0          0 ipsec0
192.168.60.0    0.0.0.0         255.255.255.0   U         0 0          0 vlan1
192.168.60.0    0.0.0.0         255.255.255.0   U         0 0          0 ipsec0
0.0.0.0         192.168.60.1    0.0.0.0         UG        0 0          0 vlan1

I noticed too that a false route is inserted. This caused packets to loop and
get dropped by klips. try: route del 192.168.60.0 dev ipsec0

Other then that, I saw no problems in the barf.

Paul