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

[Paul Wouters]

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.

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