IPSec: Why does my VPN100 not answer to client requests?

Torsten_1 Posts: 3
First Anniversary First Comment
edited April 2021 in Security
I am rather a newcomer, and I am fully aware that I certainly have overlooked something. I just cannot see what I have overlooked...

My problem is that I fail to establish VPN access for a home user, using the built-in W10 VPN client.

I have 2 sites "E" and "G". On each site I have a VPN100, acting as a firewall and NAT router. Between the two VPN100 I have established an IPSec tunnel. Up to here, everything works like a charm, the 2 sites can nicely reach each other.

The next step is to add VPN access for home users. So I have established a VPN Gateway and a VPN Connection as described in various posts. My VPN client is a W10 computer at home, with built-in VPN support. The VPN type is IKEv2, and the server is set to site "E". When I try to connect, the connection fails.

I have wiresharked things and I see that my computer sends out 3 packets and never gets any response from site "E":

I have then run a packet capture on the VPN100 on site "E" and could not see any incoming packets from my home computer. Instead, I noticed that the 2 VPN100 on site "E" and "G" exchange some messages every time I try to connect from my home computer. This I find quite weird, because it seems to indicate that the VPN100 on site "E" does receive the packets from my client. The communication between the two VPN100 looks like this (you can see the IP addresses of site "E" and "G":
No.&nbsp;&nbsp;&nbsp; Time&nbsp;&nbsp;&nbsp; Source&nbsp;&nbsp;&nbsp; Destination&nbsp;&nbsp;&nbsp; Protocol&nbsp;&nbsp;&nbsp; Length&nbsp;&nbsp;&nbsp; Info<br>1&nbsp;&nbsp;&nbsp; 22:30:09,294523&nbsp;&nbsp;&nbsp;;&nbsp;&nbsp;;&nbsp;&nbsp; ISAKMP&nbsp;&nbsp;&nbsp; 122&nbsp;&nbsp;&nbsp; INFORMATIONAL MID=131 Responder Request<br>2&nbsp;&nbsp;&nbsp; 22:30:09,305497&nbsp;&nbsp;&nbsp;;&nbsp;&nbsp;;&nbsp;&nbsp; ISAKMP&nbsp;&nbsp;&nbsp; 122&nbsp;&nbsp;&nbsp; INFORMATIONAL MID=131 Initiator Response<br>3&nbsp;&nbsp;&nbsp; 22:30:11,013419&nbsp;&nbsp;&nbsp;;&nbsp;&nbsp;;&nbsp;&nbsp; ISAKMP&nbsp;&nbsp;&nbsp; 122&nbsp;&nbsp;&nbsp; INFORMATIONAL MID=133 Initiator Request<br>4&nbsp;&nbsp;&nbsp; 22:30:11,015305&nbsp;&nbsp;&nbsp;;&nbsp;&nbsp;;&nbsp;&nbsp; ISAKMP&nbsp;&nbsp;&nbsp; 122&nbsp;&nbsp;&nbsp; INFORMATIONAL MID=133 Responder Response<br>5&nbsp;&nbsp;&nbsp; 22:30:40,296129&nbsp;&nbsp;&nbsp;;&nbsp;&nbsp;;&nbsp;&nbsp; ISAKMP&nbsp;&nbsp;&nbsp; 122&nbsp;&nbsp;&nbsp; INFORMATIONAL MID=132 Responder Request<br>6&nbsp;&nbsp;&nbsp; 22:30:40,307839&nbsp;&nbsp;&nbsp;;&nbsp;&nbsp;;&nbsp;&nbsp; ISAKMP&nbsp;&nbsp;&nbsp; 122&nbsp;&nbsp;&nbsp; INFORMATIONAL MID=132 Initiator Response<br>7&nbsp;&nbsp;&nbsp; 22:30:42,015768&nbsp;&nbsp;&nbsp;;&nbsp;&nbsp;;&nbsp;&nbsp; ISAKMP&nbsp;&nbsp;&nbsp; 122&nbsp;&nbsp;&nbsp; INFORMATIONAL MID=134 Initiator Request<br>8&nbsp;&nbsp;&nbsp; 22:30:42,017654&nbsp;&nbsp;&nbsp;;&nbsp;&nbsp;;&nbsp;&nbsp; ISAKMP&nbsp;&nbsp;&nbsp; 122&nbsp;&nbsp;&nbsp; INFORMATIONAL MID=134 Responder Response<br>
In order to rule out that my Internet provider at home blocks UDP traffic, I have sent some UDP packets using a test tool. The only difference to the packets sent by the VPN client is that they do not originate from port 500. Those test packets are indeed shown in a packet capture on the VPN100.

I am at complete loss of what is going on here, and hope somebody can advice.

For better understanding, I attach a picture showing the setup.

With kind regards,
Problem overview


All Replies

  • Torsten_1
    Oh, the Wireshark snippet got shredded. I try again:
    No.    Time    Source    Destination    Protocol    Length    Info
    1    22:30:09,294523    ISAKMP    122    INFORMATIONAL MID=131 Responder Request
    2    22:30:09,305497    ISAKMP    122    INFORMATIONAL MID=131 Initiator Response
    3    22:30:11,013419    ISAKMP    122    INFORMATIONAL MID=133 Initiator Request
    4    22:30:11,015305    ISAKMP    122    INFORMATIONAL MID=133 Responder Response
    5    22:30:40,296129    ISAKMP    122    INFORMATIONAL MID=132 Responder Request
    6    22:30:40,307839    ISAKMP    122    INFORMATIONAL MID=132 Initiator Response
    7    22:30:42,015768    ISAKMP    122    INFORMATIONAL MID=134 Initiator Request
    8    22:30:42,017654    ISAKMP    122    INFORMATIONAL MID=134 Responder Response

  • Ian31
    Ian31 Posts: 167  Master Member
    First Anniversary 10 Comments Friend Collector First Answer
    If the client behind NAT,
    (1) The 1st IKE packet initial from client to VPN gateway will be UDP port 500.
    (2) The 2nd IKE packet from client to VPN gateway will encapsulate by another UDP port 4500 header to destination UDP port 4500 of VPN gateway.

    So first, check the firewall rule on VPN gateway is allow access both UDP port 500 and UDP 4500.
    Then capture UDP 4500 on VPN gateway.

  • Zyxel_Stanley
    Zyxel_Stanley Posts: 1,366  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer

    Hi @Torsten_1  

    During establish VPN tunnel, UDP500/4500 are required.

    You may have a check on your NAT router setting or ISP.

    If UDP500/4500 still unable to forward successfully, then you may use SSL VPN tunnel for your requirement. (Install SecuExtender on PC)

  • Torsten_1
    Hej Ian31 and Zyxel_Stanley,
    sorry for not responding earlier. It seems I don't get any notifications from this forum, need to check that.
    Regarding the actual issue:
    1. The mysterious packets between the 2 VPN100 ("" and "") are completely unrelated, as I found out. They are just the normal keep-alive/handshaking between them, because the 2 sites have the Site-to-Site tunnel between them.
    2. The missing packets on port 500: Believe it or not, the reason for them not arriving in the VPN100 was indeed my own NAT at home router where I many moons ago had disabled IPsec passthrough. It is enabled again, and I do see them arrive in the VPN100 now (using packet capture).
    However, being one step further, I do not see any response from the VPN100, and therefore my W10 VPN client never sends any packets on port 4500. Se we can worry about those packets later.

    One last comment: Both VPN100 are not behind a NAT router. The one on site "E" is behind a Sagemcom 3890 in bridge mode. The one on site "G" is behind some fiber equipment. Both should be fully transparent.

    With all that said, I believe I have overlooked some essential bit in the setup. But I have no clue which bit. I followed the KB-00185, which is a really good article, but still no luck.

    Any hint how to solve this issue?

  • Zyxel_Stanley
    Zyxel_Stanley Posts: 1,366  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    Hi @Torsten_1
    You may filter your client IP address on in Log viewer, then it will easier to know what caused VPN connection fail.

Security Highlight