Self Control: Windows server connected by VPN service to itself

I must believe in something, so I’ll make myself believe it.
“Self Control” by Laura Branigan, from album “Self Control” (1984)

Task

There were times when we were looking for simple yet unorthodox solutions; and this case was one of them. Imagine, if there was a Windows 2012 server with its standard VPN service (RAS, or, Remote Access, actually), configured and operational. The only problem was that static IP of the server (as should be seen by a connected user) was not up at all times. For instance, assume DHCP IP range for VPN clients was 172.0.2.1 – 172.0.2.199. That makes first address of the range, 172.0.2.1 the server’s address that is accessible by VPN clients (inside VPN tunnel). When server just started that IP would be down – not even pingable, let alone not routable. The IP address becomes live as soon as first VPN client is connected from outside to the RAS service. That presented a challenge for application jobs configured to run in both modes: locally on the server and from remote locations connected to the server. We would configure 172.0.2.1 as a universal connection point for all the applications and grant proper server firewall exclusions, though… they would not be able to connect if no external users connected to the VPN service yet.

Implementation

How to solve this? Simply by inflicting a VPN connection to server from a user session inside the server itself, automatically, right after the server started. First, let us prepare a VPN connection (as a client while we are on the same server):

1. Open Network and Sharing center and click on “Set up a new connection or network”.
2. Choose “Connect to a workplace” and click Next.
3. Skip using existing connection, by choosing “No, create new connection”.
4. Choose “Use my Internet connection (VPN)”.
5. For the internet address enter localhost or 127.0.0.1, if you like that one better.
6. Give a unique name to this connection, for instance selfVPNconn.
7. Suggestion: you would need to create a special user, for instance, we can call that a “selfvpnuser”, that is not used for any other purpose (with minimal privileges, not even part of group Users, just make sure you granted them Dial-In privilege as “Allowed” and choose a complex password, as this same user could be connected from outside.
8. Keep the setting “Remember my credentials” as checked.
9. Important: before connecting for the first time: go to Properties of the new connection (by right click on it) and select Networking tab. There, you may want to unselect TCP/IPv6 protocol and all the services. Then get into Properties of “TCP/IPv4” protocol (that must be selected) and click on “Advanced” and UNCHECK the setting “Use default gateway on remote network”. Failure to adjust this setting would cause a network loop after VPN connected and server would be not accessible until the next reboot. We also recommend to setup client VPN connections for remote users this way to prevent all their internet access to go through the VPN tunnel, but it is not as critical for them.
10. Now you are ready to connect for the first time. Click on the newly configured “selfVPNconn” and enter the user credentials for it to remember and connect. Nothing should happen, except that your server IP address (172.0.2.1 in our case) would be up.

After the first successful connect, storing the user id and password, we were ready to automate this solution. The cmd script selfVPNconnect.cmd that we used contained just one-liner call to RasDial application:

rasdial selfVPNconn

Now we may place this script in a folder like C:\work\bin, create a folder C:\work\log for log records and schedule this script via Task scheduler by condition “On Startup” with a 2 minutes delay (allowing Remote Access and other services to start up after boot) and schedule selfVPNconnect.cmd with redirection >c:\work\log\selfVPNconnect.log 2>c:\work\log\selfVPNconnect_err.log to record the command output.

Voila, just using these hands.