[Openswan dev] openswan connections with %defaultroute with later upcoming network
harald at a-little-linux-box.at
Tue Jul 6 17:47:24 EDT 2010
wouldn't such a helper also solve the IPv6 problem in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=573955?
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=22.214.171.124
> > 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.
> Dev mailing list
> Dev at openswan.org
More information about the Dev