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

Tom
Tom Posts: 2
Friend Collector First Comment
edited April 2021 in Security

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

  • Alfonso
    Alfonso Posts: 257  Master Member
    First Anniversary Friend Collector First Answer First Comment

    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
    Zyxel_Stanley Posts: 1,361  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer

    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
    Tom Posts: 2
    Friend Collector First Comment

    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
    Zyxel_Stanley Posts: 1,361  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer

    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
    AmerDz Posts: 1
    First Anniversary First Comment

    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
    Zyxel_Cooldia Posts: 1,426  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer

    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
    Zyxel_Cooldia Posts: 1,426  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    edited July 2019

    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
    warwickt Posts: 111  Ally Member
    First Anniversary Friend Collector First Answer First Comment

    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
    Zyxel_Cooldia Posts: 1,426  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer

    Hi @warwickt

    Thanks for that detailed explanation about troubleshooting guide.

     

    @Tom ,@AmerDz

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

Security Highlight