IPSec VPN Network Policy Error on Windows 11
-
I have configured an IPSec IKEv2 VPN with RADIUS authentication as document in the Netgate Recipe.
My Windows 11 client hast the following VPN Connection Configuration:
Here is my Phase 1 Config:
Here is my Phase 2 Config:
When I attempt to connect from Windows, I receive a
Policy Match Error:
The IPSec logs on the gateway show show the following:
As far as I can tell, I have matching Phase 1 and Phase 2 options that the client and server should agree upon. What am I missing here?
-
@codechurn It’s failing in the initial IKEv2 phase - before negotiating ciphers. So my guess is you missed something in the:
“Phase 1 Proposal (Authentication)” part of your mobile user tunnel. Likely that you need a certificate that matches the name fo your VPN endpoint? -
This is how my Phase 1 Proposal is setup:
I'm using an ACME Let's Encrypt certificate; it's the same certificate I use for the Web GUI, which works without issue. The certificate has one SAN, as depicted below:
I can confirm that the RADIUS is indeed working via Diagnostics Settings | Authentication
Thoughts on what to look at next?
-
@codechurn Hmm, that looks fine. I looked at your log again, and perhaps I misinterpreted at what stage the problem occurs because I was expecting a more thorough log-output. In my setups the proposals the client offers, and the proposals the server expects are logged when the connection is made. But that could be in my logs only because I might have raised (can't remember) the default log-levels.
So that's what I would do now - raise the IKE log level so you can see the proposals from both ends in the log - then it might become more obvious, But I agree - It looks like you have the right ciphers in both ends.
Another angle:
Try and change the Windows VPN to use the AES256 Encryption instead of the GCM-256. I seem to recall I had issues with that years ago in Windows and went AES256 instead - which has worked ever since. -
@keyser
I cranked up all of the logging to highest and here is the tail of it (most recent to older):
ipseclog.txtI find these lines interesting:
May 28 18:42:27 charon 25147 16[IKE] <1> no IKE config found for 192.168.0.254...192.168.0.209, sending NO_PROPOSAL_CHOSEN May 28 18:42:27 charon 25147 16[CFG] <1> ike config match: 0 (w.x.y.z...0.0.0.0/0, ::/0 IKEv2) May 28 18:42:27 charon 25147 16[CFG] <1> ike config match: 0 (%any...127.0.0.1 IKEv1/2) May 28 18:42:27 charon 25147 16[CFG] <1> looking for an IKEv2 config for 192.168.0.254...192.168.0.209 May 28 18:42:27 charon 25147 16[ENC] <1> parsed IKE_SA_INIT request 0 [ SA KE No N(FRAG_SUP) N(NATD_S_IP) N(NATD_D_IP) V V V V ]It's like it's not finding and matching config. w.x.y.z is the public IP of my WAN interface, and I am clearly bound to this interface.
-
@codechurn So my first hunch was correct - it never matches the remote client to a IKEv2 policy.
But there is something wrong with your IP addresses/interfaces.
You have selected WAN as the IPSec interface, but the interface that recieves the client request has IP 192.168.0.254 according to the logs (Not a public IP). Is 192.168.0.254 really your WAN interface? Are you behind a Carrier Grade NAT/an ISP modem that does port forwarding of IKE (UDP 500/4500)?The client you are testing with comes in with IP 192.168.0.209 (also not public) AND is in the same L2 and L3 IP subnet as the WAN interface. Is that intentional? As far as I know It won’t work when the client and server are in the same L2 and L3 subnet because the client cannot tunnel packets to the destination IPsec interface IP (as it’s in the same subnet as the client, and that subnet is not tunneled).
-
@codechurn If you are not behind a port forward/carrier grade NAT your public WAN IP should clearly be listed in the logs as the IP interface it recieved a packet on. If you are behind a port forward it should still work but explains why the interface is listed with a Private IP.
More important: The client coming in should be listed with it’s public IP - even if you have a ISP modem is doing port forward (NAT).
Do you perhaps a flawed NAT rule that accidentally applies to your clients traffic reaching the IPsec Service? -
@keyser Thanks for your input. Your advice helped me validate that the IPSec VPN was working and gave me insight into my flawed testing approach. Let me share some background on what I was doing; perhaps this thread will help someone else in the future.
Network Configuration
- 192.168.0.254 is the LAN1 interface IP of the firewall.
- The firewall is configured as a DNS resolver to 1.1.1.1 and 1.0.0.1 for the LAN1, WAN1 and Localhost interfaces
- The firewall DNS resolver has an override for the xxx.org domain to use 192.168.0.110 and 192.168.0.111 which are DCs on the local network.
- 192.168.0.110 and 192.168.0.111 point to 192.168.0.254 for upstream DNS.
- The DCs run an IPv4 DHCP server with scope 192.168.0.0/24.
- LAN clients are allocated an IP address out of this range and passed 192.168.0.110 and 192.168.0.111 as DNS servers and 192.168.0.254 as the gateway.
DNS Resolution
- Internal DNS serves gateway.xxx.org as 192.168.254.
- 75.x.y.65 is the WAN1 interface IP
- External DNS serves gateway.xxx.org as 75.x.y.65
I was testing from a laptop which was connected to the LAN. Since I was not outright blocked and since it seemed like the RADIUS authentication testing was working I assumed there was something wrong with my IPSec configuration. It was not until seeing in the logs where it was not finding an IPSec profile and your comment about receiving the inbound request at the private IP that I realized that the problem likely was that I was connected to the LAN. I disconnected from the LAN and test tethered the laptop to a hotspot and attempted to connect to the VPN and BINGO - worked first time. I then further refined my Phase 1 and Phase two as follows:
Phase 1 Proposal
Phase 2 Proposal
Windows 11 Client Configuration
I validated this configuration from the hotspot connected laptop and everything worked great! It would be great if I could test IPSec connectivity from a LAN connected device without disconnecting and tethering to the hotspot, but it sounds like this may not be possible based on your response.
Thanks again!
-
@keyser So I thought about this for a while and added the following NAT port forward rules on the LAN1 interface:
After doing this, I was able to connect successfully to the IPSec VPN from the test laptop while connected to the LAN. Off LAN connections still (no surprise) continued work. Do you see any issue with what I am doing here? Also, I did not need to create a port forward rule for ESP IP Protocol 50, which according to the Internet is used by IPsec.
-
@codechurn So glad I could help and execellent work in cleaning up your settnings to only allow the exact ciphers you wish to use.
In regards to IPsec: IPSec uses ESP to encapsulate packets between source and destination.
ESP is a transport layer protocol (like TCP and UDP) that is used for encapsulating other packets in their complete form. It has a built-in authentication measure that is broken if the ESP packet has been tampered with.
ESP does not use protocol ports like TCP or UDP - only source and destination IP addresses. This means it cannot be safely NAT’ed/Portforwarded as the NAT/Portforward device cannot keep proper/secure state between source and destination. Also: The builtin authentication would be broken by the NAT rewrite of the packets.That is why there are two ways for IPSec to establish a VPN tunnel:
The VPN Client contacts the VPN server on IKE port UDP 500 and attempts to negotiate an IPsec tunnel. IKE uses the clients and servers actual IP inside the IKE negotiation to see if they correlate to the sending and recieving IP. This will reveal if there as any NAT done in transport. Then it selects which way to tunnel traffic based on the result:- If both ends has a public IP and no NAT/Portforward is done, tunneling can be done using straight ESP packets exchange, and a tunnel is established that way.
- If one or both ends are being NAT’ed, the IPSec tunnel is instead established using a NAT friendly solution. This is done by encapsulating the ESP packet in a UDP packet and forwarded to port 4500. The UDP packet can traverse NAT, and once decapsulated by the reciever, the ESP packet is still in its original form (untampered with) . This is known as IPsec NAT-T.
The first way only has one encapsulation of the original packet into a ESP packet, and thus has the theoretical best performance.
The second way does two encapsulations of the original packet - first into ESP and then ESP into UDP. This takes more CPU and uses more bits/packet for overhead/packet and thus has a slightly lower theoretical performance. -
@codechurn In regards to your created NAT rules to allow testing from the inside LAN:
Yes it works, but it’s not a very “pretty way” to do it :-)
What you should do, is have your VPN service use a dedicated DNS name for VPN only (Different than DNS for the Firewall).
You should then register that name in your internal/External DNS with the same IP - Your actual public WAN IP.
This would allow internal clients to tunnel to the VPN server, and VPN will work without NAT “workaround” rules. -
Thanks for the recommendation. I can't believe I overlooked this much simpler solution. I zapped the NAT port forward rules and just created a new hostname for the VPN which resolves to the public IP on the LAN.
Also, thanks for taking the time to provide details on IPSec and ESP.
