13

First, this problem has existed for almost two years. Until serverfault was born, I pretty much gave up on solving it - but now, hope is reborn!

I've set up a Windows 2003 server as a domain controller and VPN server at a remote office. I am able to connect to and work over the VPN from every windows client I've tried, including XP, Vista, and Windows 7 without issue, from at least five different networks (corporate and home, domain and non.) It works fine from all of them.

However, whenever I connect from clients on my home network, the connection drops (silently) after 3 minutes or less. After a short while, it will eventually tell me the connection has dropped and attempt to redial/reconnect (if I've configured the client that way.) If I reconnect, the connection will re-establish and appear to work correctly, but again will silently drop, this time after a seemingly shorter time period.

These are not intermittent drops. It happens every single time, in exactly the same way. The only variable is how long the connection survives.

It doesn't matter what type of traffic I send. I can sit idle, send continuous pings, RDP, transfer files, all of that at once - it makes no difference. The result is always the same. Connected for a few minutes, then silent death.

Since I doubt anyone has experienced this exact situation, what steps can I take to troubleshoot my evanescing VPN?


Additional background

During this two year span, I have changed ISPs (on both ends), added a new domain controller (my network), and changed routers (both networks). None of that had any affect.

The issue is reproducible from multiple PCs, with different OSes, but only from my network.

I verified that the behavior is client agnostic by testing on a non-Windows device.. I configured the VPN on my iPhone and connected via wifi over my network. Using an app called Scany, I pinged the server continuously until the connection dropped after about 2 minutes - same behavior I was seeing on Windows clients. Afterward, I disabled wifi and VPN'd over AT&Ts 3G and pinged continuously with no lost requests for 11 minutes. This test adequately isolated the issue to my network.

The only consistent component over the two year span is my domain controller which handles WINS and also acts as a VPN server for inbound connections. But, outbound traffic shouldn't route through my DC, it goes straight to the firewall/router, which is connected directly to my cable modem.

More Notes

A request was made that I verify my routes aren't funky when the VPN connection is established. I took a look and don't see anything obviously wrong, but my experience with route configuration is quite limited, so I'm posting the data.

My LAN's class C range is 192.168.1.255, the remote LAN's class C range is 192.168.10.255. I also masked the VPN server's public IP (74.93.XXX.XXX).

>route print (VPN Disconnected)
===========================================================================
Interface List
 17...00 ff 10 80 57 0c ......Juniper Network Connect Virtual Adapter
 11...00 23 ae e6 bb 49 ......Realtek RTL8168C(P)/8111C(P) Family PCI-E Gigabit
Ethernet NIC (NDIS 6.20)
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.24     10
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.1.0    255.255.255.0         On-link      192.168.1.24    266
     192.168.1.24  255.255.255.255         On-link      192.168.1.24    266
    192.168.1.255  255.255.255.255         On-link      192.168.1.24    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link      192.168.1.24    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link      192.168.1.24    266
===========================================================================
Persistent Routes:
  None


>route print (VPN Connected)
===========================================================================
Interface List
 25...........................VPN Test
 17...00 ff 10 80 57 0c ......Juniper Network Connect Virtual Adapter
 11...00 23 ae e6 bb 49 ......Realtek RTL8168C(P)/8111C(P) Family PCI-E Gigabit
Ethernet NIC (NDIS 6.20)
  1...........................Software Loopback Interface 1
 12...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter
 13...00 00 00 00 00 00 00 e0 Microsoft ISATAP Adapter #2
 16...00 00 00 00 00 00 00 e0 Teredo Tunneling Pseudo-Interface
===========================================================================

IPv4 Route Table
===========================================================================
Active Routes:
Network Destination        Netmask          Gateway       Interface  Metric
          0.0.0.0          0.0.0.0      192.168.1.1     192.168.1.24     10
    74.93.XXX.XXX  255.255.255.255      192.168.1.1     192.168.1.24     11
        127.0.0.0        255.0.0.0         On-link         127.0.0.1    306
        127.0.0.1  255.255.255.255         On-link         127.0.0.1    306
  127.255.255.255  255.255.255.255         On-link         127.0.0.1    306
      192.168.1.0    255.255.255.0         On-link      192.168.1.24    266
     192.168.1.24  255.255.255.255         On-link      192.168.1.24    266
    192.168.1.255  255.255.255.255         On-link      192.168.1.24    266
     192.168.10.0    255.255.255.0   192.168.10.134   192.168.10.134     11
   192.168.10.134  255.255.255.255         On-link    192.168.10.134    266
        224.0.0.0        240.0.0.0         On-link         127.0.0.1    306
        224.0.0.0        240.0.0.0         On-link      192.168.1.24    266
  255.255.255.255  255.255.255.255         On-link         127.0.0.1    306
  255.255.255.255  255.255.255.255         On-link      192.168.1.24    266
  255.255.255.255  255.255.255.255         On-link    192.168.10.134    266
===========================================================================
Persistent Routes:
  None
hemp
  • 361
  • 1
  • 3
  • 12
  • Since you have tried to solve this before, can you let us know what you have already tried so we don't rehash things that haven't worked for you so far? – Zypher May 25 '10 at 03:06
  • Most of what I've "tried" involved searching the 'Net for related issues, which ultimately turned up very little. One issue which may or may not be relevant is that the VPN server has some configuration issues. e.g. In order to communicate with it once the VPN is connected, I have to use its IP rather than its name (I typically edit the hosts file on each connecting client.) Also, I always turn off "Use default gateway" when connecting to the VPN because its RAS routing is misconfigured. However, these issues have not caused problems when connecting from any other network. – hemp May 25 '10 at 03:14

4 Answers4

8

Tremendous thank you to @Warner and @William for their suggestions. Ultimately it was William's answer which lead me to the final resolution. For anyone who comes looking, here's the deal.

After a ton of messing around trying to isolate the problem, I finally did as William suggested and pulled up my firewall logs. Not expecting to find anything interesting, I was surprised when I saw this line:

PPTP ALG rejected packet from xxxx to xxxx:1723

Knowing that PPTP is how this VPN is configured, I did some searching on the error. It turns out, other people have seen it as well. Specifically, people with my exact router, the D-Link DIR-655.

The solution, it turns out, is simple.

In the router's web administration interface, access the Advanced tab and click on Firewall Settings on the left-hand menu. In the section labeled "APPLICATION LEVEL GATEWAY (ALG) CONFIGURATION", uncheck the box for PPTP (optionally, also uncheck IPsec if your VPN uses that protocol.) Click "Save Settings" and tell the router to reboot. Voila!

Unfortunately, disabling these ALG options means certain advanced routing features will not work. For instance, the PPTP support is intended to allow multiple NAT'd clients to tunnel to the same VPN server simultaneously. That probably will not work if the box is cleared. However, if like me your VPN doesn't really work at all when the box is checked, you probably don't mind.

I am still unclear as to why I seem to recall having this issue previously with a totally different router, but I'm happy it is working nonetheless.

hemp
  • 361
  • 1
  • 3
  • 12
  • I had a similar problem and what do you know...the same D-Link router. Your solution worked. Thanks! Interestingly, I never had a problem with my VPN until I inserted a Vonage VDV21-VD device between the cable modem and my D-Link router. – staticman Oct 24 '10 at 22:40
  • What firewall logs are showing you this message? Not firewall logs on your VPN client, or VPN server, i assume. – Ian Boyd Feb 09 '11 at 21:22
  • @Ian: No, the firewall is the DIR-655 itself. That's where the logs are (viewable via their web interface.) – hemp Feb 16 '11 at 21:57
  • 1
    This resolved the issue for me as well. Just a heads up: When adding the port forwarding required by VPN. – red Jan 25 '16 at 20:21
2

At a guess, there is a component of the VPN traffic that is required but being blocked (eg at a firewall) or lost, and causing the drop out. Check firewall logs if you have them for dropped packets. Double check the rules to ensure all necessary ports and protocols are enabled. You might also want to do some continuous route monitoring on your end to see if traffic is mis-directed after the VPN tunnel comes up. The "route print" command shows this info on Windows.

William
  • 1,158
  • 8
  • 9
1

I was having the same fault with openwrt and luci, I would connect via vpn to my openvpn server on my router. Connection would be established, then it would keep restarting my 3g modem and loosing my connection, the answer was in, firewall (thank you for pointing the direction) and edit the :1194 connection. Here you have a choice where the vpn connection was coming from and by default it was device, the other two options where lan and wan so for my situation it was wan, a quick change and restart and works great..

Happyman
  • 11
  • 1
0

Basic troubleshooting. Eliminate equipment. Internet connection directly to PC. If reproducible, a different PC. Replace modem, try different ISPs (cell modem). Keep on going down the line until isolated then troubleshoot the equipment it's isolated to.

Warner
  • 23,756
  • 2
  • 59
  • 69
  • Thanks for the suggestions. Along those lines, here's what I can add: During this two year span, I have changed ISPs (on both ends), added a new domain controller (my network), and changed routers (both networks). None of that had any affect. Connecting the VPN server directly to the Internet isn't going to happen, even for a few minutes, so that's out. The issue is reproducible from multiple PCs, with different OSes, but only from *my* network. However, that did give me the idea to try it from a non-Windows client, which I'll try now. – hemp May 25 '10 at 03:34
  • Your work network is already out of scope, as you stated yourself, it's isolated to your network. It sounds like it's your connection or network equipment. Connect your home connection directly to a known working PC against the VPN. – Warner May 25 '10 at 03:41
  • I configured the VPN on my iPhone and connected via wifi over my network. Using an app called Scany, I pinged the server continuously until the connection dropped after about 2 minutes - same behavior I was seeing on Windows clients. Afterward, I disabled wifi and VPN'd over AT&Ts 3G and have been pinging continuously with no lost requests for 7 minutes (and counting). This test adequately isolates the issue to my network. However, I had already done that - so it offers little new information, except that the behavior is client agnostic. – hemp May 25 '10 at 04:05
  • FYI - that ping ran for 11 minutes without issue before I got bored and killed it. – hemp May 25 '10 at 04:08
  • So what's in your network? Is it your routing equipment, "modem," or Internet connection? – Warner May 25 '10 at 04:20
  • I don't think it's any of that since all of it has been replaced since the problem started. The only consistent component is my domain controller which handles WINS and also acts as a VPN server for inbound connections. But, outbound traffic shouldn't route through my DC, it goes straight to the firewall/router, which is connected directly to my cable modem. – hemp May 25 '10 at 04:53
  • 1
    Shut down your DC. Does the issue continue? Connect your workstation directly to the Internet. Does it continue? What equipment was eliminated by connecting directly to the Internet? – Warner May 25 '10 at 17:29
  • I shut down (physically powered off) the DC. Actually I have two - they're both off. No change. I really was hoping that would make a difference... – hemp May 26 '10 at 05:54
  • Step 2, connect directly to the Internet.. – Warner May 26 '10 at 13:14
  • I'm not sure what that accomplishes? I've already shown that taking my LAN out of the equation makes the problem go away - and the closest I can come to a "direct" connection to the Internet is thru my cable modem. But, for kicks, I'll do it anyway. – hemp May 26 '10 at 14:07
  • The whole point of troubleshooting is to isolate to the root issue, which will allow proper allocation of time to focus on the details of the cause. If connecting directly to your modem reproduces the issue, the issue is with your modem or ISP. If it does not, the issue is somewhere with the equipment that was removed by connecting directly. – Warner May 26 '10 at 14:21
  • @Warner: I understand your goal. However I already stated that I've changed ISPs (I'll add that I actually switched from DSL to Cable), so you're essentially asking me to isolate something I already have. As I said, I'm happy to try it anyway. – hemp May 26 '10 at 17:42