[Openswan dev] openswan connections with %defaultroute with later upcoming network

[Avesh Agarwal]

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 
>> "auto.in".
>
>> 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 
> dependancy
> 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
Avesh
> 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 
> updated.
>
> 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 
> conns
> using those. In a later stadium, pluto could perhaps become clever enough
> and figure out these changes happen by itself, and call the 'whack 
> routine'.
>
>> 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 
> packetflow
> 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.
>
> Paul