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

USG_User
USG_User Posts: 374  Master Member
5 Answers First Comment Friend Collector Sixth Anniversary
edited August 2021 in Security
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.

Accepted Solution

  • Zyxel_Charlie
    Zyxel_Charlie Posts: 1,034  Zyxel Employee
    50 Answers 500 Comments Friend Collector Fourth Anniversary
    edited August 2021 Answer ✓
    @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.

All Replies

  • Zyxel_Charlie
    Zyxel_Charlie Posts: 1,034  Zyxel Employee
    50 Answers 500 Comments Friend Collector Fourth Anniversary
    edited August 2021 Answer ✓
    @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
    USG_User Posts: 374  Master Member
    5 Answers First Comment Friend Collector Sixth Anniversary
    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
    USG_User Posts: 374  Master Member
    5 Answers First Comment Friend Collector Sixth Anniversary
    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
    mMontana Posts: 1,389  Guru Member
    50 Answers 1000 Comments Friend Collector Fifth Anniversary
    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
    USG_User Posts: 374  Master Member
    5 Answers First Comment Friend Collector Sixth Anniversary
    edited April 2022
    @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
    terrylu Posts: 8
    First Comment Friend Collector First Anniversary

    直接換個廠牌,

    時間就是金錢

Categories

Security Highlight


Read more

Security Help Center

EnglishTiếng ViệtРусскийไทย中文（台灣）