[Openswan dev] Feature request - routing

[John A. Sullivan III]

On Tue, 2004-08-24 at 17:54, Erik Carlseen wrote:
> 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.
<snip>
I would appreciate your feedback on this for the ISCS project
(http://iscs.sourceforge.net).  ISCS looks at the entire environment and
then produces a complete and consistent set of rules for all the various
subsystems including iptables, *swan and iproute2.  The nice thing about
such a model is that the user can be presented with a relatively simple
screen that may then compile in the background to a rather complicated
interdependent list of *swan, iproute2 and iptables rules.

We're currently finishing the Resources logic and the very next module
is the logic for configuring the routes, VPNs and network interfaces on
the gateways.  There is already an option to set a metric for an
indirectly connected route and there are choices of which public
interface to use for the VPN and, separately, for Internet traffic. 
Perhaps you could suggest a slight change to the user interface to
enable what you want and then we can figure out how to consistently
reproduce it on any ISCS managed gateways.  Take care - John
-- 
John A. Sullivan III
Open Source Development Corporation
Financially sustainable open source development
http://www.opensourcedevel.com