Re: Testing OpenVPN?

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

> The requirements are:
>
> 1) It needs to happen after racoon has started up and has sent the
> REGISTER message to the PF_KEY socket.  Though making the ping last long
> enough might be sufficient.  I'd probably send about 10 or 12 at 5-second
> intervals.
>
> 2) The source address of the ping needs to match the near end of the
> tunnel, which may require using -S on the ping if there isn't a suitable
> fake static route for it.

I've already tried this. On the local network, I've set up a cron job on 
a server that periodicly ping the LAN IP of the remote m0n0wall box. But 
on the remote network, there is no machine no machine running 24/24 and 
there are only Windows machines and no sysadmin at all :-(

The trick only work if both sides of the tunnel can send ping packets. 
This is why it should be included in m0n0wall.

Justin is about to release a ping patch, so we'll have to wait...


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

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

I've just noticed this parameter in our old Netopia (Cayman) R3100 ISDN 
router (not tested - just looked at the menu entries):

You can try to use old SA first or force new SA use.

Yes, it can be the clue to our problem... Combined with a good keepalive 
 feature, the IPsec tunnels can be always available, even within a few 
minutes after a reboot.

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


> Even if you get IPsec fully working, I recommend having the PPTP option
> available as Plan B.  Unfortunately, m0n0wall itself can't be the client,
> though.

I'll do that, sure ;-)


Thanks you for investigating, Fred.

-- Vincent