IPSec: Why does my VPN100 not answer to client requests?
Hej,
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. Time Source Destination Protocol Length Info<br>1 22:30:09,294523 93.167.246.158 93.160.21.81 ISAKMP 122 INFORMATIONAL MID=131 Responder Request<br>2 22:30:09,305497 93.160.21.81 93.167.246.158 ISAKMP 122 INFORMATIONAL MID=131 Initiator Response<br>3 22:30:11,013419 93.160.21.81 93.167.246.158 ISAKMP 122 INFORMATIONAL MID=133 Initiator Request<br>4 22:30:11,015305 93.167.246.158 93.160.21.81 ISAKMP 122 INFORMATIONAL MID=133 Responder Response<br>5 22:30:40,296129 93.167.246.158 93.160.21.81 ISAKMP 122 INFORMATIONAL MID=132 Responder Request<br>6 22:30:40,307839 93.160.21.81 93.167.246.158 ISAKMP 122 INFORMATIONAL MID=132 Initiator Response<br>7 22:30:42,015768 93.160.21.81 93.167.246.158 ISAKMP 122 INFORMATIONAL MID=134 Initiator Request<br>8 22:30:42,017654 93.167.246.158 93.160.21.81 ISAKMP 122 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,
Torsten
Tagged:
0
All Replies
-
Oh, the Wireshark snippet got shredded. I try again:No. Time Source Destination Protocol Length Info
1 22:30:09,294523 93.167.246.158 93.160.21.81 ISAKMP 122 INFORMATIONAL MID=131 Responder Request
2 22:30:09,305497 93.160.21.81 93.167.246.158 ISAKMP 122 INFORMATIONAL MID=131 Initiator Response
3 22:30:11,013419 93.160.21.81 93.167.246.158 ISAKMP 122 INFORMATIONAL MID=133 Initiator Request
4 22:30:11,015305 93.167.246.158 93.160.21.81 ISAKMP 122 INFORMATIONAL MID=133 Responder Response
5 22:30:40,296129 93.167.246.158 93.160.21.81 ISAKMP 122 INFORMATIONAL MID=132 Responder Request
6 22:30:40,307839 93.160.21.81 93.167.246.158 ISAKMP 122 INFORMATIONAL MID=132 Initiator Response
7 22:30:42,015768 93.160.21.81 93.167.246.158 ISAKMP 122 INFORMATIONAL MID=134 Initiator Request
8 22:30:42,017654 93.167.246.158 93.160.21.81 ISAKMP 122 INFORMATIONAL MID=134 Responder Response
0 -
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.
0 -
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)
0 -
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:
- The mysterious packets between the 2 VPN100 ("93.167.246.158" and "93.160.21.81") 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.
- 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).
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?/Torsten
0 -
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.
0
Categories
- All Categories
- 415 Beta Program
- 2.4K Nebula
- 144 Nebula Ideas
- 94 Nebula Status and Incidents
- 5.6K Security
- 237 USG FLEX H Series
- 267 Security Ideas
- 1.4K Switch
- 71 Switch Ideas
- 1.1K Wireless
- 40 Wireless Ideas
- 6.3K Consumer Product
- 247 Service & License
- 384 News and Release
- 83 Security Advisories
- 29 Education Center
- 10 [Campaign] Zyxel Network Detective
- 3.2K FAQ
- 34 Documents
- 34 Nebula Monthly Express
- 83 About Community
- 71 Security Highlight