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

[Avesh Agarwal]

Hi Paul,

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.
>
Thanks for your response. The reason for using "ipsec.info" is to make 
pluto do everything instead asking users to enter defaultroute and ip 
address info.

> 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'.
>
As I said that asking users to enter defaultroute and ip address does 
not seem user friendly. And it should work without NM too.

>> 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.
>
This issue is not just about KH_DEFAULTROUTE, it happens with 
KH_IPHOSTNAME (this leads to unresolved ip address) too. Following are 
the scenarios it can happen:


1.  left=%defaultroute
      right=11.0.0.1

2. left=%defaultroute
     right=xxx.yyy.com

3. left=10.0.0.1
     right=xxx.yyy.com

So not only with case 1, it should solve cases 2 and 3 too. When network 
is not up at boot time, and considering cases 2 and 3, the connection 
will have unresolved ip addresses ("right" ip addresses). These 
addresses should be resolved after network is up, otherwise connections 
can not be initiated. It will also require setting some parameters of 
the connections again like it is done by "default_end" API. If pluto can 
do all these things by itself without user interventions whenever 
connection is initiated, that would be better.

> 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.
>
With NETKEY, when there is need to add source ip address (obtained from 
remote server), its netmask is set to 32 by default. However, due to 
some issues with iptables masquerading,  this netmask should be set to 
the netmask of the remote subnet (rightsubnet). Otherwise, traffic from 
nodes behind the local ipsec end can not be routed inside VPN. I checked 
that KLIPS also does this in its updown script but it seems little bit 
wrong right now.

Thanks and Regards
Avesh

> Paul