[Openswan dev] Feature request - routing
ecarlseen at praecelsus.com
Tue Aug 24 15:54:17 CEST 2004
Ladies / Gentlemen:
I've been using FreeS/WAN for a few years now, and have moved the bulk
of my systems to OpenS/WAN. There is one particular item that I've
noticed keeps rearing its ugly head during implementations, and that's
the issue of properly setting routes when tunnels are established. The
default behavior (setting a low-cost route to the destination subnet) is
all well and good for simple networks, but for more complex
implementations (eg: using the VPN as a backup link, and for extranet
partners with bizzare^H^H^H^H^H^H unusual IP address usage) it would be
nice to have more flexibility through parameters in the ipsec.conf.
Right now I work around these issues by using specially modified _updown
scripts, but this is a rather ugly hack.
Details on the first issue: VPN as a backup link.
I typically use OpenS/WAN on firewalls at remote sites for clients (yes,
I know I could simply slap a VPN / Firewall on the Cisco routers,
however, having the Linux box as the edge device has proved invaluable
due to my good friends squid, iptraf, tethereal, and tcpdump). These
remote sites have leased lines or frame relay connections that provide
the primary connection, and Internet connections for local Internet
access (reduces load on the leased line) and VPN backup. Using
Zebra/OSPF, routes are dynamically created if the leased line is running
(not always reliable, especially if the remote site is in a third-world
country or even in the US where the telcos have fired most of the
technicians with seniority^H^H^H^H^H^H IQs higher than their shoe size)
and removed if it is not. I have the VPN running in "always on" mode,
with a route cost of 1024 (an arbitrary number higher than the leased
line route cost) so that as soon as OSPF deletes the leased line route,
routing fails over to the VPN on both sides of the connection. This
works extremely well, with typical failover / recover times of 3-5
seconds. The only issue revolves around using the hacked _updown script.
It would be desirable to have a connection parameter such as
'route-cost' that one could set in the ipsec.conf file.
Details on the second issue: Strange IP address usage on the other end.
One of my extranets involves a partner (that shall remain nameless) who
has their own /16 block on the Internet (my, aren't they wasteful...
errr... special). They use the 'public' Internet addresses for hosts
inside their firewalled-off private network. Their VPN gateway is right
in the middle of this address space, so we have to essentially establish
the connection, delete the created route, and create a custom route list
that specifies the hosts and subnets we need to connect to. Again, this
is done through a hacked _updown script. Alternately, it could be done
by creating a fairly massive number of connections, but that would be
far more difficult to maintain. Yes, I know that OpenS/WAN is smart
enough to send IPSEC traffic to the correct gateway regardless of the
routing table in most cases, however, these routes are propagated via
OSPF (for redundancy purposes) and having the /16 route propagate all
over the place prevents the other sites from correctly forming tunnels
(they try to send packets through the already established VPN at another
site). In our case it's undesirable to use OSPF route filters and just
block propagation of the extranet route(s) because we allow other sites
to connect through the local VPN for redundancy purposes. This is a
somewhat confusion explanation, so here is an example: Site 'A' brings
up the VPN and a route to 172.16.0.0/16 (addresses have been changed,
obviously) is created, and propagates to sites B, C, etc. When another
site (say, 'B'), tries to bring up the tunnel, it has to connect to the
remote gateway at 172.16.82.135 (again, changed). Because the route to
172.16.0.0/16 exists, it tries to go through the existing tunnel at site
'A', which (of course) fails. A much better solution would be to have a
'route-list' parameter in the ipsec.conf file that allows one to specify
an alternate list of routed hosts / subnets that are directed through
If I'm simply being stupid with my implementations, I would welcome
alternate suggestions. I'm kind of surprised that the route cost issue
hasn't been addressed, as it seems to me to be the most efficient way to
run a backup connection (however I'm always open to new ideas if someone
has a better one). The route-list issue is more unusual, however, I can
think of some other cases where it may be desirable, as a security
measure, to use routing to control which hosts can be accessed through
the tunnel (both ways!) rather than relying strictly on packet filtering
rules (which to my shock I've found many people don't even bother with).
I'm always in favor of using multiple layers of security where possible.
I would also be willing to attempt to code these changes myself with my
rather rusty C skills, but I'm unsure of the policy of the dev group as
far as patch submissions from strange people on the Internet is
concerned, so I'd appreciate some feedback from someone who knows their
feelings regarding this.
Thanks in advance,
Praecelsus Consulting, Inc.
More information about the Dev