I am using VPN to connect to work. I am used to listening to streaming music when I am in the office, but when i do that over the VPN, the connect drops. So, no big deal, I just won't use the streaming music when I'm on the VPN.
But I just had a Skype meeting with the office, and lost the VPN. So now this is getting in my way and I want to fix it. Any ideas where I should look?
I'm running Server 2008 on a laptop, using a wireless connection in my house to a decent, relaiable DSL connection. I'm using the built in Windows VPN client.
update: On the office side, the VPN is on a DLink firewall - it's PPTP with 128 bit MPPE encryption.
update: I beleve this is related to the DPC latency issue which seems to be plaguing many laptops on the market. I've still not solved the problem. In my case, I'm using a Dell Studio XPS 16, which is one of the laptops with this problem. I'm hoping eventually to find the right mix of drivers to solve the problem.
More than likely you have a root cause: how the traffic is being routed.
For instance, listening to streaming music should not be a problem - because it should NOT be going over the VPN.
Likewise, I would wager if you are using a common video client for your conferences like Skype then you still dont need that traffic going over the VPN. Obviously, this might not apply if you are connecting to a video bridge behind your corporate firewall.
If you are using the Windows VPN client there is a simple way to send non-VPN traffic through your local gateway. If you're using a third party client you'll have to refer to their documentation.
I have run into issues similar to this while using a windows VPN connection to our main office and found the following.
Be sure to limit upstream (and possibly downstream) traffic for any heavy use systems on your network. My dedicated torrent box has been set so that it doesn't eat my entire pipe and cause issues. Even with QOS enabled to prioritize VPN traffic it tends to drop if I saturate the link and increase the latency the connection has to deal with. The PPTP vpn connections are pretty finicky when it comes to latency they tend to drop VERY readily.
I also noticed in your question that you said you are streaming music over your VPN connection? Are you aware that be default Windows VPN connections are set to send all traffic through the remote default gateway? This is in place so that you can route to other networks via the VPN that may not be in the same subnet as your connection. You can easily get around this by disabing the "use default gateway on remote network" here: Connection Properties -> Networking Tab -> TCP/IP properties -> Advanced Button -> General Tab
Once checked this will only send traffic destined for the remote subnet over your VPN connection allowing your streaming music to go out your local network connection without incident. I find this extremely helpful when you are trying to surf the web while working on a remote network, you get your local speed to everything except the remote LAN.
NOTE: if your pptp server device assigns IP addresses to your client system that is in a separate subnet than the network you are trying to get to you may have to work around it.
example: LAN Network address at remote site: 192.168.0.0/24 LAN network address at your house: 172.16.7.0/24 VPN subnet assigned to clients on the router when connecting: 192.168.254.0/24
This is the way windows server handles VPN connections when you use RRAS to host the VPN connections, and I have seen routers handle connections this way as well.
Workaround: you will either need to manually run a route command to add an entry to your routing table after connecting to the VPN, the command will look something like this: route ADD network_to_reach MASK subnet_mask gateway_ip_of_vpn_connection (possibly) route add 192.168.0.0 MASK 255.255.255.0 192.168.254.1
This will tell your machine that it has to use the router at 192.168.254.1 to get to any system in the 192.168.0.0/24 network. Systems inside the network will be using the router hosting the connection as their default gateway so they will not need to be told how to get back to your system.
This can be automated and added to the VPN connection. This is how we manage and deploy clients at our office and it works EXTREMELY well. You can use the microsoft CMAK (Connection Manager Administration Kit) to build a VPN "connectoid" that contains automation instructions including routes to add, scripts to run during different phases of the connect and disconnect process, and some other goodies I've never touched.
Hopefully this will sort out your issues and get you VPN'ing while jamming to your tunes and help some others out there achieve a state of VPN ZEN.
How fast is your connection (usual expected rates, not headline "up to" rates) and at what rate is the audio streaming?
It could be that the extra traffic is delaying VPN packets and responses which the VNOP client sees as a connection drop. On a modern setup (i.e. not dialup) I would not expect to see a single incoming audio stream to be enough to fill your downstream to the point where other traffic is affected, but if you have a connection with a very small upstream rate the outgoing skype data might be enough in induce measurable delays.
If the problem is due to latency issues caused by other traffic then there are two things you can try: see if there are any timeout settings in the VPN client that you can change and that are currently very low, and/or try traffic shaping at your end (though this will only help if the upstream bandwidth is saturated, not the downstream as you can't directly control the downstream flow).
What you might want to consider is packet size. Streaming and skype will surely generate some large packets and vpn sometimes don't play well with large packets as they will add their headers and sometimes go over the MTU.
A quick hack would be to drop your MTU to a low value (~1000B) on your client. That will quickly help you determine if the packet size is indeed the issue.
If i remember rightly, the MTU is set in the registry under windows ...
It's probably better using the same tools on both sides. For example, you mentioned you run the VPN server on DLink, I would say try the VPN client provided by Dlink to see if it gets any better. Or enable RRAS on your Server 2008 box and link to it using Windows VPN connection, and see if it makes any difference.
We had a problem like this a while back with one of the VPN products we used. It was not tolerant of out-of-order arrival of packets, and would terminate the VPN session when it happened. At the time, work was using a bonded pair of T1's and that lead to some out-of-order problems for a number of protocols. TCP is supposedly tolerant of that, but not all protocols using TCP are.
You might want to look into a router that has QoS on it so that the VPN connection gets priority over the other packets.
The other thing that might be the cause (as mentioned by others) is check your upstream bandwidth. Usually downstream bandwidth is pretty high, but the upstream is capped (256k or 356k). You might want to look at changing your broadband plan if the upstream is really low.
-JFV
A PPTP connection is really two connections, a control connection and a data connection. That in itself is a problem with routers and especially firewalls.
Degradation (and promotion) of packet sizes is part of the protocol, so I don't see how that could be a problem, unless you have a really lousy line - because then your packet size might drop to 1 and your upstream will be reduced to bad analog modem speed because of protocol overhead.
But what's a bit worse is that if the control connection receives packets out of order the whole VPN connection gets dropped. Or the control connection is "overrun" by the data connection, which leads to a timeout and therefore a drop of the whole VPN connection.
You mention Skype, and as far as I know Skype uses as much bandwidth as it can get to provide smooth pictures and good sound. Even sound-only Skype connections use upto 16 kBytes/sec which translates to about 128kBit/s, so if your ADSL upstream is even near that, that might be the problem, especially since you ave to add protocol overhead for your VPN connection. Video worsens these bandwidth issues even more.
So if you have any possibility to implement QoS on your ADSL line (ie. your router supports it), set a high priority for port 1723 TCP (which is your control connection), right below ICMP. That might help.
A few things to start with:
1) Which end is dropping the connection? With the VPN up, run pings in both directions and perform packet captures at both ends, ideally of both the encrypted an unencrypted traffic. Cause it to fail and see what happens; you'll likely find one end is sending packets, but the other end is either silently dropping them on the floor or actively rejecting them.
2) Start simplifying things and try again at each step; remove the wireless and plug directly into your router. Bypass the router and plug directly into your modem. Do the same at the other end. You can identify some forms of NAT problems by removing routers from the equation and putting your public IP's directly on the end kit; the amount of networking gear with NAT or ALG bugs is astounding.
3) Check VPN event logs and firewall logs to see if they provide any insight as to why the VPN tunnel is dying. At a minimum, they should be logging the failure and, ideally, a reason why.
4) Try a different PC, try a different OS. See if you can nail down a combination that works.
Once you've found the faulted equipment, you can continue to troubleshoot; you may need to upgrade a device's firmware, add in some NAT/port forwarding entries or adjust your firewall ruleset. If it's specific to a machine, it may need a rebuild or networking stack to be reset (some Broadband Optimiser application can horribly break network stack configuration, and other apps that inject themselves into the network stack may be mangling the packets).
If the problem is due to lack of bandwidth then it's likely that it's your upstream bandwidth that is the issue (assuming you're on an asynchronous connection).
Voice will be using somewhere in the region of 4Kbyte/sec to 11Kbyte/sec on the upstream when you're speaking. Listening to music in itself is the opposite direction so shouldn't affect anything. Are you by any chance using Spotfire to listen to music or something else that does peer-to-peer and thus using all of your upstream?