Assistance diagnosing Always On VPN error 809

Question

Assistance diagnosing Always On VPN error 809

James Edmonds 831

Hi,

I've just finished deploying my AOVPN infrastructure, and am now running my test connections in order to confirm working and prep a VPN template.
Sadly, I am getting error 809, which I understand to be a network connectivity related issue likely due to UDP 500 and 4500 being blocked.

I'm at a bit of a loss where this issue is being introduced in my network flow, and hoping someone can offer some advice on what else to check;

We are a small organisation, so don't currently have a separate perimeter network and external/internal firewalls. We have a single Meraki MX84 as our firewall/LAN router, and I am trying to separate inbound VPN traffic from the LAN using a separate VLAN. Not ideal, but the best I can do at the moment.
We have two subnets/VLANs involved, VLAN 1 - 10.0.0.0/23 and VLAN 61 - 172.16.1.0/24. The Meraki has an interface on both of these of 10.0.0.1 and 172.16.1.1
Our "External" interface on our RRAS VM is on VLAN 61 with IP 172.16.1.6, with the "Internal" being on VLAN 1, with IP 10.0.1.57
No ACLs between the VLANs yet, but will be introduced once I get this VPN working. As such, any client on either VLAN can route to a client on the other VLAN
The Meraki has NAT rules mapping our external IP to the 172 address of the VPN server for UDP ports 500 and 4500.
The Meraki has a Trunk to a Cisco Catalyst 9200
The Cisco has a trunk to our ESXi server
Our RRAS VM sits on the ESXi server

So when I try to connect from an external network, I get error 809 and the message that comes along with that:

If I connect internally, I have no issues and everything seems to function.
The VM currently has its Windows firewall disabled during testing.
The Meraki rules are the only other place that the ports may be getting blocked, but our NAT rules are allowing them:

I've also done a quick and dirty network diagram showing the setup.

If anyone can offer me any advice on what else to check, I'd appreciate it!

Thanks
James

2 answers

Your answer

Answer 1

Gary Nebbett 6,216

Hello @James Edmonds ,

The next thing that I would try is a simple network trace. That would indicate whether packets to UDP ports 500 and 4500 are actually being exchanged. It may be the case that packets to both ports are being exchanged but that communication stops after the first exchange but before the VPN is fully established.

On the client, I would suggest starting a trace with the following command: pktmon start --capture --comp nics --flags 0x10 --trace --file-name why.etl. Now try to establish a VPN connection (perhaps just disconnect and reconnect to a network, in the case of AOVPN) and then stop the trace with he command pktmon stop. You can either make the captured file available in this forum or analyse it yourself (perhaps pktmon etl2pcap -? will help).

Gary

James Edmonds 831 Reputation points

2022-01-26T19:03:02.007+00:00

Thanks.

I've done some packet captures on my client and can see outbound packets, but no inbound from the external IP/VPN server.
The same seems to be true on my Meraki appliance.

I have raised a ticket with them to see how else we can diagnose on the Meraki.

Thanks
James
Gary Nebbett 6,216 Reputation points

2022-01-26T19:21:27.997+00:00

Hello James,

So, is it correct to say that you are only seeing outbound packets to port 500, all of the same size and probably separated by approximately 1 second intervals?

There are other things that we could trace, but let's first give Meraki support a chance.

Gary
James Edmonds 831 Reputation points

2022-01-26T22:51:33.203+00:00

It would be 100% correct yes :)

I see three packets outbound from my client to port 500, and that is the sum total of packets to/from the external IP of the VPN server.

I have provided Meraki with the public IP, and they are going to check my config.

Many thanks for your advice Gary!
James
Gary Nebbett 6,216 Reputation points

2022-01-27T08:27:26.647+00:00

Hello James,

Can you access the Internet with a web browser from the VPN server? One possibility is that the routing to the Internet is not (auto-) configured correctly on the VPN server.

Gary
James Edmonds 831 Reputation points

