Phonefactor with RRAS(Windows Server 2003) - VPN client timeout after 20 seconds -- too fast!


  • [Note that I have previously posted this question on Experts Exchange... but have not found a solution yet].

    We are a small business and would like to switch to two-factor authentication for VPN connections. We spent nearly a year helping Barracuda debug their small business VPN appliance and finally they took their boxes back and gave us back our money - they just couldn't get file sharing to work consistently with some new firmware they had to install due to a patent case.

    So... now we are trying Phonefactor.

    Our VPN setup is RRAS on a Windows Server 2003 domain controller.

    We have installed Phonefactor, enabled it as a Radius server, and configured RRAS to point to Phonefactor for Radius authentication. We configured phonefactor to send text messages for authentication, as we figured that would be less disruptive than a phone call.

    It all works except... the timeout for VPN clients is only 20 seconds! By the time we receive the text message on a cell phone, sometimes there is only 5 or 6 seconds to get the six digit code typed into a reply on the cell phone... and unless we are really nimble, that is frequently not enough time!

    When the VPN client times out, it gives an Error 718 "The connection was terminated because the remote computer did not respond in a timely manner."

    How can we increase the timeout on the VPN clients, so we can more reliably enter the authentication code in a reply back to phonefactor?

    Things we have tried:

    1) Connecting (PPTP) from different Windows clients to see if we get different timeout limits. So far we have tried several Windows 7 boxes and a Windows Server 2003 as the client, but in all cases the timeout is 20 seconds.

    2) On the windows clients: Searching through the PPTP client settings to see if there is one labeled "connection timeout". So far we have found nothing.

    3) On the windows 2003 server: Modifying the RRAS Radius Server time-out to be 30 seconds, 60 seconds, 300 seconds. We've tried restarting RRAS after these changes, but the client connection timeout is still 20 seconds.

    4) In the phonefactor configuration: Searching through the radius server settings to see if there is one labeled "connection timeout". So far we have found nothing.

    5) Using NTRadPing to connect directly to the phonefactor radius server. With NTRadPing we were able to wait more than 60 seconds without a timeout from phonefactor. So we don't *think* at this point that the issue is within phonefactor.

    6) We have asked phonefactor support, but their response is "hmmm... good question, we don't know, that sounds like a problem with your vpn client". And they could well be correct.

    7) Search the web for how to increase either the stock windows VPN client timeout, or the RRAS radius authentication timeout. No luck so far.

    8) Try this registry hack: Didn't help.

    Any ideas?


    Wednesday, April 10, 2013 5:52 PM

