USG210s Mesh VPN With 3 Of Them

Options
KCS1
KCS1 Posts: 6  Zyxel Employee
First Anniversary First Comment
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 Anniversary First Comment
    Answer ✓
    Options
    Ended up being a corrupted default vpn security policy rule.
    Deleted, recreated, and all is well.

All Replies

  • jasailafan
    jasailafan Posts: 192  Master Member
    First Anniversary 10 Comments Friend Collector First Answer
    Options
    How about configuring VPN concentrator?
  • KCS1
    KCS1 Posts: 6  Zyxel Employee
    First Anniversary First Comment
    edited January 2021
    Options
    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 Anniversary First Comment
    Options
    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 Anniversary First Comment
    Options
    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: 204  Master Member
    First Anniversary 10 Comments Friend Collector First Answer
    Options
    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 Anniversary First Comment
    Options
    Thank you Zyman2008 although the static route unfortunately did not work either :(.
  • KCS1
    KCS1 Posts: 6  Zyxel Employee
    First Anniversary First Comment
    Answer ✓
    Options
    Ended up being a corrupted default vpn security policy rule.
    Deleted, recreated, and all is well.

Categories

Security Highlight


Read more

Security Help Center

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