-------- 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
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
> 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
> 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
> 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.
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:
Windows 2000 192.168.1.5 (PPTP client)
m0n0wall 192.168.5.254 (PPTP server - no PPTP forwarding)
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,
I'll do that, sure ;-)
Thanks you for investigating, Fred.