[Openswan Users] Problems with routing on Openswan 2.3

[Ken Farnen]

A little help please - we're trying to set up OpenSwan 2.3 on our already
busy firewall server, and I'm having trouble getting it to install the
correct routes:

the (anonymised) network config:

Firewall has 4 interfaces:

eth0: connects to internet via our public class C - 158.152.1.0/24, subnet
on the interface is 158.152.1.248/29, address is 158.152.1.253
eth1: connects to internet via NAT-ed ADSL link (faster!) - public addresses
are 20.51.52.48/28 - address 20.51.52.49
eth2: connects to our internal network, which uses a subnet of our public
class C, 158.152.1.0/26 - address 158.152.1.1
eth3: connects to our wireless segment, which we trust for naught, and has
158.152.1.224/28 - address 158.152.1.225

Firewall is called huey (primary interface is eth2, huey.14Cubed.COM)

ADSL interface is called louie - this is where we are directing the VPN
traffic to.

We want to allow VPN connections from the ADSL side (for homeworkers and
raod-warriors) and connections from thw WiFi side to allow secure access to
the internal servers for WiFi users.

Our (anonymised) config:

version 2.0     # conforms to second version of ipsec.conf specification

# basic configuration
config setup

        interfaces="ipsec0=eth1 ipsec1=eth3"
        klipsdebug=all
        plutodebug=all
        #nat_traversal=yes
        #plutoload=%search
        #uniqueids=no
        myid=@louie.14Cubed.COM


conn %default
        #Use RSA and certificates
        authby=rsasig
        keyingtries=0
        leftid=@louie.14Cubed.COM
        rightrsasigkey=%cert
        leftrsasigkey=%cert
        #[L]eft is LOCAL - this side of the tunnel
        #left=20.51.52.49
        leftcert=louie.14Cubed.COM.pem
        ike=3des-sha,3des-md5,aes-sha
        esp=3des-sha1,3des-md5,aes-sha1
        auto=add

The Roaming config
conn wifi-fcl
        type=tunnel
        auth=esp
        authby=rsasig
        left=158.152.1.225
        leftnexthop=%direct
        right=%any
        rightsubnetwithin=158.152.1.224/28
        leftsubnet=158.152.1.0/26
        disablearrivalcheck=yes

#The ADSL Roaming config

conn adsl-fcl
        type=tunnel
        auth=esp
        authby=rsasig
        left=20.51.52.49
        leftnexthop=%direct
        right=%any
        rightsubnetwithin=0.0.0.0/0
        rightnexthop=20.51.52.49
        leftsubnet=158.152.1.0/26
        disablearrivalcheck=yes


------------------END CONFIG-----

So, after some interesting learning experiences, we have IKE working with
public keys, and can issue certs from our new CA, and authenticate with
them.  However, not all is well in VPN-land - our problems:

1.  Try as we might, we cannot get the WiFi and the ADSL traffic to use two
different connections!  In the config above, all users end up being auth-ed
against "conn adsl-fcl" - What have I mssed?  I've tried getting the WiFi
users to use the GW on their local I/F (158.152.1.225) but it either doesn't
auth, or decides to use conn-adsl - how can you get this to work?

2.  the _updown script isn't adding the right routes.  Regardless of how I
fiddle with [right/left]nexthop, the script always tries to create a route
with the via being the remote security GW (e.g. if 158.152.1.235 connects
from the WiFi segment, it tries to add "158.152.1.235 via 158.152.1.235 dev
ipsec0" - which fails, as 158.152.1.235 is not within the subnet for that
interface.  For a roadwarrior it is even worse, and the routing it is trying
to add is sometimes for private subnet blocks!  If I manually add the route
as 158.152.1.235 via 20.51.52.49 dev ipsec0, everything works - and I've
hacked the script to set the via to $PLUTO_ME instead of $PLUTO_NEXT_HOP,
which works, but I don't understand why I need to do that, so I think I'm
probably missing something.

3.  Given the network config, you will not be surprised to learn that we are
ALREADY using policy routing to selectively direct traffic between the two
internet links, and so I'm very interested in the interactions between my
current config and the routes that the VPN installs.  Here's what I've noted
so far:

3a: the ipsec[0-9] interfaces do not seem to like traffic with the fwmark
set.  I'm using netfilter mangle tables together with policy routing to
classify traffic, and if I do not set the fwmark back to 0 in the
POSTROUTING chain, all my outbound packets dissapear.  Is this intentional?

3b: I've noticed that the _updown script has some neat policy routing stuff
that is not currently referenced.  Why What? When? Where? - for our config
I've installed an additional table for vpn routes, and hacked the script to
put all it's routes into that table (table "vpn").  There is then a rule
that directs all traffic for the segment we are trying to connect to
(158.152.1.0/26 in the example above) to that table, and a catch-all "throw
0.0.0.0/0" at the end.  This makes routing for the WiFi users work
(otherwise once the VPN comes up, they cannot talk to anything else BUT the
local segment, as the route Openswan installs eclipses the route that sends
out normal traffic to the eth3 interface).  However, if I could figure out
what the script was trying to achieve, I could turn this into a more generic
approach, that would save me having to hack the policy routing every time we
added a new connection.

A complex configuration to be sure, but any help would be greatly
appreciated!

Ken.