[Openswan dev] openswan connections with %defaultroute with later upcoming network
avagarwa at redhat.com
Tue Jul 6 10:09:57 EDT 2010
On 07/05/2010 08:53 PM, Paul Wouters wrote:
> On Thu, 1 Jul 2010, Avesh Agarwal wrote:
> Hi Avesh,
>> I am attaching a patch that addresses Openswan issues with connection
>> loading at boot time and iptables masquerading as explained below:
> We looked at the patch, and we think the fix will have to be
> different. I talked
> it over with Hugh Redelmeier as well.
>> 1. When IP addresss for either "right" and "left" are not specified
>> explicitly in the conf file, and network is not up at the system boot
>> time (like in wireless network case), with "chkconfig ipsec on", the
>> connection is not added. And even after the network becomes up,
>> connection can not be loaded even if one does "ipsec whack --listen".
>> The reason is that those ip addresses are never resolved by pluto,
>> because "ipsec whack --listen" mainly adds the newly found network
>> interfaces, but does not resolve the addresses. So if one does "ipsec
>> auto --up <name>", the connection does not work until Openswan is
>> restarted. To fix this, I had to make following changes in the code:
>> a) Reading the network information once again and storing them into
>> /var/run/pluto/ipsec.info by using "defaultinterface()" in the file
>> b) I have added a new API "resolve_and_reorient()" in the file
>> "initiate.c" that resolves the ipaddresses by reading the file
>> "/var/run/pluto/ipsec.info" and also adds the new network interfaces
>> and sets the both ends again.
> We really want the ipsec.info file to go away. Pluto currently has no
> on it, and we really do not want to add that right now.
One more thing to add, if I understand correctly, ipsec.info is still
being used in Pluto, the code in addconn.c makes use of it, and
ipsec.info is sourced in auto.in.
Thanks and Regards
> Though this would fix the "network has updated" case for the simple
> initiate case,
> it would not be a good generic solution. Rather, it would be better
> for pluto to
> be made aware of a change of ipaddress and/or nexthop, and then
> perform a check on
> all conns to see which ones need to have their %defaultroute value
> This would also not require writing to ipsec.info at all.
> So we are thinking of adding a new whack command to allow passing in
> the new
> ip and/or nexthop. Then NetworkManager could whack pluto to update all
> using those. In a later stadium, pluto could perhaps become clever enough
> and figure out these changes happen by itself, and call the 'whack
>> c) Another change I had to make the way connections with unresolved
>> ip addresses are added in "connections.c" file.
> I don't think this then is needed anymore either. If pluto loops over all
> loaded conns, and checks for KH_DEFAULTROUTE conns, it should be able to
> update the settings I believe.
> Things to be aware of with these changes:
> - If the connection is up, do we want to do the equivalent of
> "--replace and --up"?
> - should we take into account the rekey= setting?
> - If the ip and nexthop change, what do we do if uniqueids=no ?
> - Should we --down when we know the defaultroute vanished or hope it
> comes back before
> application time outs? (prob the latter)
>> 2. I noticed that there is an issue with iptables masquerading, where
>> if the added "source ip address" does not have the same maskbits as
>> the remote subnet, "iptables masquerading" does not work. This is an
>> issue with RW connections where there are multiple clients behind
>> that RW, and also in the "VM and Host" environment, where multiples
>> VMs are behind the host running ipsec. Currently the traffic from the
>> machines behind the RW (or host) can not be routed properly. The
>> patch takes care of this issue too.
> Could you tell me a bit more about what is going wrong? I assume this
> case is
> very different from NETKEY and KLIPS. I am not sure I understand the
> in this case. With KLIPS there are "more specific" half-routes that
> need to
> be added, so I'm weary of changing things without knowing exactly why
> we are
> doing this.
More information about the Dev