Jump to content
RESET Forums (homeservershow.com)

Did a 12/11/12 Windows Update break remotewebaccess.com SSTP VPN?


Jason
 Share

Recommended Posts

No. The 2 clients accessing the VPN were not joined to the domain. However they were both able to connected to the WS2012E VPN without issue prior to the 12/12/12 patch Tuesday. Since then, they can still connect fine only not until after I've REPAIRED the Anywhere Access after each reboot. Odd to say the least.

That would seem normal to me since the clients have no knowledge of the new configuration of the server since they were not domain members. My guess is the update also update Group Policy which your machines would not have gotten since they are not on the domain.

Link to comment
Share on other sites

That would seem normal to me since the clients have no knowledge of the new configuration of the server since they were not domain members. My guess is the update also update Group Policy which your machines would not have gotten since they are not on the domain.

 

I think it must be some other issue since the affected machines are able to connect via VPN fine until the WS2012E box is rebooted. After that, they cannot until the Anywhere Access is repaired on the WS2012E. VPN connectivity for those same non-domain clients is then once again restored. Flaky but a minor annoyance when the WS2012E box isn't rebooted often.

Link to comment
Share on other sites

Remember, VPN is not on the same local subnet. You could create a scheduled task to open the tunnel after a reboot.

Link to comment
Share on other sites

Remember, VPN is not on the same local subnet. You could create a scheduled task to open the tunnel after a reboot.

 

I haven't set up a VPN in quite a few years, but I recall that the only way I got it to work was to have a different subnet 'inside' the tunnel as opposed to 'outside' the tunnel. Is that what you're getting at, and is it still true?

Link to comment
Share on other sites

Actually, the one I setup this year did have the same subnets on both ends so I could map network drives. I still think this issue jason saw was a result of clients not being joined to the domain.

 

Remember, we found "workarounds" for getting non-domain members to be able to be backed up. I think we are now seeing the results/drawbacks of that. But I really don't see the difficulty of joining your clients to a domain. It's less work on the back end and more secure.

 

Just my .02

Link to comment
Share on other sites

Actually, the one I setup this year did have the same subnets on both ends so I could map network drives. I still think this issue jason saw was a result of clients not being joined to the domain.

 

Remember, we found "workarounds" for getting non-domain members to be able to be backed up. I think we are now seeing the results/drawbacks of that. But I really don't see the difficulty of joining your clients to a domain. It's less work on the back end and more secure.

 

Just my .02

 

I think you misunderstood me. I understand having the same subnet for the LANs at both ends of the VPN to facilitate file transfers, drive mapping, etc. I was talking about the IPs for the tunnel itself; what I call the inside of the tunnel. IOW, I had a LAN at one end with 192.168.1.x, with x being between 1 & 100, and the other LAN with 192.168.1.x with x being between 101 & 200. The insde of the tunnel, or the tunnel 'ends' if you prefer, were set to 192.168.2.1 & 102.168.2.2.

Link to comment
Share on other sites

No, I used the same scheme on both ends. I was only trying to get the Homeserver so that was the only address on 1723 that was opened.

Link to comment
Share on other sites

Upon further testing, it appears that rebooting WS2012e is a rather lengthy process. In other words, from the time you restart until when the OS reloads, starts all services, etc. As a result, I may have been attempting to re-establish a SSTP VPN (Anywhere Access) connection from a client PC before the OS was ready.

 

I say this because last night I rebooted, re-logged into WS2012E via RDP (my box is headless) and launched Task Manager. By monitoring the Performance tab, there was approx. 20%-50% CPU usage for some period of time until the CPU settled down to the usual "idle" 2-3% I'm accustomed to seeing. And this was not during any client/server backup window or scheduled tasks.

 

In other words, while the OS is loaded and responding, even serving file shares, it may not be fully initialized for several minutes.

Link to comment
Share on other sites

That is perfectly normal behavior for a server with a major update. If you had a monitor connected to it you would see the "configuring updates" beach ball spinning at startup. After that, services may have been rerigistering, etc. As long as it is running, things like that don't bother me.

 

For the OCD people among us, head to the Event Logs for sometime boring reading. :(

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...