[Openswan dev] Feature request - routing

[Erik Carlseen]

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 
the tunnel.

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,

Erik Carlseen
Praecelsus Consulting, Inc.