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

[Harald Jenny]

Hello all,

wouldn't such a helper also solve the IPv6 problem in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573955?

Good night
Harald

On Tue, Jul 06, 2010 at 12:43:38PM -0400, Paul Wouters wrote:
> 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
> 
> _______________________________________________
> Dev mailing list
> Dev at openswan.org
> http://lists.openswan.org/mailman/listinfo/dev