Site2Site VPN Routing not working (USG60 to USG60)

stephan · January 2022

Zyxel_Jeff said:

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 .

Hi Jeff. Sorry for the exceptionally late reply.
Unfortunately, our business needed my elsewhere for a while.

I did spot the access blocked triggered by the default rule in the logs.
I did create a policy LAN1 to any, but pings are still not going through. But they are also not showing up as blocked anymore.

Here is what I did/found

Created the policy like this on the branch USG60:

Image: https://us.v-cdn.net/6029482/uploads/editor/nj/br0bssui4u2w.jpg

Made sure the VPN shows as connected on both USG60s
I tried pinging both USG60s from both networks.

Machine in HQ pinging HQ USG60
Machine in HQ pinging branch USG60
Machine in branch pinging branch USG60
Machine in branch pinging HQ USG60

All of these pings did return normally and return the pings.

I tried pinging devices within the networks and this doesn't work though.

Machine in HQ pinging network printer in branch
Machine in branch pinging network printer in HQ

Both should return pings.
So I guess, there is still a routing issue?
I did try a tracert from branch to a device within HQ network and it did seem to bounce around aimlessly as it did show timeouts after the branch USG60 and terminated after 30 hops.

Image: https://us.v-cdn.net/6029482/uploads/editor/xw/ti0bmw19upte.jpg

If I try to tracert the HQ USG60 from a branch device, it correctly shows 3 hops and a termination at the HQ USG60.

Image: https://us.v-cdn.net/6029482/uploads/editor/d6/xdovgkun9mvb.jpg

Any ideas still?

valerio_vanni · January 2022

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.

stephan · January 2022

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.

Sorry if I was not clear enough on that. I will edit my post to reflect that.

Edited the post to be more clear that pings within networks to target machines work. But through VPN they don't. I can only ping the edges of the net (the 2 USG60s respectively).

valerio_vanni · January 2022

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 · January 2022

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!

valerio_vanni · January 2022

stephan said:

The devices do respond to ping from the same net.
So the issue is not on the device.
Sorry if I was not clear enough on that. I will edit my post to reflect that.

It was clear, but that behavior cannot exclude local firewall as cause.

A local firewall can define a subset of addresses in its rules. For example, Windows Firewall by default has some rules that have as scope "local subnet".

So it would be regular to find that PC accept connection from their subnet and not from another.

I cannot tell if it's your case, but the test of disabling local firewall it's worthy. Quick and simple.

You said that printers did respond. Do they have the same gateway like PCs?

stephan · January 2022

valerio_vanni said:

stephan said:

The devices do respond to ping from the same net.
So the issue is not on the device.
Sorry if I was not clear enough on that. I will edit my post to reflect that.

It was clear, but that behavior cannot exclude local firewall as cause.

A local firewall can define a subset of addresses in its rules. For example, Windows Firewall by default has some rules that have as scope "local subnet".
So it would be regular to find that PC accept connection from their subnet and not from another.

I cannot tell if it's your case, but the test of disabling local firewall it's worthy. Quick and simple.

You said that printers did respond. Do they have the same gateway like PCs?

I already posted a comprehensive explaination here: https://community.zyxel.com/en/discussion/comment/37240/#Comment_37240
tl;dr: It was a FW routing issue.

You said that printers did respond. Do they have the same gateway like PCs?

Yes. Their gateway is are their respective USG60s.

I cannot tell if it's your case, but the test of disabling local firewall it's worthy. Quick and simple.

As outlined in the other post, the machines (printers and a Linux server) did return pings from our L2TP VPN to requests from outside their net. It was not a local firewall or internal routing issue with the machines.

Site2Site VPN Routing not working (USG60 to USG60)

All Replies

Categories

Security Highlight

Security Help Center