VPN problems - need help badly

I am burdened with fixing a major problem at my place of work: We cannot get consistency from a VPN connection that we need with our State. I am slightly skilled with computers, but no where near most of you posting here. Please forgive any ignorance that I convey with my questions.

We run the Cisco VPN client Version on a handful of machines on our network.

They are supposed to communicate with our State (NC) to establish a secure tunnel to allow our department to run a program that communicates with the State. We use the VPN so that we are able to connect to the State computer via the internet. This saves us money and is much quicker. The downside is that the State now will not help us with our connection because they say that any problems we are having is due to our method of connection (i.e. our ISP for the broadband we connect with).

Our ISP (broadband) is generally reliable - we have had some outages, but none that we can't live with. We have a backup ISP (DSL) so we are covered for any major outage, however our VPN problems exist whether we connect with broadband or DSL, leading me to believe this is the root of our problems.

I have done research to try to fix this problem, however I have not succeeeded. I am looking for ANY and ALL. I will list configuration settings when requested, because I am just not sure where to begin.

Basically, the VPN will timeout and kick the users out of the VPN. I have adjusted the peer response to the max of 480. I have tried to up the MTU to 1500. Then I read a posting that suggested that changes needed to be made of both sides of the VPN to really work.

Please post any and all suggestions. I am a novice but I am trying very hard to resolve this problem that is affecting us in a horrible way. We are a public saftey agency and we really need to get this resolved.

Thank you in advance.

Reply to
Loading thread data ...

What kind of hardware are you using as a router to your broadband provider? Is there any correlation between disconnections? IE, is one person disconnected when another VPNs in? Is there a specific timelimit when the disconnect occurs?

Reply to

I can find no correlation to the time outs on the vpn. One station will be up and running while the another station right next to it gets kicked out. The disconnections appear to be sporadic. I have had reports that users are kicked off together sometimes at 5:00 pm. But that is the only similarity that I can find. No specific time limit and disconnections are definitely not linked to inactivity on the users part - they can be disconnected while working or just after working on the program.

We connect to the internet with a sonicwall.

I also wanted to mention the Windows firewall is disabled through group policy.

Reply to

Do you have any packet loss or excessive latency on the network to the outside world? If you aren't sure, open up a command prompt and do a ping -t . I use usatoday.com (ping usatoday.com -t) but you can use whatever site you want as long as it responds to ping (many have it blocked). Look to see latency or if any pings are dropped. IPSec tunnels are very touchy and are completely unlike web sessions where a dropped packet will simply be re-transmitted. I'm assuming your network is all wired as well and no wireless? Wireless can definitely cause vpn issues if you don't have a well laid out design with excellent coverage.

If many users are in at the same time, and you don't have any idea as to what is causing it via consistent timeouts or drops, then it seems to be leaning towards an issue outside of your network (aka ISP, etc). Do you have any laptops you can take home and try from there or another place with a different internet connection? Will the State pull vpn logs and at least tell you what they are seeing on their side such as timeout or terminated by peer?

The reason I asked about your router is that on personal routers (linksys, dlink, etc), many are known to only allow one IPSEC tunnel at a time. A lot of these were fixed by a simple firmware upgrade, but I doubt this is your issue since you are running an enterprise device. Just as a good play of due diligence, have you checked sonicwall's website for your device/software rev and verified there are no known issues with VPN/IPSec?

Other than this issue, no other known network problems reported right?

Reply to

We do have some wireless on our network. We connect some buildings wirelessly, however the majority, if not all, of the VPN problems occur in the building where the internet connection is local.

I seem to be able to ping outside. When you add the -t to the end, what does that indicate? I tried usatoday and got good responses with one time out error. I am trying google now. With google I also get good responses with one time out error thrown in. How can I tell if this is normal?

I haven't tried to access the VPN from outside our network. My internet access at home is the same as work, so I am wondering if that would be worthwhile? Also, if I can connect the VPN I will not be able to run the state program from home. We have backup DSL here at work and when we switch to it, we still have connectivity problems.

