Site-to-Site IPSEC VPN - connects but only way packets
Hi All,
We have found an issues with two ZyWALL 310's we are running. Both are on different leased lines/circuits and work fine, when you configure a VPN (even using the official setup guide) the VPN connects and you can see packets coming in one direction but we don't appear to get the response traffic.
The firewalls are running V4.33(AAAB.0) / 2019-01-09 09:40:42 and with a ping you can see the outbound increase on one and the inbound increase on the other firewall but no response is received. If you run the ping in the other direction nothing is logged on the firewall side.
Any ideas?
Thanks.
Tom
All Replies
-
Hi @Tom
Here is your topology:
ZyWALL#1=====[VPN tunnel]=====ZyWALL#2
Your symptom is client can pass traffic from ZyWALL#1 to ZyWALL#2, but unable pass traffic back to ZyWALL#1.
This situation should coming from your routing priority.
You can go to Maintenance > Packet Flow Explore to check your routing priority.
And you can make sure if packet has effected by any rules.
Share yours now!
Stanley
0 -
Hi @Alfonso and @Zyxel_Stanley
I've done some more testing today. On the ZyWALL#1 the traffic is now leaving and can be found doing a packet capture. On the ZyWALL#2 the traffic is now not showing at all in the IPSec Monitor or on a packet capture. I've looked at the routing priority and not found any issues or conflicts with the traffic routing.
Any other ideas as it is the same scenario with another VPN between ZyWALL 310 and USG60. Our other VPN's which are configured in the same way work fine.
Thanks,
Tom
0 -
Hi @Tom
In the default setting, after site to site VPN tunnel is established system will add routing automatically.
Maybe your routing have effects by other rules. I will send you private message for further check.
Share yours now!
Stanley
0 -
Hello,
I have the same problem!
USG310 192.168.13.1 -> USG110 10.8.110.1
USG310 -> USG50 10.8.1.1
USG110 10.8.110.1
USG310 can send packet to USG110
USG310 can send packet to USG50
but unable pass traffic back to USG310?
Regars
Amer
0 -
Hi @AmerDz
Can you post USG110 and USG50 policy route and Static-Dynamic route for troubleshooting.
CLI:
Router> show system route policy-route
Router> show ip route static-dynamic
Don't miss this great chance to upgrade your Nebula org. for free!
0 -
Hi @AmerDz
It could be caused by security policy or policy route.
For security policy, you could disable both site security policy temporarily for testing, if it is fine after disable security policy, you may check this first.
For policy route, do you create any specific policy route for both site lan subnet?
Don't miss this great chance to upgrade your Nebula org. for free!
0 -
Hi Tom ,AmerDz et al, this is usually straight forward to resolve using Policy Routes or such in the USG appliances.
IF you are seeing ICMP traffic or otherwise) get over to the destination and getting lost (packet capture or otherwise) , it's probably the the response if trying to return to return from the destination to the source but doesn't know where to go (crudely_ speaking).
Generally you can simply use a Policy Route in the USG appliances to do this.
In the case of AmerDz :
His USG310 has a range/subnet where he says the stuff originates:
Let's refer to this subnet 192.168.13.0/24 as "usg310LAN13SUBNET" .. define an object as an INTERFACE SUBNET (for this else use the default if one exists (i.e. LAN1_SUBNET for example) . Make sure this is defines ALSO on the destination devices as well. In this case on AMerDZ usg110 (next)...
The other USG appliance is his USG110 where a subnet (in his case) is 10.8.110.0/24. Let's refer to this subnet 10.8.110.0/24 as "usg110LAN8110SUBNET" .. define an object define an object as an INTERFACE SUBNET for this else use the default if one exists (i.e. LAN1 SUBNET or LAN2SUBNET for example). Make sure this is defines ALSO on the destination devices as well. In this case on AMerDZ usg310 (previous)... etc etc)
Refer to the WEB UI / Configuration/Address GEO/ and make the address ojjects any way you like yourself...
With these defined on the other's appliances and knowing what subnet they might originate, you have what you need to provide a return path to the lost packets using a Policy Route.
Here's how: Use the WEBUI or cli to set a simple Policy route on each of the two appliances . The goal is to coerce the flow from a particular source subnet to a specific destination subnet over a specific interface and do the same for the response.
For example assume the site to site interface is a IPSEC_VPN called tunnel5 and these two usg310 and usg110 are connected over a working tunnel5 (same name both ends for simplicity)
Thus from the USG310 point of view, we will use a policy route to coerce all traffic from any address on "usg310LAN13SUBNET" (192.168.13.0/24) that is destined for a subnet called "usg110LAN8110SUBNET" (10.8.110.0/24) . We MUST put the reverse Policy route on the USG110 to assist in the packets return to the source on "usg310LAN13SUBNET"
USG310 :
active: yes auto-disable: no description: usg310LAN13SUBNET to usg110LAN8110SUBNET Tun5 user: any schedule: none interface: tunnel5 tunnel: none sslvpn: none source: usg310LAN13SUBNET destination: usg110LAN8110SUBNET DSCP code: any service: any srcport: any nexthop type: Tunnel nexthop: tunnel5 nexthop state: Not support auto destination: no SNAT: none DSCP marking: preserve connectivity-check: no
USG110:
active: yes auto-disable: no description: usg110LAN8110SUBNET to usg310LAN13SUBNET Tun5 user: any schedule: none interface: tunnel5 tunnel: none sslvpn: none source: usg110LAN8110SUBNET destination: usg310LAN13SUBNET DSCP code: any service: any srcport: any nexthop type: Tunnel nexthop: tunnel5 nexthop state: Not support auto destination: no SNAT: none DSCP marking: preserve connectivity-check: no
Examine the Incoming Interface selection for a specific interface where the response packet comes from. this is helpful rather than using
you might need to offer the SNAT setting in some cases. Generally I've not needed it
AS usual insure you have correct Security Policies (ACL's) set to allow access from to from IPSEC_VPN or TUNNEL etc ..
TIP: set Security Policy logging ON for the specific security policy to log and track it to debug ... for Access Forward or Access BLOCKED .. lie to know if it actually gets through to the destination. 😉
SO packets originating on usg310LAN13SUBNET destined for the remote appliance on Tunnel5 to devices on usg110LAN8110SUBNET ought go out and return as you expect.
Worth a look
HTH
Warwick
Hong Kong
1 -
Categories
- All Categories
- 414 Beta Program
- 2.2K Nebula
- 130 Nebula Ideas
- 90 Nebula Status and Incidents
- 5.4K Security
- 171 USG FLEX H Series
- 256 Security Ideas
- 1.4K Switch
- 71 Switch Ideas
- 1K Wireless
- 36 Wireless Ideas
- 6.2K Consumer Product
- 235 Service & License
- 372 News and Release
- 77 Security Advisories
- 24 Education Center
- 5 [Campaign] Zyxel Network Detective
- 2.9K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 80 About Community
- 69 Security Highlight