I’m in the classic computer situation where it’s not working, and everyone is pointing the finger at everyone else.
Basic situation: Me and hubby both work remotely from our respective workplaces. Everything has worked fine for the past several years.
We decided to get out of the snow and cold for a few months, and relocated to a southerly place in a rental house. Rental house comes with wireless internet and ISP. We brought our computers from home.
Everything works fine, except our VPNs. We work for two separate places, meaning two completely different VPNs. In both cases, we can log on just fine, but approximately every 30 minutes both VPN connection die.
The Internet connection itself is fine - we’re not losing browsers or IM or anything like that. Just the VPN.
The ISP is Comcast, and they tell us that the VPNs should work, and that the problem is not on their end.
The router/modem thing is a Motorola SBG900 Gateway - looks like it’s both a modem and wireless router.
Have you thought of setting up Wireshark(or another traffic capture tool) to capture traffic between you and the server?
My WAG is that something that Comcast is running is saying, “Hm, a long-running, high-bandwidth encrypted TCP connection that I can’t identify. It’s probably bittorrent.”
ETA: If the people running your VPN are willing to co-operate a capture from their end might also be enlightening.
If you’re consistently seeing your connection die every 30 minutes, I’d turn on your VPN for 25 minutes and then use Wireshark to start capturing traffic.
I don’t have Wireshark installed on my machine so I can’t give you step-by-step instructions, but it should be pretty easy for you to figure out. Start it up(it’s a GUI application), and then select Capture->(something like start capture).
If memory serves, a window with a bunch of options will come up. The only ones that you should need to worry about are the adapter and “promiscuous mode”. Select the network adapter that you use to access to internet(ie your Ethernet adapter or wireless card). Disable promiscuous mode if it’s enabled, and then select Ok/Start Capturing/Whatever.
You should see traffic start to show up in the main Wireshark menu pretty much right away. Here’s a picture of what it will look like as packets are coming in. If you don’t see any packets being captured, try using the Internet for anything(do something over the VPN, open up a webpage, etc) and then check again to see if any packets were captured. If you still see nothing you probably selected the wrong adapter, so stop the capture and try a different one.
Once you VPN connection dies you can stop the capture. If you know anything about TCP you can look at the last few packets to see why your connection died. If you don’t then it probably won’t mean much to you to look, but you could try. In particular, look for a RST packet.
I don’t know much about TCP, but I’m a programmer, and have coded against various protocols in the past, so I’m not entirely clueless. I’ll take a look and see if I see the RST code you mention. Anything else I should look for?
One side sends a RST packet to the other.
One side sends a FIN packet to the other. The second will send back a FIN packet. The first computer finishes things off with an ACK.
RST, FIN and ACK are just flags in the header. Wireshark will highlight these flags for you. In the picture I linked to, packet #56(fourth one down) shows one computer sending a FIN.
No FIN, no RST. What I do have right before the disconnect is a series of lines that look sort of like the following (I’ve removed the time & IP addresses):
Those are repeated a couple times in between what looks like normal TCP data.
The last 3 lines before the disconnect are:
SSDP M-SEARCH * HTTP/1.1 (this is highlighted in RED)
IGMP V3 Membership Report
IGMP V3 Membership Report
I don’t see these types of lines anywhere else in the trace (I traced for about ten minutes).
I also got a popup from WireShark saying “Error while capturing packets: read error: PacketReceivePacked failed.” I interpret this as WireShark responding to the connection being killed - is that correct?
That is very strange. AFAIK, Wireshark should not react to a connection dying like that. Wireshark doesn’t care about TCP connections, it cares about the network interfaces.
Are you both using the same computer to access the VPNs? It’s possible that Windows is barfing every 30 minutes and killing all of your connections. Maybe it’s a driver issue. Are you connecting to the router via wireless?
How many distinct TCP connections are there in the capture? Wireshark can tell you that; it’s somewhere under the Statistics menu. You’re almost certainly behind a NAT, and the cheaper consumer-grade NAT devices can only handle a couple thousand connections at once.
When I read your OP, my first thought was ISAKMP. Seeing ISAKMP mentioned in your capture, I would bet that it’s the source of your problem. My wife had the same problem with the VPN at her last place of employment.
I don’t have access to my home router’s configuration from here, but I’m pretty sure I solved it by enabling port triggering for UDP port 500. I can confirm this later this evening.
In my wife’s case, my recollection is that the VPN client was initiating a key exchange using ISAKMP over port 500 (over the internet, not the VPN,) and our firewall was blocking the server’s response. After a number of retries, the key exchange would fail, and the VPN connection would drop. By enabling port triggering, the firewall was instructed to briefly direct incoming traffic to UDP port 500 to the machine that had most recently sent something out over the same port.
This worked for us because she was the only one using a VPN w/ ISAKMP. In your situation, with two of you, there is a potential for nearly simultaneous key exchanges causing problems, but I would guess that the chances of this are remote, and are something you could live with.
Well, my latest theory is that the router sucks, so we just ran to the store and got a real router - a Linksys, similar to the one I have in our permanent home. We’ll see if this works.
I’ve had similar problems in the past and had great success lowering the MTU of the internet connection for all PC’s using the VPN. I think the default MTU is 1500 and you try lowering it to like 1400 to see if that works. Don’t mess around editing the registry to do this, theres a neat program called DrTCP.
I can’t really tell you why this works, or what its doing exactly, but its worth giving it a shot and you can always change it back. You can google about vpn’s and mtu anyway.
Just a follow-up: After checking the configuration changes I made to our Linksys router to solve a strikingly similar problem, it was indeed a port trigger for IKE on port 500 that solved the problem.
From your follow-up, it seems that this might not be your problem. For what it’s worth, to diagnose our problem, I used tcpdump (a tool apparently similar to Wireshark) to capture packets immediately before the disconnect, and noticed the seemingly unanswered traffic over port 500. So, the techniques previously suggested by others might work for you as well in diagnosing this.
Some routers are notorious for failing to handle UDP fragmentation correctly. ISAKMP can generate large UDP packets, leading to this kind of problem. Some VPN client software allows you to force TCP instead of UDP to avoid fragmentation problems. Or you can try reducing the MTU as Suda suggests, but you have to do it on every single PC on your network.
I’m not sure what the problem was, but I’ve learned my lesson on cheap routers - it seems like 90% of the networking problems I’ve ever had are fixed miraculously by the purchase of a $150 router. Amazing.
It was probably a good investment regardless of the VPN problems. The lil’ router that came with the house I’m sure is made for casual Internet usage. We counted up all our devices yesterday, and between Mr. Athena and I we have eight active connections going… not exactly your average home user
