IKEv2 client access problem with traffic flow

tgusset

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

tgusset

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

Zyxel_Jerry

Hi @tgusset

Welcome to Zyxel community

Can you private message your configuration for check further?

tgusset

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

warwickt

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

tgusset

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

tgusset

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