[ previous ] [ next ] [ threads ]
 
 From:  Fred Wright <fw at well dot com>
 To:  m0n0wall at lists dot m0n0 dot ch
 Subject:  Re: [m0n0wall] Testing OpenVPN?
 Date:  Tue, 17 Aug 2004 01:30:30 -0700 (PDT)
On Thu, 12 Aug 2004, Vincent Fleuranceau wrote:
> -------- Original Message --------
> 
> > I have an idea as to what causes this, and I believe it would be avoided
> > if the now-removed "automatic" mode actually worked correctly (though it's
> > possible that a kernel fix might be needed as well).  In the meantime, I
> > think a workaround would be to arrange to ping through the tunnel after a
> > reboot.  I'm not sure this can be done with the <shellcmd> facility due to
> > timing issues (i.e. whether "background commands" work properly in this
> > context).
> 
> This is the reason why I've asked Manuel to add a lightweight cron 
> daemon to m0n0wall. This would make possible to have the ping command 
> issued on a periodic basis, not only at boot time. And it may have other 
> uses.

One doesn't need cron to do periodic pings.  And actually, the periodic
part is *almost* completely unnecessary in the absence of bugs, while
being insufficient in the presence of bugs.

> > The basic idea is to insure that the tunnel is brought up from the
> > just-rebooted end, so that the orphaned SAs in the other end don't make it
> > think it doesn't need SA negotiations.  I'm not sure why a ping is
> > necessary to do this, unless racoon's default for "passive" has been
> > changed to "on".
> 
> I don't see what this option actually does...

Apparently it only serves to suppress initiating negotiations *even when
requested by the kernel*.  AFAICT, racoon has no code to initiate
negotiations *without* a request from the kernel under 8any*
circumstances.

> > The other issue is how the kernel prioritizes conflicting send SAs.  
> > There's no simple answer to this, since preferring older SAs can cause
> > problems with orphaned SAs, but preferring newer SAs may cause a temporary
> > loss of connectivity due to skew in when the new SA is established at the
> > two ends.  Theoretically this skew could be as much as a maximum segment
> > lifetime (MSL, about 4 minutes), but in practice it's likely to be only a
> > fraction of a second.
> > 
> > I think the best compromise for SA priority would be to choose the newest
> > SA that's been in existence for at least MSL, or the oldest if none meets
> > that condition. That would limit the duration of the "reboot interruption"
> > to MSL, while avoiding interruptions altogether in normal SA turnover.  
> > Unfortunately, this behavior isn't one of the available options. :-)
> 
> I really agree for the newest SA choice. I can wait for one minute for 
> the new SA to be negotiated, but can't wait for hours for the old SA to 
> be purged.

The time shouldn't be anywhere near a minute under normal circumstances.  
It's only the delay in the very last step of the negotiations that's
involved.  However, it usually turns out to be a few seconds rather than a
fraction.  I believe this is because of the "rate limiter" nonsense; the
IKE designers seem to have been *incredibly* paranoid about generating
floods of negotiation packets.

> > The choice between the other two is based on the net.key.preferred_oldsa
> > sysctl, which is currently set to 1.  I think setting it to 0 would be a
> > better tradeoff.  You might give that a try.  I think it should work to
> > put the sysctl using <shellcmd>, but since it's the non-rebooted end that
> > matters, you in the configcould just try it on the fly first with
> > exec.php.  You'd still need the ping from the rebooted end.
> 
> Very interesting!

It turns out that there was a bug where turning this off was only
partially effective (only in the FAST_IPSEC version; it had been fixed in
the regular version).  Anyway, I've fixed that, as well as adding a
"holdoff" feature; I'm testing that kernel now.

I also have a pinger kludge working.  Done in an ugly way, but it serves
as "proof of concept".

> > Be sure that the IP addresses used for the PPTP link are not in the tunnel
> > range.  For example, here the remote SnapGear has the tunnel configured
> > for 192.168.1.x, and its PPTP server configured for 192.168.2.x.  With
> > both links up I can connect to the remote WebGUI by either method just by
> > picking the proper IP.
> 
> I know the IP range rules, but just in case, this is what I had:
> 
> Site A
>    m0n0wall 192.168.1.254
>    Windows 2000 192.168.1.5 (PPTP client)
> 
> Site B
>    m0n0wall 192.168.5.254 (PPTP server - no PPTP forwarding)
> 
> PPTP config:
>    server address 192.168.50.254
>    remote address range 192.168.50.1/28
> 
> Works well, but when active, make IPsec tunnel not respond...

Is it possible that Windows is being "helpful" by making the PPTP server
the default gateway when the link is up?  Check the routing tables.

					Fred Wright