adiinfo
join:2005-11-02
Switzerland
| VPN reconnect
Hi
we use a Zywall 50 with the latest FirmWare-Release for about 30 concurrent VPN-Links. All devices connecting to the Zywall 50 are Zyxel (652, 662).
Our problem is that if a VPN connection is dropped unexpectetly by the peer the Zyxel 50 still keeps the tunnel and consequently, when the same peer device tries to rebuild a tunnel, the Zywall 50 says the tunnel already exists and denies to build a VPN Tunnel.
So the only solution we found up to now was to delete the tunnel manually in the Zywall 50. But this is annoying.
any ideas how we can get the Zywall to drop a tunnel automatically?
is this behavior better in Release 4.x in ZyWall 35?
Thanks
Andrej |
|
maxusa
Premium
join:2004-05-05
USA
4 edits | In the newer Z5/35/70 series, there are several timers for IPsec: input and output. Also, look into nailed-up for auto renegotiation. A combination of these on both ends shall provide the answer.
>ipsec timer chk_conn
>ipsec timer chk_input
Your units might not have these in the GUI, so test-run them from the CLI and then add the necessary lines into autoexec.net to persist.
EDIT: ZyXEL engineers are on record to be screwing around with these timers. They have changed timer ranges, ability to turn-off, relationship to nailed-up, etc. It has been a moving target (royal pain). Currently, the way things settled in V4.0 seems to be:•chk_conn a.k.a. output idle timer. Checks for replies after sending something to the remote routers. If no reply is received after the specified time, the router will verify the suspected tunnel and, if found dead, will drop it. Number of seconds between 120 and 3600. Can not disable. Default is 3600.•chk_input a.k.a. input idle timer. If no inbound traffic is received for the specified time, the tunnel is deemed suspected. The router will verify the vitals and, if found truly dead, drop the tunnel. Number of seconds between 30 and 3600. Enter 0 to disable.•nailed-up will renegotiate the tunnel when SA is expired and/or when above timers knock the tunnel down. You may want to consult the user guide or firmware release notes for details. Beware of inconsistencies. For example, the chk_conn timer is always on, but some docs claim 0 will disable it. You need to experiment as different firmware releases and different products behave differently. Also, your solution now may not be forward-compatible with the next firmware release.
To add insult to injury, most firmware circa late 2004 through early 2005 had bugs in these timers knocking tunnels down regardless of the traffic. See your IKE logs for constant tunnel reset/renegotiation. Timers work better now (Z5/35/70). Sounds like fun? Good luck.
Hope this helps. |
|
dougzz
join:2004-03-26
England | reply to adiinfo
I have exatly the same issue with a Zywall 70 and 662's and 652's to connecting to it. The Z70 is running V3.65(WM.1). |
|
maxusa
Premium
join:2004-05-05
USA | reply to maxusa
To continue on the subject, you may want to see other IPsec-related commands: "ipsec timer chk_my_ip", "ipsec timer update_peer", and "ipsec config keepAlive". They may improve the dis/reconnect rate in some cases (like DDNS). |
|
ttgpm
join:2005-05-30
UK | no such commands as "ipsec timer chk_my_ip" or "ipsec config keepAlive" on the Z5...?! |
|
maxusa
Premium
join:2004-05-05
USA | Sorry, I did not mention... some commands are for the Prestige line. Since IPsec is a collaborative effort, one needs to configure both end points for best results. Please see the corresponding product guide for the supported CLI commands. |
|
Eric_T
join:2004-03-22
Belgium
| reply to adiinfo
In my experience with similar issues (since then resolved in my setup thanks to some firmware upgrades) you can make the central Z-50 "realise" that there is something wrong with the tunnel by sending some traffic through it.
That doesn't help you much if you're at the remote end trying to re-establish the tunnel, but if there's a server at the central site and if the VPN's are supposed to be up 24*7 then a simple ping script can perform miracles...
We used What'sUp Gold form ipswitch (www.ipswitch.com) to verify which networks & hosts were up and found that it would (eventually) make our Z10W realise a tunnel was down & then re-establish it. |
|
maxusa
Premium
join:2004-05-05
USA
2 edits | Ping script is a good way to trigger the chk_conn timer. The input idle timer is supposed to help when no outbound traffic is expected (can not use chk_conn). Therefore, a combination of both timers on the router shall provide the desired result. Pair this with the other endpoint fine-tuning.
The real world evidence, however, suggests that IPsec interruptions (and loss of service) are inevitable. Our job is to minimize downtime to acceptable levels. |
|
adiinfo
join:2005-11-02
Switzerland
| reply to adiinfo
Ok
first of all, thanks for the detailed discussion of the Zyxel VPN reconnect behevior.
Also, i did not mention that i was talking about dynamic VPN tunnels, so all run over one dynamic profile (one fix IP at the ZyWall 50, everything dynamic at the peers).
a while ago, we did some testing on a ZyWall 35, FirmWare 3.6x and found the results to be somewhat inconsistent. Overall, the results were not really better, just different. So we decided to stay with the factory settings for the 3 timers.
I do not say its not possible to get better results, we might have not tried hard enough.
But in my opinion the main question remains: why does the ZyWall not drop a dynamic VPN tunnel when a new request from a peer comes in? When the ZyWall is able to determine that a Tunnel from a specific peer already exists, so why not drop it and let it rebuild by the peer site???
As a dynamic VPN tunnel can only be build by the peer site, no harm can be done in dropping it.
Andrej |
|
DavidJWood
Premium
join:2001-10-12
UK
| Defining the x in 3.6x when talking about VPNs on the Z35 is important - the VPN code went through a significant redesign for 3.64. If your previous experiments were with 3.62 or 3.63, it's worth testing again with 4.00 (which also has the new VPN code).
David |
|
maxusa
Premium
join:2004-05-05
USA
| reply to adiinfo
The reason for not dropping a dynamic tunnel appears to be that there is no way of knowing apriori that this is the same or different node/user calling. Suppose several users in the same remote site are trying to IPsec pass-through. During the initial IPsec negotiation, it is very difficult/risky to make a determination to drop something else. Besides this and obvious complexity, there might be other reasons.
In theory, the 2 timers, nailed-up/keepAlive, and chk_peer shall provide the solution. As we know, however, technology not always works as expected.  |
|
maxusa
Premium
join:2004-05-05
USA | reply to adiinfo
Have you tried to move IPsec tunnels to their own rules/policies? Much better control and troubleshooting. Made our lives easier. |
|
adiinfo
join:2005-11-02
Switzerland
| how?
to my knowledge, the concept for dynamic VPN with Zyxel is to make one policy with remote network of 0.0.0.0. So all dynamic VPN's connect on this one policy with 0.0.0.0
we do not want to use ddns or buy static addresses a the peer sites.
Andrej |
|
maxusa
Premium
join:2004-05-05
USA | Why not use DDNS? |
|
