[Openswan Users] Problems with routing on Openswan 2.3

Ken Farnen kenf at 14cubed.com
Wed Feb 16 13:32:50 CET 2005

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 -, subnet
on the interface is, address is
eth1: connects to internet via NAT-ed ADSL link (faster!) - public addresses
are - address
eth2: connects to our internal network, which uses a subnet of our public
class C, - address
eth3: connects to our wireless segment, which we trust for naught, and has - address

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"

conn %default
        #Use RSA and certificates
        #[L]eft is LOCAL - this side of the tunnel

The Roaming config
conn wifi-fcl

#The ADSL Roaming config

conn adsl-fcl

------------------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 ( 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 connects
from the WiFi segment, it tries to add " via dev
ipsec0" - which fails, as 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 via 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
( in the example above) to that table, and a catch-all "throw" 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


More information about the Users mailing list