Description of problem:

The patch being carried in the openswan RPM for case #600174 appears to be incorrect as it is causing nonsense addresses to be added to one of my interfaces.

Our setup has 172.16.0.0/16 as the local network and 172.19.0.0/16 as a remote network that we are establishing a tunnel to. The configuration looks like:

        left=xxx
        leftnexthop=xxx
        leftsubnet=172.16.0.0/16 
        leftsourceip=172.16.1.1
        right=xxx
        rightsubnet=172.19.0.0/16

There is (obviously) an existing route to 172.16.0.0/16 via eth0 and the external traffic is via teql0.

The leftsourceip clause is just there to set the source address on the route to the remote network, so that the endpoint can talk to the network, but the patch for #600174 is causing a 172.16.1.1/16 address and corresponding route to be added to the external interface which means we have two routes for the local network, one going out the wrong interface.

My guess is that, even if it is correct to add a subnet address rather than a /32 address in the updown script, you still need to first check that there isn't already a valid route, as the upstream code does.

Version-Release number of selected component (if applicable):

openswan-2.6.32-1.fc15.x86_64

How reproducible:

Every time I start openswan.

Steps to Reproduce:

1. Setup an appropriate connection
2. Start openswan
3. Notice that a bogus address and route have appeared
  
Actual results:

Bogus address and route added.

Expected results:

Bogus address and route are not added.