[Openswan Users] Major problems with multiple tunnels on Fedora 11

[Marek Greško]

On Pi 26. Jún 2009 23:38:10 Marek Greško wrote:
> On Pi 26. Jún 2009 21:16:15 Marek Greško wrote:
> > On Pi 26. Jún 2009 18:09:51 you wrote:
> > > On Fri, 26 Jun 2009, Marek Greško wrote:
> > > > since I upgraded from F10 (openswan-2.6.19) to F11
> > > > (openswan-2.6.21+nss.patch) I have problems to instantiate multiple
> > > > tunnels between the gateway and the roadwarrior. Prior to upgrade
> > > > everything worked. Except from some time ipsec.exe on Windows XP
> > > > instantiates only the first tunnel it finds (it used to work before).
> > > > My question is not about that but if anybody knows I will be happy on
> > > > any advice on that.

I have several observations you may be interested in.

I solved this issue by removing empty %default section from ipsec.conf of 
ipsec.exe. Hope this is the final solution and will not stop working again.

> > >
> > > ipsec.exe is a really old tool. ipsectool is newer, but AFAIK only
> > > works for one tunnel. Openswan could be ported to Windows, though
> > > really only on the newer ones with the netsh command (Vista and up I
> > > believe?)
> >
> > The ipsec.exe is the only non-gui tool for XP I am aware of and it was
> > supporting multiple tunnel configuration. It suddenly stop to. I do not
> > know when.
> >
> > On Vista we use netsh without openswan successfully.
> >
> > > > Windows XP instantiates tunnel B.
> > > >
> > > > I get this in the log:
> > > >
> > > > Jun 26 11:02:42 gw pluto[15235]: "A"[1] WinpublicIP #94: the peer
> > > > proposed: Brightiprange:0/0 -> WinpublicIP:0/0
> > > > Jun 26 11:02:42 gw pluto[15235]: "A"[1] WinpublicIP #94: peer
> > > > proposal was reject in a virtual connection policy because:
> > > > Jun 26 11:02:42 gw pluto[15235]: "A"[1] WinpublicIP #94: a private
> > > > network virtual IP was required, but the proposed IP did not match
> > > > our list (virtual_private=)
> > > > ... this is probably due to public ip on windows without NAT and is
> > > > probably harmless, am I right?
> > >
> > > I cannot really read this with the information hiding. If it tried to
> > > propose with 0.0.0.0/0 its clearly wrong. If it is not behind nat, you
> > > prob don't have rightsubnet=vhost containing "%no" (for non nat) or if
> > > you are behind nat, and have rightsubnet=vhost:%no,%priv, then the
> > > internal range of the client is not part of virtual_private=
> >
> > I was doing bad consequences. The problem did not arise on upgrade to
> > openswan 2.6.21 I only did not check whether it works with 2.6.19 without
> > NAT. But I am almost sure it did with openswan 2.4. The current state is
> > that it works when using NAT, but not working without NAT. I have set up:
> >
> >         leftsubnet=vhost:%no,%priv
> >
> > The virtual_private is configured properly. What leftsubnet should I use
> > if I want the tunnel to work for the same device whether it is natted or
> > not?
> >
> > Or is it necessary to create separate tunnel definition for non-natted
> > client?
>
> I probably found an answer to my question:
>
> https://gsoc.xelerance.com/issues/973
>
> Isn't it the issue I am observing?
>
> Marek

I created a copy of tunnel definitions with

leftsubnet=vhost:%no

I don't know why, but it looks like whether I use nat or not, always is used 
this connection with vhost:%no and never vhost:%no,%priv.

But it works!!

The only issue I am now stuggling with is this:

I have USB 3G modem connected with static public IP address to an Win XP 
client which uses IPsec without NAT to an static public IP address range. When 
I disconnect the modem, connect it to my Linux box without IPsec configured and 
try to connect to the same IP range I get no answer until restart of IPsec on 
the remote gateway. I understand what is going on. The remote gateway holds 
the IPsec policy and tries to communicate through previously created IPsec 
tunnel. But I have DPD (with policy clear) configured and the tunnel never 
stops. Isn't the DPD intended to be used to put down the tunnel when the 
oposite side does not use it?

Marek

>
> > > > The problem arises when gw thinks Windos is trying to instantiate
> > > > tunnel A, not B. How can I override this? It used to work before
> > > > upgrade.
> > >
> > > Since the phase 1 for A and B are the same, you are misled in thinking
> > > the gateway is mistaken. When doing phase1 there is no difference, so
> > > the connection name it picks can be iether one of the two. Once it gets
> > > to phase 2, it should switch to the right conn.
> >
> > OK. My fault. So the problem arises some where in the "proposed IP did
> > not match our list (virtual_private=)".
> >
> > Marek
> >
> > > Paul
> >
> > _______________________________________________
> > Users at openswan.org
> > http://lists.openswan.org/mailman/listinfo/users
> > Building and Integrating Virtual Private Networks with Openswan:
> > http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155
>
> _______________________________________________
> Users at openswan.org
> http://lists.openswan.org/mailman/listinfo/users
> Building and Integrating Virtual Private Networks with Openswan:
> http://www.amazon.com/gp/product/1904811256/104-3099591-2946327?n=283155