USG210s Mesh VPN With 3 Of Them

KCS1
KCS1 Posts: 6  Zyxel Employee
First Comment Second Anniversary
edited April 2021 in Security
I have 3 USG210s setup in a mesh VPN. 2 are working great with bi-directional communications. The 3rd will not communicate with either of the other 2 unless I edit the default deny rule and set to allow. I have tried to create rules to allow the comms to no avail. I have never encountered an issue like this and have many site to site VPNs configured, all using the wizard for setup and work seemlessly. I have tore down both VPN connections on the unit and re-set them up to encounter the exact same anomaly. Thank you for any insight!

Accepted Solution

  • KCS1
    KCS1 Posts: 6  Zyxel Employee
    First Comment Second Anniversary
    Answer ✓
    Ended up being a corrupted default vpn security policy rule.
    Deleted, recreated, and all is well.

All Replies

  • jasailafan
    jasailafan Posts: 193  Master Member
    5 Answers First Comment Friend Collector Sixth Anniversary
    How about configuring VPN concentrator?
  • KCS1
    KCS1 Posts: 6  Zyxel Employee
    First Comment Second Anniversary
    edited January 2021
    Thank you Jasailafan.
    I tore down and rebuilt with a concentrator based on the kb article you shared and have the same anomaly.
    I am using same key, security, dh, etc on the tunnels and all sites have static IP.
    More Detail:
    HomeOffice 192.168.1.254 
    BranchA  10.0.0.1
    BranchB  192.168.2.1 (unable to communicate in tunnels unless default policy set to allow)
    Connectivity Check Greyed Out On HomeOffice VPN Monitor For BranchA but VPN works.
    Connectivity Check On HomeOffice VPN Monitor To BranchB Fails.
    BranchB was added to the network 6 months later.
    I am at a loss and thinking I may have to call support :(
  • KCS1
    KCS1 Posts: 6  Zyxel Employee
    First Comment Second Anniversary
    Zyxel Tier1 support looked at the setup today and could not figure out why it was not working. They escalated the issue to US Support and said I would receive a call back. I have yet to receive a call but will post the results when I do.
  • KCS1
    KCS1 Posts: 6  Zyxel Employee
    First Comment Second Anniversary
    Update, when testing and try to ping a far end USG at 192.168.1.x the response comes back 34.31.X.X. Quite odd as we do not have 34.x.x.x anywhere in the system. Tier1 was lost as to why that was occurring.
  • zyman2008
    zyman2008 Posts: 223  Master Member
    25 Answers First Comment Friend Collector Seventh Anniversary
    KCS1 said:
    Update, when testing and try to ping a far end USG at 192.168.1.x the response comes back 34.31.X.X. Quite odd as we do not have 34.x.x.x anywhere in the system. Tier1 was lost as to why that was occurring.
    I think you hit the very old known issue of USG policy based IPSec VPN.
    The source IP address of the reply packet will choice the WAN interface IP instead of the internal IP address(192.168.1.x).
     
    Here a tricky work-around to solve the issue,
    For example,
    Ping from Brach A(10.0.0.1) to Home Office USG (192.168.1.x)  
    You need to add a static route on Home Office USG.  Destination:10.0.0.1, Subnet mask: 255.255.255.255, Next-hop: lan1 interface

  • KCS1
    KCS1 Posts: 6  Zyxel Employee
    First Comment Second Anniversary
    Thank you Zyman2008 although the static route unfortunately did not work either :(.
  • KCS1
    KCS1 Posts: 6  Zyxel Employee
    First Comment Second Anniversary
    Answer ✓
    Ended up being a corrupted default vpn security policy rule.
    Deleted, recreated, and all is well.

Categories

Security Help Center

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