On Wed, 11 Aug 2004, Vincent Fleuranceau wrote:

> More: IPsec does not work 100% of the time for me, but this does not 
> mean I will switch to OpenVPN and let other people find a solution for 
> me. I imagine other people are not satisfied with the situation too, so 
> I want to contribute and make IPsec work on m0n0wall. I won't give up so 
> easily ;-)

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

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.

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

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

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.

> > How about just investigating what's wrong when your IPsec tunnel stops
> > working?  Did you ever get the PPTP link set up so you can view the state
> > of the remote without depending on IPsec?  Fixing something that almost
> > works is likely to be easier than implementing something entirely new.
> 
> This was a good "Plan B", but unfortunately, the PPTP integrated server 
> feature + IPSec tunnel does not seem to work at the same time on the 
> same box. I've tested it two times from different clients and with two 
> different m0n0 boxes. PPTP just work fine but the IPsec tunnel does not 
> establish anymore after the PPTP is running.

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.

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.

					Fred Wright