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

[Paul Wouters]

On Tue, 6 Jul 2010, Avesh Agarwal wrote:

> 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.

Then we should probably make a new "helper" or go straight into pluto learning
about new IP/defaultroute. The ipsec.info is for scripts and is on our todo list
to kill - adding a dependancy in pluto for that is not something we want to do.

> As I said that asking users to enter defaultroute and ip address does not 
> seem user friendly. And it should work without NM too.

I agree, we should have some helper figure that out for the user. I thought
it might just be easy to do from within NM.

> 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.

Are you compiling with USE_DYNAMICDNS=true ? If should fix those issues AFAIK.
If not, we can fix those, but it seems quite a different fix from the one where
we determine %defaultroute.

> 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.

Yes. pluto without ipsec.info i hope :)

> 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.

Tuomo will shortly have a patch for you to see if that fixes your masquerading issue.

Paul