Site-to-Site IPSEC VPN - connects but only way packets

Tom

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

Alfonso

Hi @Tom

Please verify if the ping packet reaches the target ip address, and if the device responds (pong packet), and if reaches the "local" Zyxel device.

It will fantastic if you show error logs.

Regards

Zyxel_Stanley

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.

Tom

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

Zyxel_Stanley

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.

AmerDz

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

Zyxel_Cooldia

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

Zyxel_Cooldia

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?

warwickt

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

Zyxel_Cooldia

Hi @warwickt

Thanks for that detailed explanation about troubleshooting guide.

 

@Tom ,@AmerDz

Feel free to let us know if you still have issue.