I haven't asked the state to pull the logs, but I will try. Worst they can say is no. Actually the worst they say is they will call or e-mail and then you never hear from them.

I have not checked Sonicwall's website yet - but I will do that today.

Now that you mention it, there is one network problem we have here that is perpetually unresolved. We have one station "CAD1" that can ping its server, but the server cannot ping CAD1. IT (of which I have just been promoted too and all these issues landed on my lap) "fixed" the problem by getting a new machine at that station, but the problem returned. I have no idea if this is related, this is a workstation that we have VPN trouble on, but other workstations without that ping problem have the same VPN issues.

Thank you so much for your responses.

Reply to

Okay, good information here. First and foremost, you really shouldn't be dropping ANY pings to those servers. -t or /t makes ping go on past the default of 4 pings, and it will go on forever. Let it run for a few hundred or so, and look at the results. In the web world, dropped packets are fine, as http will retransmit since it relies on TCP. VPN is an entirely different ballgame and dropped packets will cause the IPSEC tunnel to drop. Latency to the internet should be anywhere between 20-200 milliseconds with 30-50 being the norm for good performance. Latency alone should not cause VPN issues, unless it is all over the place and up in the hundreds or thousands. I am thinking you have an issue with that ISP connection.....

If you have the access, I'd do an nslookup up google/usatoday, and get the IP. Then go to the router and do an extended ping (source it from the internet/external interface if you know how) and ping the two sites. If you are still getting packet loss, this is an issue. Try the other router or connection to the internet. If you are getting the same, and you are using two different providers, it could be something with your cabling or the local telco loop. Regardless, you need to call these issues in and tell them you have an issue that is impacting your business and need immediate support. Escalate as high as you can without getting nasty, hopefully they have something similar to 'sev 1 tickets' and can dispatch a knowledgeable technician.

Wireless is definitely something to watch. If the PC you are doing this ping test on is relying on wifi or microwave between buildings, do the same ping test but use your gateway instead of usatoday/ google. Basically you are pinging across the wifi/microwave and making sure that packet loss is not occurring on your own network. Provided that you are not losing packets or having network issues between your other buildings and your internet gateway router, you should be ok there...but definitely something to keep an eye on in the future.

Can't help you on the CAD1 issue yet. If one can ping the other, then that means traffic is routing correctly both directions or else replies would not be received. Are they on the same subnet or different? Any firewalls present or a DMZ? Same location or across wifi?

Lastly, and just as a reference, I did a ping to usatoday while I was writing this...results are below. The packet loss is most likely your VPN issue or a big part of it.

Ping statistics for Packets: Sent = 500, Received = 500, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 48ms, Maximum = 185ms, Average = 50ms

Reply to

Thank you very much for your help. I am going to work with this info and see if I can't make any progress. I will post as soon as I know anything else.

Again, your assistance is greatly appreciated.

Reply to

You are correct, although he is pinging something on the internet, and his ARP cache will only have his gateway for anything that is not on the same subnet. Also, I would seriously doubt that a dropped packet problem to remote hosts only is a layer 2 issue. I would suspect DNS first for internet issues, but these sessions are established and running, ruling DNS out at this point.

Reply to


-t says to PING continuously until manually stopped.

That sounds fine Don't be concerned if the FIRST PING gives you an error, that may be completely normal. The very FIRST time a machine uses an IP address is will need the destination MAC address for the Packet so it has to do an ARP and receive a reply first, and that could take longer than the PING timeout interval. This is completely normal for the FIRST PING only. All subsequent PINGS should complete normally.

If you do a PING a second time to the SAME host, (within about 5 mins of the first PING), then the ARP cache should still be populated so you should get NO errors that time, but for the FIRST time yes. It all depends on what timeout period is used for your machines ARP cache. This usually could be anything from 10 - 30 minutes (depending on settings) before the ARP entry times out and woudl have to be re-done.


Reply to

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.