Site2Site VPN Routing not working (USG60 to USG60)

stephan
stephan Posts: 31  Freshman Member
First Comment Friend Collector Sixth Anniversary
in Security
I am trying to integrate our branch office into our network.
For this I set up a Site2Site VPN between the two USG60 devices (one on each end).
This Site2Site VPN works (at least it is listed as "connected").

However, I can not reach resources in the HQ network from the branch network (assuming vice-versa, but not tested).
Here is what I have:
When trying to ping 10.0.0.X from a 192.168.178.X address, it doesn't work.
So I created 2 policy routes.
One at the branch
One at the HQ
I thought this was all I need, but I am still unable to reach any device in the HQ network from the branch.
I even checked the security policies, but nothing stands out there as being disallowed.

I am probably missing something elemental. But since I am not a trained network engineer, I am stuck right now.

Best Answers

  • Zyxel_Jeff
    Zyxel_Jeff Posts: 1,230  Zyxel Employee
    100 Answers 500 Comments Friend Collector Fourth Anniversary
    Answer ✓

    Hi @stephan

    The reason why the branch site can’t ping to HQ site is the packet be dropped by branch site's default rule, you can check those logs message as below:

    Monitor > Log  >View Log



    You can set a security policy on the branch site, from LAN1 to any as below:



    Then you can ping successfully from LAN1 IP(192.168.178.100) of branch site to LAN1 IP(10.0.0.2) of HQ :) . 




    241015_Speak-up,-Win-WiFi-7_Community-CSO-signature_1920x200.jpg

    Share your feedback through our survey, make your voice heard, and win a WiFi 7 AP! https://bit.ly/2024_Survey_Community

  • valerio_vanni
    valerio_vanni Posts: 91  Ally Member
    First Answer First Comment Friend Collector Second Anniversary
    Answer ✓
    stephan said:
    valerio_vanni said:
    If you ping printers but not PCs, it seems that PCs choose not to respond.

    I would look at system operating firewall: Windows firewall? Third party firewall?
    Try to disable it, just to diagnose.

    The devices do respond to ping from the same net.
    So the issue is not on the device.
    It was clear. But it's not enough to exclude that cause.

    A local firewall can define a subset of addresses inside its rules.
    And many rules in "Windows firewall", by default, have as default scope "Local subnet".

    If it's the case, it's perfectly expected that PC answers to ping from its subnet but not from the remote.
    I'm not sure if it's your case, so I suggested to try.

    Default gateway of PCs is the same of printers?
  • stephan
    stephan Posts: 31  Freshman Member
    First Comment Friend Collector Sixth Anniversary
    Answer ✓
    Thank you for putting me on the right track. I think I am done (will check in detail later).
    Allow me to elaborate:

    A local firewall can define a subset of addresses inside its rules.
    And many rules in "Windows firewall", by default, have as default scope "Local subnet".

    I understand now. This was not the issue. Win10 Machines set up the same way, dialed into the user VPN (10.0.1.X) were successfully pinging both the HQ printers and the HQ Linux server I tried.

    Default gateway of PCs is the same of printers?

    This was also not the issue. The gateway of the printers is correctly set as their respective USG60s (who act as gateway in both nets). Also, see above. The printers responded to pings from the VPN (which is a different net).

    HOWEVER

    You were still right. The printer at branch office I tried to ping from HQ actually was offline (and still is ... seperate issue). So after reading your reply, I tried pinging the other printer at branch office from HQ and this worked.

    This lead me to look at the routing policy set on the HQ USG60. In there the routing from for incoming traffic from the VPN connection to branch was set to:

    * source address was the net of branch office
    * destination address was the net of HQ
    * SNAT was set to HQ net

    I changed that to a much more lenient setting of

    * source address any
    * destination address any
    * SNAT outgoing-interface

    On branch office USG60, the settings always were

    * source address is HQ net
    * destination address is branch office net
    * SNAT is none

    So I suspect that I am doing something wrong with SNAT here. I will dig deeper and reply one last time with final routing settings I am satisfied with. In the meantime:
    With these settings, branch office finally can reach IPs in HQ net.

    I realize this was fully my mistake on routing too tightly, and I am sorry for the time I wasted here and hope that the detailed write-up might help others avoid my mistakes in the future.

    Thanks for the great help, valero and jeff!
