Frequent VPN disconnects, very little logged information...

    General discussion

  • Hi everyone, I'm pretty sure this issue wasn't already addressed (although I've found plenty of VPN issues, none of them seem to match mine, and none of the found solutions work (so far)).

    We have users worldwide that access the SBS2008 VPN in our office.  With the exception of one site, none of our users are having any problems.  For the site that is having issues, there are 3 users and they always have the same problem at the same time (but the problem isn't kind enough to actually occur predictably) - they can be connected to the VPN for a few hours, but then they'll get disconnected (all at the same time).  It's at least 20 minutes before they can reconnect to the server (to the point that even the forward facing websites aren't visible to them - once again, this would point to a problem at the remote office, but once again - all of their equipment has been replaced and configured with default settings for testing.  This method works at other sites for troubleshooting, but not at the site in question).

    A little background - I've been fighting this issue for over 8 months, assuming (as most would) that the problem is with our remote site.  After having replaced every piece of network equipment at that site, and having Comcast and Integra (both ends of the connection) troubleshoot the connection during an outage but not locating any trouble spots I've come to the conclusion that there's a problem with our server itself.

    I am only finding one log that gets updated during the disconnect:  %windir%\tracing\KMDDSP.LOG

    The errors logged are as follows (they're too cryptic for me to understand - any enlightenment in that direction is certainly welcome!)

    [5748] 12:53:52:195: !   AsyncEventsThread: got a line event
    [5748] 12:53:52:195: !   ProcessEvent: event(00000000002594C8), msg(2), ht_line(0000000000060000), ht_call(00000000800003B3), p1(0000000000004000), p2(0000000000000000), p3(0000000000000100)
    [5748] 12:53:52:195: !   PE::fnLineEvent(CALLSTATE): htline(0000000000010344), htcall(000000000001007B), p1(0000000000004000), p2(0000000000000000), p3(0000000000000100)
    [5748] 12:53:52:195: !   PE::fnLineEvent(CALLSTATE_IDLE): htline(0000000000010344), htcall(000000000001007B), p3(0000000000000100)
    [13904] 12:53:52:195:     lineGetCallStatus(458): call(0000000003BC0004)
    [13904] 12:53:52:195: !   SyncDriverRequest: oid(GetCallStatus), devID(1), reqID(1264), hdCall(0000000000000B8D)
    [13904] 12:53:52:195:     lineDrop(477): reqID(102ad), call(0000000003BC0004)
    [13904] 12:53:52:195: !   AsyncDriverRequest: oid(Drop), devID(1), ReqID(102ad), reqID(1265), hdCall(0)
    [5748] 12:53:52:195: !   AsyncEventsThread: got a completed req
    [5748] 12:53:52:195: !   AsyncEventsThread: req(00000000002930F8) with reqID(102ad) returned lRes(80000048)
    [5748] 12:53:52:195:     lineDrop_post: lRes(80000048)
    [5748] 12:53:52:195:     AsyncEventsThread: call compproc with ReqID(102ad), lRes(80000048)
    [13904] 12:53:52:195:     lineCloseCall(471): call(0000000003BC0004)
    [13904] 12:53:52:195: !   SyncDriverRequest: oid(CloseCall), devID(1), reqID(1266), hdCall(0000000000000B8D

    I'm not even certain that that log applies, but it records an event every time our remote site loses access, so it's a starting point.

    Had to type this up in the middle of work - hopefully it's not too disjointed.  If you have any questions, please let me know and I'll do my best to answer.

    Monday, June 11, 2012 10:27 PM

All replies

  • Not going to be a lot of help, just asking question to jump start the conversation:

    What does the VPN tunnel?  The prefered method is matching routers/firewalls at each end, or a mobile client for individuals that travel a lot.

    Why all this?  Put a terminal server in the main office and RDP, or better, RWA to it and avoid all the VPN hassle.

    Larry Struckmeyer[SBS-MVP]

    Monday, June 11, 2012 11:50 PM
  • Using SBS 2008's built in VPN...I'm not sure of the hardware on the far side (it's Comcast with a Linksys router inside their local network).  On the near side it's Hattaras (never heard of it - used by Integra) with a Watchguard switch on the inside.  I don't disagree that this could be a problem (I've seen it before myself), but considering the sheer number of users that *don't* have these kinds of problems in our company, I'm inclined to think that there's something else going on.  We've got about 40 users that VPN regularly, and only 3 of them have problems, all from the same location.  I thought it would be some drop in the connection between the two providers, but last week more or less proved to me that that isn't the case.  Rebooting/resetting switches on both sides does not change the fact that it takes a minimum of 20 minutes before a new connection can be made.

    Mostly the reason we aren't using RDP exclusively is licensing - my company won't pay for enough TS client licenses to make that happen, at least, not right now (been fighting for 6 months to replace our DC which is nearing it's max user capacity - finally got approval today for that).

    It's the same old story - new guy floats in, lots of legacy configurations and hardware that needs to be changed...can only change so much at once without getting fired :)

    Thanks for popping in Larry - I appreciate the questions...couldn't tell you the number of times that a well-placed question led me to the answer ;)

    • Edited by Roknrol Tuesday, June 12, 2012 12:38 AM Fixed provider name
    Tuesday, June 12, 2012 12:26 AM
  • Aha! A possible glimmer of hope.  <g>

    Watchguard is not a switch.  It is a very good firewall and comes with a mobile client that will create a tunnel from the user to the Watchguard, or from other Watchguardiances.  If you have that in place you might try provisoning the end users with the mobile client.  You use the Watchguard manager to create the code, install the app on the remote system and import the code generated by the management software. 

    Larry Struckmeyer[SBS-MVP]

    Tuesday, June 12, 2012 10:55 AM
  • My apologies for misrepresenting our network...I know that Watchguard is a firewall, not a switch - I can't imagine that being a problem though, since we have anywhere from 10-20 other users around the world that connect to the VPN using the same methods.

    Is there any documentation anywhere that can help me decipher the logfile?  That seems to be the only consistent report during the disconnects...I'm sure it's telling me something important, I just don't know what :)

    Tuesday, June 12, 2012 5:01 PM
  • Hi Roknrol,

    Thanks for posting here.

    We have a similar issue before which caused by router device , I know perhaps hardware might not the cause in your case , however in order to investigation, could we collect the information that required in that thread?

    VPN Client disconnects after 30sec to 1 min after connecting WIN 2008 R2 RRAS PPTP


    Tiger Li

    Tiger Li

    TechNet Community Support

    Wednesday, June 13, 2012 8:24 AM
  • Thanks Tiger Li - I've enabled the logging, however today the connection was so horrible that the folks have headed to other locations to work for the day.

    I can answer some of the questions, however:  When the VPN drops (again, this happens for all 3 users at the same time) they get no popup or warning messages (unless they were connected to a network resource other than the VPN, then it reports that it lost the connection).  The other thread did help a bit, as it pointed out some info in the error logs that may be useful.  Whenever the disconnection happens, SBS 2008 records the (informational - not warning or error) event 20272 as follows:

    CoID={38DD4F2C-AA0C-4FDD-854C-54C8E467EA0C}: The user domain\username connected on port VPN2-16 on 6/13/2012 at 6:32 AM and disconnected on 6/13/2012 at 8:26 AM.  The user was active for 114 minutes 0 seconds.  65412778 bytes were sent and 6526152 bytes were received. The reason for disconnecting was user request.

    Normally I would assume user error, however 2 of the 3 people this happens to are fairly savvy and not prone to bonehead mistakes...also, they all drop at the same time so not likely user error.

    Of all of the logfiles in %windir%/tracing the only one that has recorded errors thus far is KMDDSP.log.  This may change with enabling the debugging - I won't be able to test that until the users are back onsite and have another failure.  This will likely be tomorrow morning, however any additional suggestions are welcome :)

    Wednesday, June 13, 2012 6:08 PM
  • Hi Roknrol,

    Thanks for update.

    Yes , event ID 20272 can't provide any valuable clue and let us to isolated this issue and it will be great to have logs .

    If there is any update on this issue, please feel free to let us know.


    Tiger Li

    Tiger Li

    TechNet Community Support

    Monday, June 18, 2012 5:40 AM