Frequent VPN Drop/Missed Heartbeat 227/AT&T Hello, i'm a newb so if i'm in the wrong forum please advise. Please excuse the length but I'm desperate for help.
I work for AT&T Mobility and have a company HP c6460/Windows 7. We use the AT&T GNC for VPN, and I have UVerse internet with three receivers and one PS3 on the network. It seems my issues first started the day I got the new laptop, previously had a Dell/Vista, and experienced no issues dropping off VPN. I use a hard token SecurID as well. Whether i'm wired or wireless, I have the same issue. I will log in about 8am, open Outlook and the other BAU programs, then two minutes later, I lose Outlook connection, internet, but our corporate messenger service will still remain connected. Then a few minutes later I'll get dropped "missed heartbeat - error 227". I reconnect and get the same thing over the next 2-3 hrs.
Magically around 11-12pm my connection is solid all day. I have tried to get UVerse to help but they won't troubleshoot VPN unless I use their ConnecTech fee based service. Our helpdesk will not troubleshoot home network issues. I have had the laptop re-imaged, we've uninstalled/reinstalled the VPN client, tried changing various IP settings, un/reinstalled the network adapter, tried adding IP to DMZ, nothing.
I unplugged all of my devices from the router on 9/6 at 10am and left only the laptop connected, then plugged all back in after an hour and VPN remained connected all day. In fact, it had a great connection as all of the intranet sites I use that are bandwidth heavy ran very smooth.
I can supply more details if someone out there needs them. I am very frustrated as I'm losing hours of work over this. I'm short of replacing the laptop. Any/all friendly advice is appreciated. Thanks, Darin.
Many VPN programs depend on the time and timezone to be set exactly correct in order to maintain the connection.
Verify in your time settings that the PC has the correct time zone set and that you have it adjusting the time automatically based on a NTP server that actually exists.
Try imputing one of these NTP servers and see if that helps. 0.us.pool.ntp.org, 1.us.pool.ntp.org, 2.us.pool.ntp.org, 3.us.pool.ntp.org
reply to dchester
Is it ONLY Outlook / VPN that drops, or the "internet" overall? One key thing I ask when TS'ing
corporate VPN issues is "is is VPN and assoc traffic that drops or VPN AND your overall internet
said by dchester:From the sounds of it, the laptop loses all "internet" / UVerse connectivity per your quote.
then two minutes later, I lose Outlook connection, internet, but our corporate messenger service will still remain connected.
reply to BlueMist
I will try your advice and report back - thanks!
reply to HELLFIRE
Hellfire, one of two scenarios occur: 1) i lose Outlook and internet/intranet after being on vpn about two minutes in. I usually close vpn client and all other programs the re-login. 2) i can be on vpn for up to 15 min then receive the error 227 and the vpn connection is dropped. Each scenario happens about 4 times between 8am-11am.
I do not lose UVerse connectivity. Once off vpn internet is fine. Its only when on vpn i have the problem.
Okay dchester, that helps clarify things.
I don't know how technical you are, but three things I can think of to help out
a) get the exact date / time stamps of the VPN disconnects and get the helpdesk to crossreference with logs
from the VPN headend and see if there's anything screwy -- it may take alittle doing, but if you can show
it's not UVerse taking down the VPN, they can be made to see reason.
b) try this on the same laptop but another internet connection (not UVerse if possible) and see if the problem
follows or not -- if it does, you've just definately ruled out the underlying network so it's either the VPN
client, the laptop, or the VPN headend / infrastructure.
c) install wireshark and set it to run one morning before connecting to the VPN and during the whole VPN session
ESPECIALLY when the problem happens. This is by far the most technically involved, but someone on this forum
or at the help desk ought to be able to take a look at it and see if there's anything screwy going on at the
packet level when this happens.