2022-01-27T09:18:33.73+00:00

Morning Gary,

Yes internet access is ok.

Many thanks
James
Gary Nebbett 6,216 Reputation points

2022-01-27T10:03:07.447+00:00

Hello James,

One thing that I would try is repeating the network trace, but this time on the VPN server, to see if the packets are received. This information would not bring you a big step forward, but it would help a little bit to isolate the problem (or confirm suspicions).

Gary
James Edmonds 831 Reputation points

2022-01-27T10:06:09.843+00:00

A very good suggestion!
I shall give it a go.

James
James Edmonds 831 Reputation points

2022-01-27T10:31:41.517+00:00

Interestingly, on the VPN server, I can see these ISAKMP packets being received and then responses going back.
I suspect therefore the Meraki is blocking them outbound for some reason.

Will see what Meraki come back to me with.

Thanks Gary!
James
Gary Nebbett 6,216 Reputation points

2022-01-27T12:28:01.003+00:00

Hello James,

Another idea, again just intended to scope the problem, is to use the tracert command on the VPN server to trace the route back to the VPN client. I know that you have said that connectivity to the Internet from the VPN server is working, but this might be misleading - for example, I access www.google.com over IPv6 but obviously I would use IPv4 to access an IPv4 address. It would be good to know that IPv4 routing to the client was behaving as expected.

Gary
James Edmonds 831 Reputation points

2022-01-27T12:39:35.037+00:00

Hi Gary,

Tracert'ing goes first hop to the 172.16.1.1 address on the Meraki (as this is set as the gateway address on the "External" interface on the VPN server), and then from there out onto the internet.

I suspect a firewall issue on the Meraki, but can't see why, so hopefully their support can offer some guidance on how to check.

Thanks for your ongoing advice.
James
James Edmonds 831 Reputation points

2022-01-31T12:35:49.077+00:00

Hi Gary,

I've had a chat with Meraki support, but not proven to be too successful in diagnosing.
It turns out the Meraki is sending out the response packets, but my client machine doesn't seem to receive them.

Below is the WAN interface of the Meraki:

But this is my client machine:

I've sent this back to Meraki, but I honestly can't think of what else would cause these packets not to reach my client?

Cheers
James
Gary Nebbett 6,216 Reputation points

2022-01-31T14:21:36.843+00:00

Hello James,

I know that there might be confidentiality issues, but it is much easier to give clear answers if the raw (unfiltered and binary) trace data is available.

