No traffic in VPN IPSec Site-to-Site
Hi, I need to setup a IPSec Site-to-Site VPN with a third party. We use a Zyxel USG, while the third party device is unknown.
My local lan is 192.168.1.0/24 , in the vpn settings the Local Policy is 10.9.230.144/29 and the Remote Policy is 172.16.0.0/12
I followed this and this guide, the VPN connection is established, but there is no traffic flow, both inbound and outbound in the VPN Monitor.
So I have some questions:
- Do I need to add some routing?
- What are the needed Security Policies? I already have "IPSec_VPN_Outgoing" and "IPSec_VPN_to_Device"
- In the "VPN Connection" dialog, section "Related Settings"→"Zone" can I choose "none"? Does it bypass Security Policies?
- The remote servers of the third party sadly don't answer to pings, any other way to debug the problem?
Thanks
Accepted Solution
-
Now I would be curious to know why the routing from computers on 192.168.1.0/24 subnet doesn't work.
Because the other end is expecting 10.9.230.145 – 10.9.230.150 when it see 192.168.1.0/24 it will get to its gateway and not down the tunnel.
so we now know 10.9.230.146 works so with SNAT by the VPN tunnel should work
0
All Replies
-
The Local Policy you put in is not the same as your local LAN you can setup your LAN to be on the site to site Local Policy
or try a routing rule
incoming Interface LAN
destination 172.16.0.0/12
next hop VPN Tunnel
VPN tunnel
0 -
I can't choose my LAN due to third party setting, so I set the routing:
With this I see on VPN Monitor some few bytes on Outbound traffic while doing a traceroute on a destination host, but still not reachable.
The traceroute stops at first hop:
1 10.9.230.254 0,300ms 0,210ms 0,152ms
2 * * *
…
10.9.230.254 is the vlan gateway I set for that subnet.
The computer routing table has this entry:
Destination Gateway Genmask Flags Metric Ref Use Iface
10.9.230.147 10.9.230.254 255.255.255.255 UGH 0 0 0 enp5s0
0 -
I'm sorry, @DW_Informatica, but i cannot exactly understand this part of your post.
My local lan is 192.168.1.0/24 , in the vpn settings the Local Policy is 10.9.230.144/29 and the Remote Policy is 172.16.0.0/12
AFAIK, local and remote policy must be the same otherwise things can't work. So… You know the "real" remote subnet?
Also… there are specific settings for network remapping on the tunnel. For instance I can translate my network (192.168.1.0/24) as a different network
https://mysupport.zyxel.com/hc/en-us/articles/360003321659--ZyWALL-USG-How-to-configure-VPN-SNAT-on-Zyxel-gateways
0 -
@mMontana everything I know is in the first post, so the "real" remote subnet is unknown.
I now followed the instructions of your link,
but the vpn connection has no data flowthe vpn connection has few bytes in data flow but remote host still not reachable.0 -
Are you sure Remote Policy 172.16.0.0/12 is that side and not your side?
So from what I can tell the real remote subnet is known 172.16.0.0/12 but here the problem your local IP Policy does not match your local subnet.
With the above routing rule you a forcing your subnet for destination 172.16.0.0/12 to go down the tunnel BUT when the other getting this when it sends a packet back the tunnel at that end needs a routing rule to send 192.168.1.0/24 down the tunnel because its Remote Policy is 10.9.230.144/29.
I'm thinking you might need to use the Advanced Inbound/Outbound traffic NAT in VPN setting to make this work...
maybe
0 -
"So from what I can tell the real remote subnet is known 172.16.0.0/12
but here the problem your local IP Policy does not match your local
subnet."Correct.
The above configuration you suggested is already used, after the link by mMontana.
In the next two images you can see the VPN Connection, in the third image the routing section.
0 -
But is the other end expecting you to come from a given SNAT IP in 10.9.230.145 – 10.9.230.150 and from one IP?
as it is you can't source NAT /24 from /29 1:1 SNAT
0 -
172.16.0.0/12 it's really a strange subnet.
AFAIK class B is 172.16.0.0/16, so /12 is 16 times bigger space than B class subnet . And overlaps public addresses.
Probably there's some reasoning and specific architecture behind that… But with these information I cannot figure it out what could be.
1 -
172.16.0.0/12 is correct for that subnet
0 -
It seems related to SNAT in the tunnel. Could you provide the subnet topology in the tunnel? where the subnets located at and what's the remote subnet from the peer side?
0
Categories
- All Categories
- 415 Beta Program
- 2.4K Nebula
- 144 Nebula Ideas
- 94 Nebula Status and Incidents
- 5.6K Security
- 237 USG FLEX H Series
- 267 Security Ideas
- 1.4K Switch
- 71 Switch Ideas
- 1.1K Wireless
- 40 Wireless Ideas
- 6.3K Consumer Product
- 247 Service & License
- 383 News and Release
- 83 Security Advisories
- 29 Education Center
- 10 [Campaign] Zyxel Network Detective
- 3.2K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 83 About Community
- 71 Security Highlight