[j-nsp] manually force netscreen to renegotiate phase 1 proposal for ipsec tunneling

[Anthony Fajri]

Hi All,

Last time, I got some problem when implementing IPSec tunneling (in hub &
spoke topology).
one of my site got unstable vpn link.
the log showed that the link is up and down, without any other error log.
I followed this step: http://kb.juniper.net/KB9488, but didn't help.

If the vpn was down, I can bring it up just by restarting the netscreen. of
course this is not a good practice.
but at the time, this action (restarting the netscreen) shows that nothing
wrong with the configuration.

and the condition when the link was flapping is:
- latency is good
- when the link is up, throughput is also good
- we use ADSL link (no public IP for netscreen, so the untrust interface is
using private IP) for the spoke, and dedicated link for the hub (6 mbps)
- we also has another link using ADSL, and we didn't face any problem in the
link.

then we suspect that the problem is in WAN link.
and we solve the problem after replacing the ADSL modem in the remote site.
seems like the quality of ADSL modem is not that good.

I then questioned myself, how to manually force the netscreen to renegotiate
phase 1 proposal?
So if the same problem happen, I don't need to restart the netsreen.
(that time was the 2nd time I bring up the vpn link just by restarting the
netscreen).

ps:
- I use default heartbeat
- sometime, sending data thought the vpn link (although at the time the vpn
link was down) can bring up the vpn tunnel, but it doesn't guarantee that
the vpn link goes up immediately, so this also doesn't help (for my case)
- i configure vpn monitor (pinging the trust interface of spoke netscreen
from trust interface of hub netscreen), but also didn't work

So, does anyone know how to force the netscreen to renegotiate the ipsec
proposal (phase 1 and phase 2)?

Thanks for the reply

Regards,

-- 
Anthony Fajri
http://fajri.freebsd.or.id