«1

All Replies

  • mMontana
    mMontana Posts: 1,389  Guru Member
    50 Answers 1000 Comments Friend Collector Fifth Anniversary
    Is any of the subnets you're using for LAN1 of HQ and Branch are used in other settings?
    You can check into the objects of the firewall.
  • stephan
    stephan Posts: 31  Freshman Member
    First Comment Friend Collector Sixth Anniversary
    On Branch side, LAN1 subnet is only referenced in the VPN connection and the policy route I mentioned above.

    On HQ side, LAN1 subnet has more references besides that:

    * A policy route directing traffic from on of our WAN IPs to our mail server (though LAN1 subnet doesn't appear explicitly in the settings there?)
    * A policy route for the L2TP IPsec VPN we have running on HQ
    * A policy route directing WINS traffic from our L2TP IPsec VPN to our internal WINS server

    See screenshot.
    https://i.imgur.com/43vv5Nr.jpeg

  • Zyxel_Jeff
    Zyxel_Jeff Posts: 1,230  Zyxel Employee
    100 Answers 500 Comments Friend Collector Fourth Anniversary

    Hi @stephan

    Can you provide those two USG60(HQ and branch sites) config files to us via private message?
    We can help to check on your settings.


    241015_Speak-up,-Win-WiFi-7_Community-CSO-signature_1920x200.jpg

    Share your feedback through our survey, make your voice heard, and win a WiFi 7 AP! https://bit.ly/2024_Survey_Community

  • stephan
    stephan Posts: 31  Freshman Member
    First Comment Friend Collector Sixth Anniversary
    edited October 2021
    Zyxel_Jeff said:

    Hi @stephan

    Can you provide those two USG60(HQ and branch sites) config files to us via private message?
    We can help to check on your settings.

    I sent the cfgs to your account via PN.
    Any Idea in what direction I can start debugging troubleshoot in the meantime?


    /edit: sry for my wording with debugging. This is most probably NOT a bug. Updated the post with more accurate language.
  • Zyxel_Jeff
    Zyxel_Jeff Posts: 1,230  Zyxel Employee
    100 Answers 500 Comments Friend Collector Fourth Anniversary

    We applied your configs and found HQ subnet IP(10.0.0.2) can ping to the branch site subnet IP(192.168.178.101). Can you check whether your branch site 192.168.178.X domain's PC windows firewall is disabled?


    241015_Speak-up,-Win-WiFi-7_Community-CSO-signature_1920x200.jpg

    Share your feedback through our survey, make your voice heard, and win a WiFi 7 AP! https://bit.ly/2024_Survey_Community

  • stephan
    stephan Posts: 31  Freshman Member
    First Comment Friend Collector Sixth Anniversary
    Sorry if I was confusing.
    Last time I was at the branch office and tried to ping a server in the HQ network, which didn't work.
    The machine I tried to ping was a Linux server that should respond to pings and does so when pinged from the HQ network.

    I will try pinging a machine from HQ to branch now and get back to you with details.

  • stephan
    stephan Posts: 31  Freshman Member
    First Comment Friend Collector Sixth Anniversary
    edited November 2021
    A Ping from HQ to branch indeed works. But pings from branch to HQ don't:

    Pings in HQ:
    C:\Users\hq-pc>ping 192.168.178.1<br><br>Ping wird ausgeführt für 192.168.178.1 mit 32 Bytes Daten:<br>Antwort von 192.168.178.1: Bytes=32 Zeit=16ms TTL=61<br>Antwort von 192.168.178.1: Bytes=32 Zeit=18ms TTL=61<br>Antwort von 192.168.178.1: Bytes=32 Zeit=15ms TTL=61<br>Antwort von 192.168.178.1: Bytes=32 Zeit=14ms TTL=61<br><br>Ping-Statistik für 192.168.178.1:<br>    Pakete: Gesendet = 4, Empfangen = 4, Verloren = 0<br>    (0% Verlust),<br>Ca. Zeitangaben in Millisek.:<br>    Minimum = 14ms, Maximum = 18ms, Mittelwert = 15ms<br><br>C:\Users\hq-pc>ping 10.0.0.21<br><br>Ping wird ausgeführt für 10.0.0.21 mit 32 Bytes Daten:<br>Antwort von 10.0.0.21: Bytes=32 Zeit<1ms TTL=64<br>Antwort von 10.0.0.21: Bytes=32 Zeit<1ms TTL=64<br><br>Ping-Statistik für 10.0.0.21:<br>    Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0<br>    (0% Verlust),<br>Ca. Zeitangaben in Millisek.:<br>    Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms<br>STRG-C<br>^C

    Pings in branch:
    C:\Users\branch-pc>ping 192.168.178.1 -t<br><br>Ping wird ausgeführt für 192.168.178.1 mit 32 Bytes Daten:<br>Antwort von 192.168.178.1: Bytes=32 Zeit<1ms TTL=64<br>Antwort von 192.168.178.1: Bytes=32 Zeit<1ms TTL=64<br><br>Ping-Statistik für 192.168.178.1:<br>    Pakete: Gesendet = 2, Empfangen = 2, Verloren = 0<br>    (0% Verlust),<br>Ca. Zeitangaben in Millisek.:<br>    Minimum = 0ms, Maximum = 0ms, Mittelwert = 0ms<br><br>C:\Users\branch-pc>ping 10.0.0.21<br><br>Ping wird ausgeführt für 10.0.0.21 mit 32 Bytes Daten:<br>Zeitüberschreitung der Anforderung.<br><br>Ping-Statistik für 10.0.0.21:<br>    Pakete: Gesendet = 1, Empfangen = 0, Verloren = 1<br>    (100% Verlust),

    Why does it work in one way, but not the other way around?


    /edit: I again checked the policy routs on both USG60s and the active policy routes actually concern traffic from branch to HQ (outgoing on branch USG60 and incoming at HQ USG60). So I don't understand why HQ can even get into branch when there is no policy route for that currently active.
  • Zyxel_Jeff
    Zyxel_Jeff Posts: 1,230  Zyxel Employee
    100 Answers 500 Comments Friend Collector Fourth Anniversary
    Answer ✓

    Hi @stephan

    The reason why the branch site can’t ping to HQ site is the packet be dropped by branch site's default rule, you can check those logs message as below:

    Monitor > Log  >View Log



    You can set a security policy on the branch site, from LAN1 to any as below:



    Then you can ping successfully from LAN1 IP(192.168.178.100) of branch site to LAN1 IP(10.0.0.2) of HQ :) . 




    241015_Speak-up,-Win-WiFi-7_Community-CSO-signature_1920x200.jpg

    Share your feedback through our survey, make your voice heard, and win a WiFi 7 AP! https://bit.ly/2024_Survey_Community

  • stephan
    stephan Posts: 31  Freshman Member
    First Comment Friend Collector Sixth Anniversary
    I'll try that tomorrow at the latest and report back with findings.
  • warwickt
    warwickt Posts: 111  Ally Member
    5 Answers First Comment Friend Collector Third Anniversary
    G'day Stephan, I suggest you look at implementing a (series of) VTI connection(s) between your USG60 hosts with some basic policy routes (or OSPF with multiple routers).

    Its very straight forward..

    Search these forums: I had a few posts out there however, better, well known forum member  PeterUK had a few in the day.

    When you get it up implement OSPF should you have more than 2 (>2) in USG's in the VTI configs.. as well and then no need for Policy Routes.

    We have clients with several office/studio networked together like this.... as well as oursleves.. 

    TIPs-la:
    • don't bugger with the 'Zyxel Wizard" , (not so helpful for some)
    •  instead manually set the Configuration/ VPN Gateways their VPN Connections  to a public domain/host (use No-IP if or some ddns) using the UI or cli 
    •  then  lastly the Configuration/Networks/VTI / tunnel on each router to talk and them naturally... 
    • important: use the two USG60's logging for errors ( filter IKE) .. enable system logging to view in the UI
    • configure local zyxel DNS's and and use the domain fowarding carefully....
    Zyxel have made this rather nice.

    Good work you Zyxel TW blokes!


    Works great.

    IF you are lost , post .post post 

    HTH
    Warwick 
    Hong Kong

Categories

Security Highlight


Read more

Security Help Center

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