USG110 - Failed Connectivity Check caused a termination of S2S IPSec VPN tunnel

USG_User

We are using a S2S IPSec VPN. The tunnel is under surveillance by USG VPN connectivity check which is regularly pinging a host in the remote network. This remote host is not the opposite VPN terminator but another client computer/server in the remote network. So far so good.

Yesterday we experienced that the remote host which normally returns the ICMP packets (ping) was not available. That's why the connectivity check of the USG failed and administrators received an alert log. This was also fine.

But simultaneously the USG was terminating the tunnel allthough the opposite tunnel terminator was still available. Is this a normal behaviour? We would expect that we are getting informed about the failed connectivity check, but why the tunnel should be terminated simultaneously?

In case this should be the normal behaviour, the VPN connectivity check cannot be further used, to keep the tunnel established as long as possible. Maybe Zyxel should consider an additional user option, whether the tunnel should be directly terminated or not when the connectivity check fails.

Zyxel_Charlie

@USG_User
The current behavior is that the VPN tunnel will be terminated if VPN connectivity check failed.
For an additional option when the connectivity check failed, we could evaluate that add the Primary & Secondary option for connectivity check on VPN page. This will move to idea section.

Zyxel_Charlie

@USG_User
The current behavior is that the VPN tunnel will be terminated if VPN connectivity check failed.
For an additional option when the connectivity check failed, we could evaluate that add the Primary & Secondary option for connectivity check on VPN page. This will move to idea section.

USG_User

Thanks Charlie,

In the meantime it happened again with us. That's why a consideration in your idea department would be highly appreciated.

USG_User

At the moment we're encountering lots of connectivity check failures again which let the USG switching off the IPSec S2S tunnel. (As already described in my former post above)

But what's annoying us, the USG doesn't re-initiate the tunnel, as soon as the connectivity check succeeds again. Why?

Normally the USG should remain carrying out the connectivity check to activate the tunnel immediately and automatically again.

mMontana

IMVHO this depends on the time value (SA Life time) of the Gateway (Phase 1 IPSec). Longer it is, longer will last the security association, the key handshaked and exchanged for let the tunnel work (Phase 2, VPN connection).

Increasing the SA Life time will lead to a more efficient VPN connection between endpoints, with lower occurrencies of renewing Security Association.

Decreasin SA Lifetime will lead a more frequent re-key handshake and exchange, reducing the (alleged) downtime for the VPN.

In any case, if not enable consider to activate on both side the DPD into Gateway.

USG_User

@mMontana: Thanks for your reply. But, since I'm not the IPSec expert ..., what does it mean in detail when increasing the SA Lifetime? Will this longer hold the tunnel alive although the connectivity check failed? (connectivity check and opposite tunnel terminator are different IPs here with us) Or will it re-establish the tunnel automatically when the connectivity check succeeds again? This is what we expect from a S2S tunnel.

Again, in a business environment where two branch offices have to be stay connected, we expect that s2s tunnels will be automatically reconnected, except they are disconnected manually for whatever reason. Is this really not configurable by USG?

In case a failed connectivity check let a tunnel disconnecting, what about implementing without using a connectivity check. Any thoughts in this regard?

Further, we know that the USG is always getting the real tunnel state (beside the connectivity test result), since the following symbol is showing it:

Is it possible to read out this state by a CLI command? Unfortunately we didn't find any documented.

terrylu

直接換個廠牌,

時間就是金錢