All replies

  • Hi fdc2005,

    Thanks for the post.

    However, generally, we first type User Name, Password, then click connect to establish the VPN connection. Such as:

    Therefore, I have a little confusion about the timeout you mentioned. Would you please provide us more details.

    Regarding error 718, please check if the following could help:

    If you have a third-party VPN server which does not support MS-CHAPv2 as an authentication method and supports only MS-CHAPv1, you will need to use either CHAP or PAP to connect from the Windows Vista VPN client until the server you use starts supporting MS-CHAPv2.

    Steps to follow for resolution:

    (1) Check if the Routing and Remote Access Server (RRAS) is configured to allow connections with MS-CHAPv2

    (2) Check if the RADIUS server policy supports MSCHAPv2 (This step is needed if you control access to clients using Remote Access Policies on the IAS/NPS server)

    Quote from: Troubleshooting Vista VPN problems.

    Hope this helps.

    Jeremy Wu
    TechNet Community Support

    Friday, April 12, 2013 2:29 PM
  • Hi Jeremy,

    Thanks for the reply.

    1) We are using that same connecting dialog that you show in your screen snapshot. The problem occurs after we enter our username and password and click "connect". What happens then:

         1a) A dialog appears as it connects to our Windows 2003 Server / RRAS.

         1b) The dialog switches to "verifying username/password"

         1c) RRAS communicates to Phonefactor (configured as a radius server) and asks for authentication

         1d) Phonefactor sends a text message to our cell phone containing a six-digit authentication code.

         1e) We must reply to this text message by typing in the six-digit authentication code.

         1f) Phonefactor replies back to RRAS with a "success" message.

         1g) We are successfully connected to the VPN.

    2) Our problem is that we only have 20 seconds to complete steps (1a) through (1f), otherwise we get the error 718.

    3) 20 seconds is not quite enough... often it takes ~10 seconds for the text message to arrive on our phones, so we only have 10 seconds to enter the six digit number. This can be done but you have to be very fast!

    4) So... we would just like to know how to increase this 20 second limit so we can use Phonefactor authentication without having it be a test of our typing skills each time we connect :-)

    I believe that Microsoft now owns Phonefactor:

    So... our attempt to make Phonefactor (now a Microsoft product) work seamlessly with the Microsoft VPN client running on Microsoft Windows seems reasonable, I think!


    Friday, April 12, 2013 5:36 PM
  • Hi Frank,

    Based on my research, this timeout value should be set on server side.

    Please check if the following could help:


    Remote access RADIUS attributes

    Hope this helps.

    Jeremy Wu
    TechNet Community Support

    Sunday, April 14, 2013 10:31 AM
  • Hi Jeremy,

    Agreed - it looks like a timeout issue between RRAS and the RADIUS server.

    I would love to use Set-RemoteAccessRadius to set the TimeOut value on our RRAS -> RADIUS connection... but we are using Windows Server 2003 and it appears from that Set-RemoteAccessRadius applies only in Windows Server 2012. Can this cmdlet be used in Windows Server 2003?

    And, does this cmdlet do anything more than what is accomplished by setting the timeout parameter highlighted below from within the RRAS user interface? We have already set this Time-out to many different values, tried restarting the RRAS service, tried rebooting, etc.



    Tuesday, April 16, 2013 1:56 AM
  • Hi Frank,

    Were you able to resolve this?  I'm having the exact same problem with the exact same environment and have tried exactly the same things, with exactly the same type of responses from MS.



    Thursday, January 16, 2014 3:29 PM
  • Hi Jeremy,

    Has anyone been able to resolve this issue yet?  What you gave was for Server 2012.  This is not applicable in Server 2003.  I have spoken to the windows azure 'team' with similar results as Frank.  


    Thursday, January 16, 2014 10:48 PM
  • Hi Tim,

    Unfortunately we have not resolved this problem yet. But it is back on our list of high priority items for 2014, so if we find anything out I will post an answer here. The solution may just be to go with another two-factor authentication solution that integrates with RRAS.


    Friday, January 17, 2014 1:04 AM
  • Thanks Frank.  That is a bummer.  It is quite frustrating.  I've run a network analyzer this morning, and if I can figure out how to extend the time before PPTP sends the termination request I think that will resolve the issue. But I'm not entirely certain.  I mean, there's very little information out there and at this point I feel like I'm swinging wildly and hoping I'll hit something.  
    Friday, January 17, 2014 2:07 PM
  • Hi Frank

    We used to have the same problem here. After putting quite some work into it, we finally managed to solve it. In our case (W8-Client, Server2012, SSTP) the timeout was as well around 20 to 30 secs, wich was quiet a hassel for users.

    The timeout error 718 is a PPP issue, wich in our case was caused by the client. I havent yet fully investigated the whole thing but the root cause seems to by the following registry Setting on the client:


    If you set the value to 30, you get a lot more time for login.

    As allready stated above I havent figured out yet, why this is the case, but I guess this might be helpfull to you.


    Friday, January 31, 2014 8:06 AM
  • SBT_Dev:

    I think you've got it! I tried your suggestion on a Win7 client just now and I was able to connect even after waiting 60 seconds:

    > Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RasMan\PPP:MaxConifgure=10

    If you set the value to 30, you get a lot more time for login.

    I see that Microsoft has integrated PhoneFactor into WindowsAzure. I'm not sure what that means in terms of what software has to be installed/configured on our Win2k3 server, but my next step is to find that out.

    Thanks for helping us over this hurdle!


    Thursday, February 06, 2014 5:47 PM
  • Hi All -

    Next question - has anyone figured out how to install phonefactor now that it's been rebranded as "Microsoft Azure Multi-Factor Authentication"? In particular:

    - Does it still support Windows Server 2003?

    - How exactly do we purchase it and install it? I've signed up for Windows Azure, purchased a pay-as-you-go contract for MFA, and... been completely baffled about what to do next. Most of the documentation I can find is focused on using it to secure cloud resources. But I have a physical server sitting in a rack at a hosting site that I want to secure. I've spent over an hour on hold with various Microsoft departments hoping to find an answer, but no one yet can tell me - they keep redirecting me to other people who are supposed to know.


    Monday, February 10, 2014 6:57 PM
  • Update - 

    I'm passed the step 0 problem, with help from Chase Anderson at Microsoft. Here is a checklist he sent that helped:

    In particular, it explains in detail how to download the executable if you want to secure a physical machine, which is the part we needed.

    Unfortunately, even though I had uninstalled phonefactor before doing the Azure MFA download, when I installed Azure MFA it picked up all the phonefactor settings, so I don't have a clean test. I'm going to refresh our dev system from prod so I'll have a clean environment, then install Azure MFA from download.


    Wednesday, February 12, 2014 7:34 PM
  • After many months, we have closure (for now) - 

    We installed MFA from scratch on a new refresh from our prod server and it all went well. We did find that we had to increase the RRAS timeout *in addition* to the client-side registry hack identified by SBT_Dev. To change RRAS to use MFA we did as follows:

    Start | Admin Tools | Routing and Remote Access | highlight servername | Properties | security tab | Change authentication provider to "RADIUS" and click configure | Add | servername = (ip of server running MFA), enter shared secret used when setting up MFA as RADIUS server, *CHANGE TIMEOUT TO 120*, keep default ports. Need to restart RRAS after making any changes (in particular to timeouts).

    We are planning to implement on our prod server within the month.



    Tuesday, February 18, 2014 3:54 AM
  • Hi Frank,

    did the server side change fix the issue or does it also need the client side reg hack?

    Thx and greetz


    Tuesday, April 28, 2015 12:38 PM
  • Hi @ll,

    found it out myself. The server side is not enough I had that already in in the radius connection within the NPS server. So the registry key on the client is the key.

    Thx a lot for that hint. Now SSTP with Azure MFA is working nice.

    Greetz Michael

    Tuesday, April 28, 2015 1:03 PM
  • Hi Michael -

    Glad you got it working. In our experience to date, the registry hack reported by SBT_Dev is the key. We've been using the registry change on Windows Vista and Windows 7 Client machines and it has worked perfectly. Will it work with Windows 8? Not sure - we are hoping to skip 8 entirely :-)

    Good luck!

    Tuesday, April 28, 2015 4:33 PM