After three days of troubleshooting, I finally got a small RRAS VPN lab working in Windows Server. The first issue was that the client connected but never received an IP address. Configuring a static address pool from 192.168.56.100 through 192.168.56.120 fixed that.
I then simplified the setup to focus on PPTP because this was only a learning exercise and I wasn't using L2TP, SSTP, or IKEv2. The connection eventually established, but the client couldn't reach the server. Checking the firewall, GRE traffic, routing, and RRAS interface bindings helped resolve the connectivity problem.
Finally, I ran into authentication error 691 despite using valid domain credentials. The client wasn't configured to use MS-CHAP v2, and enabling it allowed the VPN connection to complete. I verified the result from a Windows 11 client and confirmed connectivity to the server at 192.168.56.10.
This was strictly a homelab exercise to better understand RRAS, VPN authentication, routing, and firewall behavior. I wouldn't use PPTP in production because it's obsolete and insecure. For people who have managed RRAS or Windows-based VPNs in production, what issue has been the most common in your experience?
4 Answers
The fundamentals you worked through—address assignment, routing, firewall rules, protocol support, and authentication—are exactly the right troubleshooting layers. The main caveat is that PPTP is useful for understanding the pieces in a lab, but it should not be used for a real deployment. Modern environments generally use IKEv2, SSTP, or a newer VPN or zero-trust access product.
In production, expired or untrusted certificates are a common cause of SSTP handshake failures. Clients behind NAT can also need specific configuration changes. NPS policies are another frequent culprit: a dial-in condition may silently reject a valid user, while the useful explanation only appears in the server's event logs.
For IKEv2 Always On VPN, packet fragmentation and MTU problems are frequent, especially with home-user firewalls. A firewall reboot can sometimes appear to fix the problem, which makes the root cause easy to miss. Expired server certificates are another major one.
RRAS can still be educational, but for production I'd seriously evaluate a modern VPN gateway or ZTNA platform with centralized policy and inspection. That usually provides better security and visibility than relying on legacy PPTP settings.
It's also worth checking TCP idle timeouts on intervening firewalls. Some devices terminate otherwise healthy sessions after a fixed period, so increasing or disabling that timeout can prevent confusing disconnects.