Quickly connect to a VPN on Windows 10 (revisited)

Update (June ’17): it has taken more than 1,5 years since I posted this, but the Windows 10 “Creators Update” finally contains a Connect button right in the Network Connections flyout… ­čÖé

Earlier I wrote about a trick to make Windows 10 connect to a VPN with a single action (double-click) instead of three or more. I recently found that this trick had a limitation: it only worked because the username and password for my VPN connection were the same as the username and password of the Windows 10 computer I was using (a local account). On another Windows 10 pc that was using a Microsoft account, it failed telling me the username / password was not correct:

Remote Access error 691 – The remote connection was denied because the user name and password combination you provided is not recognized, or the selected authentication protocol is not permitted on the remote access server.

Because it worked on the first pc, I assumed that rasdial used the username/password I stored in the VPN configuration. It looks like it doesn’t, but uses your Windows username/password instead (need to verify this). One could discuss whether that is a bug or a feature, but in the end, the result is that it doesn’t work for me.

So I started looking for alternatives. Other tricks I found involved storing the username/password in the command file, but I did not want to do that. The solution is to not use rasdial, but it’s nephew rasphone.

Change the line

rasdial "My VPN connection name here"


rasphone -d "My VPN connection name here"

Mind the -d before the name of the connection.

It shows the familiar connecting dialog, instead of the command line window, and it just works.

Solved occasional VPN RAS error 812

I had the exact problem Roger describes: occasionally a disconnect of my VPN and then unable to reconnect, with error message 812: The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.

His consideration was the same as mine, it could not be configuration or else it would have consistently worked or not. Roger traced it to a DNS issue:

Eventually I was able to isolate the issue to a periodic problem with the RRAS server not being able to connect to the Active Directory server for account authentication.  One of the reason codes occasionally generated in the security event log was:

The Network Policy Server was unable to connect to a domain controller in the domain where the account is located. Because of this, authentication and authorization for the RADIUS request could not be performed.

The cause of the problem ended up being very simple:  The primary DNS of the RRAS server was no longer pointing at the domain controller.  Changing the primary DNS to the domain controller and setting the secondary DNS to an external server (the primary google DNS in this case) eliminated the issue.

Thanks to Roger for taking the time to post that, it probably saved me a couple of afternoons debugging this…

SVN Commit failed, access forbidden

Yesterday I had to commit a project to a fresh and new repository on a Subversion server (VisualSVN Server). So I checked out an (empty) working copy, inserted the files, and committed. The files were added, but immediately after that, TortoiseSVN complained: commit failed (details follow): access to ‘/svn/(RepoName)/!svn/act/(someguid)’ forbidden.’ Errr… what?

Commit failed, access forbidden -- but I do have write access?

So I verified with the server admin that I had read and write permission, which was the case. Googling for answers turned up a possible suspect: casing of the repository name. Turned out my casing was different than what the admin had created. RepoName should have been Reponame (example, of course). With the wrong casing in the svn url, I was able to do checkouts, updates, browse the repository and everything else… but not commit.

So if you ever encounter an error something like this, check your casing. Even on Windows filesystems.

BTW: check out the improvements in the updated TortoiseSVN 1.7, impressive.

Edit (26-01-2012): As Steve pointed out in the comments, the unexpected case sensitivity is not limited to the repository name. Also check the domain part of your user’s logins.