IKEv2 client access problem with traffic flow

tgussettgusset Member Posts: 4
edited March 27, 2020 12:46PM in Troubleshooting

Hi

I set up a client access VPN following http://onesecurity.zyxel.com/img/uploads/Next-Gen_IKEv2_VPN_Server_Role_CR.pdf

Client is Win 10 with Allways on VPN using IKEv2 in ForceTunnel mode

I can establish a connection, ICMP packets passing the tunnel, arrive at a test host in the internal network, sent back to the USG40, arrive there but will not be sent back to the tunnel.

I used package capturing an can see that ICMP echo reply packets arrive at the firewall, but there are no ESP packets leaving the firewall at the WAN port.

policy routing is not active

I checked 'dynamic vpn routes' -> ok

I checked 'policy control rules' -> ok (no match on default rule for blocked packets)

I disabled 'policy control' -> no success

packet capture on lan1 and wan1 shows

  • ESP packet from Win 10 client on wan1
  • ICMP echo request to test host on lan1
  • ICMP echo reply from test host on lan1
  • NO ESP packet to Win 10 client on wan1

Any idea what's wrong?

thanks in advance

Thomas

Accepted Solution

  • tgussettgusset Posts: 4
    Accepted Answer
    finally I found the problem (a faulty virtual-server entry in the config):
    ip virtual-server XXXXXXX interface dmz source-ip any original-ip A.B.C.D map-to server01 map-type port protocol any original-port 4158 mapped-port 4158 nat-1-1-map
    original-ip A.B.C.D is the IP address of the WAN interface and it was mapped to the DMZ interface. After removing this entry and reboot the firewall VPN works now like expected.

    Thomas

All Replies

  • Zyxel_JerryZyxel_Jerry Zyxel Official Agent Posts: 272  mod

    Hi @tgusset

    Welcome to Zyxel community

    Can you private message your configuration for check further?

  • additional information:

    Win 10 (A) <-vpn-> USG40 <--> Test host (B)

    ping from A to B

    ipsec debug log shows

    Found forward, flow 24903: 192.168.101.11:1->10.0.1.21:2048, flag: 0x00143401

    Found forward, flow 24930: 10.0.1.21:1->192.168.101.11:2048, flag: 0x00343404

    ping from B to A

    ipsec debug log shows

    Found forward, flow 24941: 10.0.1.21:1->192.168.101.11:2048, flag: 0x00353404

    packet capture on wan1 shows no ESP packets leaving USG40 in direction A

    ESP packets from A arriving like expected

    A is NATed

  • warwicktwarwickt Member Posts: 96  Ally Member

    Hi tgusset you'll need some Policy routes to coerce the traffic.

    Refer to this recent post..

    https://businessforum.zyxel.com/discussion/comment/12536#Comment_12536

    extra as per:

    e.g:

    • VPNCLIENT_SUBNET = 192.168.11/24 (example host A)
    • LAN1_SUBNET = = 10.0.1.21/24 (example host b)

    on the Policy Routes check the NEXTHOP Type setting

    your scenario:

    VPNCLIENT_SUBNET:hostA --> LAN_SUBNET:hostB

    nexthop type: Auto
    nexthop: auto
    

    LAN_SUBNET:hostB --> VPNCLIENT_SUBNET:host A


    VPNCLIENT_SUBNET:hostA <--> VPNCLIENT_SUBNET:hostA2

    nexthop type: Tunnel
    nexthop: your_IKEV2_Connection_name
    

    and others if you need etc etc

    Lastly make sure you have a Security Policies that permits the above:

    Example: Security Policy Rules:

    VPNCLIENT_SUBNET:anyhost --> LAN_SUBNET:anyhost
    secure-policy rule: nn
     name: IPSEC_VPN_to_LAN1
     description: Permit VPNCLIENT_SUBNET to LAN1_SUBNET
     user: any, schedule: none
     from: TUNNEL, to: LAN1
     source IP: VPNCLIENT_SUBPOOL, source port: any
     destination IP: LAN1_SUBNET, service: any
     log: no, action: allow, status: yes
    ...
    ...
    
    LAN_SUBNET:anyhost --> VPNCLIENT_SUBNET:anyhost
    secure-policy rule: nn
     name: LAN1_SUBPOOL_to_L2TP_SUBPOOL
     description: Permit LAN1_SUBPOOL_to_VPNCLIENT_SUBNET
     user: any, schedule: none
     from: LAN1, to: TUNNEL
     source IP: LAN1_SUBNET, source port: any
     destination IP: LAN1_SUBNET, service: any
     log: no, action: allow, status: yes
    ....
    

    and other OPTIONAL accesss you need Policy Route and Security Policy rules for..

    • VPNCLIENT_SUBNET to zyxel_router
    • VPNCLIENT_SUBNET to VTInn
    • VPNCLIENT_SUBNET to some-where-special
    • VTInn --> VPNCLIENT_SUBNET VPNCLIENT_SUBNET
    • some-where-else to
    • etc etc

    FWIW.. many examples are generic and suit most non-commercial use.

    However a good practice is to use very specific rules and logging to monitor as required.

    Debug:

    • set Alert Logging in the Security Policy and look at the Logs to see if they hit
    • USG appliance's - packet capture and your mate WireShark.app

    HTH

    Warwick

    Hong Kong

  • tgussettgusset Member Posts: 4

    Hi Warwick

    thanks a lot. I did a lot of debug work.I can follow the ICMP packets from VPN Client, to the tunnel, to the test host. From the test host back to the FW and into the VPN tunnel.

    Then I would expect to see ESP packets on the wan interface going back to the VPN client.

    I can see IKE packets between the VPN Client and the FW, and also ESP packets from the VPN client to the FW - but not a single ESP packet from the FW to the VPN client.

    I used packet capture on LAN and WAN interface, I set all logs to debug but could not see any issue.

    VPN monitor shows the tunnel and also inbound and outbound traffic.

    While checking many logs I found something very strange.

    show arp-table-------------------------------------------------------------------------

    Address         HWtype HWaddress      Flags Mask      Iface

    ...

    178.197.225.187         (incomplete)               dmz

    178.197.225.187 is the NATed IP of the VPN client (the destination where the ESP packets should go).

    So I used packet capture on DMZ interface. There are ARP requests for 178.197.225.187 with sender IP address of the WAN interface but MAC address of DMZ.

    thanks

    Thomas

Sign In to comment.