Bug 687870

Description of problem:

Fedora 14 evidently introduced an Openswan patch against the wishes of the Openswan developers that changes the meaning of the leftsourceip and rightsourceip parameters.  For the past 10+ years, these parameters were used as the source IP Address for communications with the other side of the tunnel.  But Fedora 14 broke that well known behavior by apparently introducing a new patch to assign the leftsourceip/rightsourceip IP Address to a NIC, even if another NIC is already using that IP Address.  In one of my tunnels, after an upgrade to the latest version, this patch assigned the IP Address for an internal facing NIC to an Internet facing NIC - but with the wrong mask - and took down a mission critical tunnel to a DR site for several hours until I could track down the culprit.  Imagine my surprise.  

And to vent my frustration - how am I supposed to trust Fedora from release to release if it randomly changes well known behavior of included packages with no warning and no documentation?  Whether or not somebody at Fedora believes this patch is an improvement is irrelevant - it broke the well known behavior of a package and hurt Fedora's credibility.  And it also hurt my credibility.  

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

How reproducible:
At will.

Steps to Reproduce:
1.  Set up a conn definition using an internal IP Address for leftsourceip or rightsourceip parameters.
2.  Observe the IP Address assigned to each NIC.  Note the internal IP Address assigned to the Internet facing NIC.
3.  Clean up the bad IP Address assigned to the Internet facing NIC.
4.  Comment out the leftsourceip/rightsourceip parameter in the conn definition.
4.  service ipsec restart and observe expected IP Addresses in both NICs.    

Actual results:

The Internet facing NIC is incorrectly assigned an internal IP Address, but with the wrong mask.

Expected results:

Don't screw around with IP Addresses assigned to NICs!

Additional info:

Please get rid of this patch.  Screwing around with IP Addresses in this manner is playing with fire.