There is obviously some fragmentation taking place (visible in the Meraki trace and inferable in the filtered client trace (based on the implausible size of frames 31, 41 and 97) but that is not always visible in the images that you post. There might also be interesting ICMP messages that have been filtered.

I will do my best to "imagine" what might be happening, base on the data available, with initial emphasis on fragmentation as a possible cause.

If you wanted to "go the whole hog", to get a very good idea of what is happening from the client's perspective, the trace command that I would use is pktmon start --capture --comp nics --flags 0x10 --pkt-size 0 --trace --provider Microsoft-Windows-WFP --provider Microsoft-Windows-RRAS --provider "IKEEXT Trace Provider" --keywords 0x10 --level 4 --file-name why.etl (coupled with pktmon stop).

Gary
James Edmonds 831 Reputation points

2022-01-31T14:38:48.333+00:00

Thanks Gary.

There are indeed matching fragmentation packets in the client capture. I was just filtering based on ISAKMP to look for the requests and responses.
Does this not play nicely with fragmented packets?

I can't see any ICMP packets in the capture.

I'm happy to send you the PCAP I took using Wireshark from the client if you like? There is very little in between the initiator request attempts, and while I'm not expert I cannot see anything unusual. It just looks as though the response packets the Meraki is sending out never reach me.

Thanks for your ongoing input.
James
Gary Nebbett 6,216 Reputation points

2022-01-31T14:58:10.763+00:00

Hello James,

Let's try this first (assuming the VPN server is Windows Server 2019 or later):

Set the registry DWORD value EnableServerFragmentation to 1 at HKLM\SYSTEM\CurrentControlSet\Services\RemoteAccess\Parameters\Ikev2\ (see https://github.com/MicrosoftDocs/windowsserverdocs/issues/3475).

I don't know if a service or server restart is necessary before this takes effect, but once it has taken effect, the change in behaviour should be visible in the network traces (even the curtailed traces that we have seen so far).

I suggest to add the value and then test/trace, Depending on what is seen then restart (stop/start) the RasMan service.

This change will cause the IKEv2 fragmentation method to be used rather than depending on IP fragmentation.

Gary
James Edmonds 831 Reputation points

2022-01-31T16:02:23.467+00:00

Thanks Gary!
Changing that, and rebooting the server, has allowed me to connect :)
The PCAPs now show "IKE Fragment 1/3", "IKE Fragment 2/3", "IKE Fragment 3/3".
Similar for responses, with those being 4/4.

I can then see packets in ESP, after the tunnel is established.

I don't know if it is recommended to keep IKE fragmentation enabled or not, but does look to prove fragmentation may be at fault here.
We have a ticket open with our comms provider to check the MTU on our ISP router, so hopefully once we have it matching the Meraki appliance we have the option to revert this registry change.

Thanks again for such helpful assistance with this, greatly appreciated!
James
Gary Nebbett 6,216 Reputation points

2022-01-31T16:13:54.003+00:00

Hello James,

The change should certainly be permanent and there is not a problem with the MTU settings.

The problem is probably a combination of NAT (Network Address Translation) and IPv4 fragmentation.

NATting UDP is not trivial (see https://en.wikipedia.org/wiki/UDP_hole_punching) and is even more difficult when there is no UDP port number in a packet (as will be the case for all but the first fragment). Some devices and implementations can cope, others not.

Best to avoid this complication by letting the higher layer (IKEv2) perform fragmentation, using its own protocol mechanisms.

Gary
James Edmonds 831 Reputation points

2022-01-31T16:44:43.05+00:00

Diamond, thank you so much!

If you want to add an answer with a copy and paste of that, I'll mark it as the answer!

Thanks again, have a great evening (or day depending on where you are).

James
Gary Nebbett 6,216 Reputation points

2022-01-31T17:00:41.687+00:00

Hello James,

Thanks, but I am here (in this forum) for the "fun of the hunt" (for an explanation/solution) rather than points. Physically, I am here in Basel, Switzerland (a dual UK/CH citizen).

Gary
James Edmonds 831 Reputation points

2022-01-31T17:05:06.747+00:00

Glad to hear you can still get some enjoyment from it. I sometimes attribute my total hair loss to IT and the hunt hahaha!

All the best!
James

Answer 2

Hi there,

When troubleshooting VPN error code 809 the following items should be carefully checked.

Name Resolution – Ensure the VPN server’s public hostname resolves to the correct IP address.
Firewall Configuration – Confirm the edge firewall is configured properly.
Load Balancer Configuration – If VPN servers are located behind a load balancer, make certain that virtual IP addresses and ports are configured correctly and that health checks are passing.

Here is a thread as well that discusses the same issue and you can try out some troubleshooting steps from this and see if that helps you to sort the Issue.

Always On VPN Error 809 on some clients
https://learn.microsoft.com/en-us/answers/questions/649078/always-on-vpn-error-809-on-some-clients.html

-----------------------------------------------------------------------------------------------------------------------------------

--If the reply is helpful, please Upvote and Accept it as an answer--

James Edmonds 831 Reputation points

2022-02-01T10:04:58.557+00:00

Hi,

As per the exchange between myself and Gary in the comments on his answer, the issue looked to be packet fragmentation related.
He gave me a recommended registry entry to change on the VPN server to switch to IKE level fragments instead, and this seems to have resolved the issue :)

Cheers
James

Share via

Assistance diagnosing Always On VPN error 809

2 answers

Your answer