Share via

VPN RAS L2TP error code 619 & 809

Jack45674 15 Reputation points
2023-01-13T11:26:35.0866667+00:00

I have recently had a couple of users report being unable to connect to our onsite VPN, they are reporting error codes 619 and 809 for the RASClient, this did happen on my own machine and I ended up reinstalling windows after trying many different solutions as none seem to have worked and now I have one user that seems to be experiencing the same errors, this solved the problem

These errors are appearing as Error 619 and 809 consistently, with a popup on the windows VPN stating their may be an issue without firewall or NAT. I know that on both instances of this issue no configuration has changed on routers or firewalls, not even any windows updates have been completed since the user was last able to complete a VPN connection and make use of RDP. I have tried updating and reinstalling the WAN Miniport driver, re adding the VPN connection, updating Windows. It seems the user just sits connecting to the VPN and then timing out after 30 seconds to a minute.

I hope someone can shed some light on what could be causing this, or maybe someone is experiencing the same problem. both machines are running 22H2, and although it may not be related, both instances have been with an internet connection provided by SKY Broadband, although the user currently experiencing problems is able to make use of the VPN on another machine, connected to the same network.

We also haven't changed any configuration on our VPN/Company Router, all other users are making use of the VPN and RDP without issue.

Windows for business | Windows Client for IT Pros | Networking | Network connectivity and file sharing
Windows for business | Windows Server | Devices and deployment | Set up, install, or upgrade

5 answers

Sort by: Most helpful
Most helpful Newest Oldest
  1. Gary Nebbett 6,476 Reputation points
    2023-01-18T13:06:27.72+00:00

    Hello Jack,

    If ISAMKP traffic is seen in both directions, then the .etl file is more useful than the Wireshark trace; all but the first packet in each direction is encrypted, so it is difficult to guess what is causing the problem given just a Wireshark trace. The .etl file contains more information about the processing of the received packets.

    The command "pktmon etl2txt [...]" is one way of viewing the contents of the .etl file, although much of the content will still not be understandable.

    I am always happy to look at trace data - you can either post a link to the data here (potentially also requiring an "grant access" request be sent) or mail the data to me at either the short address in my avatar or gary.nebbett at outlook.com.

    The Wireshark trace would have been adequate for some scenarios (e.g. no response to first ISAKMP packet), but if several packets are being exchanged then more insight into the packet contents is needed.

    Gary

    Was this answer helpful?

  2. Jack45674 15 Reputation points
    2023-01-18T11:59:14.1066667+00:00

    Hi Gary,

    Following on from this, I can see that ISAKMP packets are being sent and recieved, I have got a wireshark capture of packets from the local machine, would you be able to review this please, or let me know what I may need to be looking for in order to resolve this problem.

    Was this answer helpful?

    0 comments
  3. Jack45674 15 Reputation points
    2023-01-17T14:53:30.1833333+00:00

    Following on from this, how would I go about using ETW, I am not very familiar and unsure how to configure and use it to monitor traffic for this.

    Was this answer helpful?

  4. Jack45674 15 Reputation points
    2023-01-16T12:59:08.4433333+00:00

    Thanks a lot for this information Gary, I will look into getting this information, I will update as and when.

    Was this answer helpful?

    0 comments
  5. Gary Nebbett 6,476 Reputation points
    2023-01-16T10:11:00.8566667+00:00

    Hello Jack,

    The symbolic names of the errors 619 and 809 are ERROR_PORT_DISCONNECTED and ERROR_VPN_TIMEOUT. The first steps that I would take is to either trace network traffic or use ETW (Event Tracing for Windows) to see which packets are being lost (the loss might be protocol or port specific).

    For L2TP/IPsec, the first packets use UDP port 500, subsequent packets might use UDP port 4500 and/or IPsec encapsulation. When we know which packets are being lost and which network protocol (IPv4 or IPv6) is being lost, we will be in a better position to speculate about the problem.

    If the router/NAT device is capable of displaying log information (or tracing network traffic) then that could be explored in parallel.

    Gary

    Was this answer helpful?

    0 comments

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.