none
VPN on SBS 2011 Essentials

    Question

  • Has anyone else gotten VPN to work on SBS 2011 Essentials and can provide any tips?  I found one post in the regular SBS forum about someone who got it to work but no explanation of how, and a post by someone else about configuring VPN on regular server 2008.

    I've read the article pointed to in that other post and several others both by Microsoft and others and I can not get it to work.

    Ideally I'd like it work over SSTP so I don't have to open the additional ports on the firewall but getting to work in ANY way would be a plus.

    With SSTP, can the single server handle both the Remote Web Access web site and VPN SSTP on port 443?  Something tells me not, partially becuase any time I enable Remote Access on my SBS 2011E server it kills RWA web site.

    But there's nothing in the config wizard or other documentation I can find that tells me how to disable SSTP support for VPN to keep the RWA site working but still allow the VPN to function with other protocols.

    And on the client I'm trying to use to connect is Windows 7 and it still won't connect with ANY protocol (I do have necessary ports forwarded and VPN passthrough enabled on the router) so there's still something beyond the SSTP config.

    Any help, please?  Thank you.

    Wednesday, January 25, 2012 9:03 PM

Answers

  • Though I have been a huge supporter of VPN’s for years, their practicality is very quickly waning in favor of newer and more secure technologies.   VPN’s have at least one major security flaw, a wide open tunnel that allows any and all traffic, legitimate or malicious, between an unknown remote computer and the corporate network.  Options available to SBS such as RWW/RWA and OWA are far more secure, and additional newer services like Direct Access and Branch Office caching are far superior to VPN’s.   Having said that there can be reasons to require a VPN.   However, if doing so, purchasing a proper VPN router is far more secure in that it moves authentication to the perimeter of the network, uses IPsec, and usually has a client that requires admin management, rather than being easily installed by anyone and everyone.  VPN routers are very affordable these days starting at $150, though proper routers that support RADIUS authentication are a little more.

     

    Regardless none of that answers your question.  SBS has always used the standard PPTP VPN.  If that is sufficient for you I have blogged (below) as to how to configure server and client with SBS Essentials.  As for SSTP, it is my personal opinion that the amount of time/labor to configure would be better spent on a proper hardware VPN device.  

    http://blog.lan-tech.ca/2012/01/28/sbs-2011-essentials-configuring-vpn-access/


    Rob Williams
    Saturday, January 28, 2012 11:51 PM
  • THANK YOU ROB!!!!  You're a life saver!!  I got it working.  Side note, it's kind of funny but I work a guy named Rob Williams. :)

    First, there is one little thing in your blog instructions.  At least in my case, it did NOT start the service for me automatically.  After the config I had to right-click on the RRAS item in Server Manager, click All Tasks and Start.  (It started the service automatically in several other attempts where I chose the direct "VPN" option in that first screen, but when I go through Custom as you suggest, it does not start the service automatically for me.)

    The key config difference between your setup and what I had been doing was configuring RRAS to use the static IP range on the SAME subnet as the server.  I THOUGHT I had tried that at one time, but maybe I never did, or maybe I only tried it after having used the "VPN" option when configuring RRAS instead of the "Custom" config and something else wasn't configured correctly because of that.  I know I tried the static range on a different subnet per another KB article I found (as mentioned in a previous post).  It's odd though, the DCHP releay does work if I try to use that with RRAS, I just can't see the server with that config.  My DHCP is my router.  I do get a valid IP address on the same subnet as the server assigned to my VPN client when connecting, but for some reason it just will not see the server.  When I changed it to use the static IP range on the same subnet (outside of the range that the DHCP server will dole out), it worked and I could see the server from the VPN client.

    One way I could tell that it worked, vs. when I connected but it wasn't working right, my client is Windows 7 with the "Network and Sharing Center".  When it didn't work, the VPN network after it connected would just show up as another network and it asked me what type of network it was (public, work, home) and I selected "work".  When it finally worked correctly, after the VPN connected it actually showed up in the Network and Sharing Center as a Domain network showing the AD domain of the server.

    Your blog article says that name resolution may not work without additional client config.  It does on mine without anything additional.  Although maybe that's because the client PC is a laptop that was joined to the domain when plugged into the physical LAN with the server and then taken home, so maybe it retains that name resolution as being part of the domain?

    Also, SSTP works just fine.  I even removed the port 1723 forwarding from the router and set the VPN client on the computer to force SSTP to be sure (I did this after I knew it had established a connection using the forwarded port and the client config at the default "Automatic" setting for the protocol).  I didn't have to do anything special to configure it, it just works.  The RRAS config automatically adds ports for it.  This may be an advantage to this being an SBS server though and not typical of a standalone server.  With SBS 2011 Essentials setting up the SSL certificate for you for Remote Web Access using a .remotewebaccess.com URL, I guess that includes what is needed for VPN to work over SSL as well.  Maybe if purchasing a 3rd party certificate, if it's purchased without the required config to support server authentication (as I read in another article somewhere) then maybe it won't work.  But with the certificate I got from Microsoft for just the .remotewebaccess.com URL, SSTP works just fine with the VPN.

    Now the thing I'd like to do is get the server to route external Internet traffic through the VPN.  I know I can set up split tunneling on the client side by unchecking the "Use default gateway" in the VPN connection properties, and that's how it's set up today with this user on their SBS 2003 server, but I read so much about how split tunneling is a security risk and I'd like to lock that down.  But the user absolutely has to be able to browse the regular Internet when connected to the VPN.  I can't seem to find any info anywhere on how to configure the server to route the public Internet traffic through the VPN on a Windows server.  (I've found several posts about how to do it on other VPN servers like on Linux and such, but nothing with direct instructions for a Windows server.)

    • Marked as answer by clh42 Monday, January 30, 2012 9:06 PM
    Monday, January 30, 2012 9:06 PM

All replies

  • I'm researching this too. I was able to get the Routing and Remote Access service running on SBS 2011 Essentials but I need to know how to enable VPN access for individual users. A nice "how to" would be nice for the whole process though.


    Dave Tschoepe Beenanza, LLC
    Thursday, January 26, 2012 7:24 PM
  • I'm making progress but not there yet.  I now can at least get the client to connect to the server over SSTP, AND it does NOT kill the RWA web site, but I can't actually access the server's file shared through the VPN.

    After several experiments, here's what I had to do to get the VPN set up and not kill the RWA web site. 

    One of the first articles I found with instructions for settin the VPN on Server 2008 said to use the "Virtual private network (VPN) access and NAT" option in the configuration wizard.  This absolutely does NOT work (at least on an SBS 2011 Essentials server).  This both kills the RWA web site and the client will not connect.

    So disabling RRAS and then running through the config wizard again, I choose only the top "Remote access (dial-up or VPN)" option.  I choose VPN only on the next screen.  Then on one of the screens there is a checkbox for "Enable security on the selected interface by setting up static packet filters."  You must UNcheck this box.  This is the only way I could get it to not kill the RWA web site and to allow the client to connect.

    I also tried using the "Custom" option on the first screen and then choosing only VPN on the next screen.  You never get prompted for that "Enable security" checkbox when going through this way, but it also seems to work.

    So after that, I am now able to connect with the client to the server over SSTP, but as mentioned above, I cannot see any of the server shares.  The PC I'm connecting from has been added to the server domain using the http://servername/connect stuff and works okay when physically plugged in to the same network.

    I've been through a bunch of different things today removing and reconfiguring the RRAS stuff and I can not get it to see the server yet.

    Thursday, January 26, 2012 9:45 PM
  • I'm still tearing my hair out on this.  2 1/2 days on this and I can't this to work if my life depended on it.

    After a couple more hours of searching I found a link to this KB article about having VPN on the same server running DNS, WINS, or being a domain controller: http://support.microsoft.com/kb/320697

    As I thought about it, most of the examples I found of setting up a VPN server did describe having a separate domain controller server, but nowhere did they say that it HAD to be that way or that it worked any differently if the DC and VPN server were on the same box.  But of course SBS is an all-in-one server with being a DC and running DNS, although my SBS2011E install apparently is NOT running WINS which I found interesting but I'm not going to question it.  And I know VPN works on SBS 2003 because we have it running on one (but there it's part of the normal wizards to configure VPN).

    This article is about Server 2000 and Server 2003, but but as I read through it I was definitely experiencing odd active directory issues, including the error it explicity lists about Netbt and a duplicate name on the network.  I hadn't associated them with the VPN until I read this.  But as I was having those exact symptoms I decide to try it out anyway.

    I first tried the workaround at the end of this article about specifying a separate static address pool with a different network segment from the segment the server is actually on.  That got me another step closer, but not all the way there yet.  I could now ping the server and get a response both by name and by IP address from the client when connected to the VPN, but I still could not access any of the file shares on the server via either name or direct IP address.

    I decided to give the full solution from this KB article a try, but no go.  Doing that I'm back to where I can't even get a response to a ping over the VPN.

    I even looked at the RRAS setup on the SBS 2003 server that I have running VPN (that this SBS 2011E server is supposed to replace) to compare to this new server, but I can't see anything obvious, and it looks different on the SBS 2011E server to where I'm not sure what I can compare.  Some of the things in the RRAS config in Server Manager on SBS 2011E aren't there on the SBS 2003 server.

    So PLEASE, any help here would be GREATLY appreciated.  As I said, I'm replacing an old SBS 2003 server with a new SBS 2011E server and they use VPN on that current server and won't be happy if I have to take it away.  (We no longer use Exchange, we're on a 3rd party hosted Exchange now for e-mail, so we wanted to save the extra expense of the SBS 2011 Standard OS and CALS.  This VPN is the ONE thing I need that is a normal part of SBS standard but since it's also a part of normal Server 2008 that SBS is based upon I thought I should be able to do it in SBS Essentials.)

    Thank you.

    Friday, January 27, 2012 10:11 PM
  • Sorry for the pain you are going through. Apparently this is a huge shortcoming of SBS 2011 Essentials. I wonder if there is a third party VPN product we could use that would make this task easier? 

    I am following your progress with interest though....


    Dave Tschoepe Beenanza, LLC
    Saturday, January 28, 2012 5:45 AM
  • Though I have been a huge supporter of VPN’s for years, their practicality is very quickly waning in favor of newer and more secure technologies.   VPN’s have at least one major security flaw, a wide open tunnel that allows any and all traffic, legitimate or malicious, between an unknown remote computer and the corporate network.  Options available to SBS such as RWW/RWA and OWA are far more secure, and additional newer services like Direct Access and Branch Office caching are far superior to VPN’s.   Having said that there can be reasons to require a VPN.   However, if doing so, purchasing a proper VPN router is far more secure in that it moves authentication to the perimeter of the network, uses IPsec, and usually has a client that requires admin management, rather than being easily installed by anyone and everyone.  VPN routers are very affordable these days starting at $150, though proper routers that support RADIUS authentication are a little more.

     

    Regardless none of that answers your question.  SBS has always used the standard PPTP VPN.  If that is sufficient for you I have blogged (below) as to how to configure server and client with SBS Essentials.  As for SSTP, it is my personal opinion that the amount of time/labor to configure would be better spent on a proper hardware VPN device.  

    http://blog.lan-tech.ca/2012/01/28/sbs-2011-essentials-configuring-vpn-access/


    Rob Williams
    Saturday, January 28, 2012 11:51 PM
  • Rob, thank you for your comments.

    I will check out your blog entry and give it a try.  SSTP would be preferred to avoid opening the other ports in the external firewall, but their current server is SBS 2003 which of course is NOT using SSTP so we can stick with that if we have to.  Though as I mentioned in previous posts, I'm not sure that's the problem here now.  I DO have the client connecting over SSTP, it just can't see the server once connected.  And in earlier testing, I couldn't get it to connect over any other protocol either.  But maybe I'll find something in your blog that point me in the right direction.

    I MIGHT consider getting a new router with VPN built in, but I have a question on that.  Will the standard VPN client that's built in to Windows connect to that?  Or do you have to a router with the VPN on it on both ends?  I might get them to buy one new router, but I won't be able to get them to buy 2 of them if one is needed on each end.

    Beyond that...

    Yeah, I would personally just assume they use the new shared folder feature built in to the new RWA on SBS 2011, but this one person works from home a lot and we really want them have a similar experience to when they're in the office instead of having to go through extra steps for constantly having to download and upload files via the RWA interface.  If it were just occasional need that would be one thing, but this full days, 2 or 3 days every week.

    Purchasing another product to accomplish this kind of defeats the cost savings of an SBS server as an all-in-one solution.  If there was something out there pretty cheap I might consider it (like the router with VPN built in) but they likely won't spend another couple hundred dolllars on a 3rd party solution, especially when everything I read says it SHOULD work.

    I'll post back after I've had a chance to check our blog and try some things based on that.  Thank you again!

    Monday, January 30, 2012 2:37 PM
  • I have never seen SSTP configured on an SBS. I am not saying it won’t work but there may be conflicts with other SSL/port 443 services and the certificate. Most often SSTP is set up on a dedicated server and used in conjunction with NPS (Network Protection Service) that can be used to quarantine a connecting PC until it is scanned for A/V, and windows updates, firewall is enabled, and other parameters you select.
    >>”it just can't see the server once connected”
    If the subnet used at the SBS site and the client site are the same you will experience that.  They must be different for example one using 192.168.1.x and the other 192.168.2.x.  Otherwise routing cannot take place.
    If the VPN client is assigned an IP outside of the SBS LAN range, you can also have firewall issues. Try disabling the SBS and any 3rd party firewalls as a test.
     
    Often best to start with PPTP and build from there.
     
    As for a VPN router, many support the Windows client, but in most cases only for PPTP.  All VPN routers offer their own VPN client, usually IPSec, some are included, some you pay extra, but you do not need 2 routers and a site to site VPN.  For the record, my preference is a Cisco ASA5505.  The basic unit allows 10 Internet connections and 10 VPN clients for <$500.  More users, more money.
     
    If you have a home user, the VPN will not duplicate an office experience. It is very slow, often 1/100th the speed of a LAN connection which leads to frustration.  The speed is determined by your corporate upload link, not download.  Also database apps like accounting applications will not work over a VPN due to the slow link, and can even lead to data corruption.  The other issue with VPN’s is they often ‘just don’t work’.   VPN protocols often are not supported by remote routers, or ISP’s and there are often conflicts with software on client computers. This combined with the security issue of having an open tunnel to a remote computer over which you have no control really make VPN’s, for home workers, a tool from the last century.  Yet they still do work J
     
    For home workers you cannot beat remote desktop for security, performance, and an almost identical experience to the office.  You can achieve this either by using a Terminal Server (RDS) or having a dedicated workstation for that home user at the corporate site.  The dedicated workstation can be a virtual machine if you like.  It is now common to have several virtual workstations just for remote users.  The Terminal server,  physical or virtual workstation, is joined to the domain and accessible through Remote Web Workplace/Access.  Remote clients love this.
     
    Unfortunately SBS is not an all –in-one solution but it does come darn close.  If you had SBS with the Premium add-on it would include an additional server that could be used as a Terminal Server.  However configuring a single workstation would be far less.

    Rob Williams


    Monday, January 30, 2012 3:05 PM
  • I'm still playing with things from your blog on my end but to address some things in your previous post...
    >>”it just can't see the server once connected”
    If the subnet used at the SBS site and the client site are the same you will experience that.  They must be different for example one using 192.168.1.x and the other 192.168.2.x.  Otherwise routing cannot take place.
    Yes, I'm familiar with how all the subnets must be different and was already taking that into account.

     

    If the VPN client is assigned an IP outside of the SBS LAN range, you can also have firewall issues. Try disabling the SBS and any 3rd party firewalls as a test
    Had tried disabling the firewall already.

     

    For the record, my preference is a Cisco ASA5505.  The basic unit allows 10 Internet connections and 10 VPN clients for <$500.  More users, more money.
    Yeah, I'd be looking for something more like $100 to $150.  See other comment below about cost.

     

    If you have a home user, the VPN will not duplicate an office experience. It is very slow, ...<snip>  Also database apps like accounting applications will not work over a VPN due to the slow link, and can even lead to data corruption
    Yes, obviously it's slower, understood, but as I mentioned, this user is already operating this way today on their current SBS 2003 server and is used to it.  They also don't use any applications over the network.  It's just purely accessing documents and a few data files which work fine.

     

    For home workers you cannot beat remote desktop for security, performance, and an almost identical experience to the office.  You can achieve this either by using a Terminal Server (RDS) or having a dedicated workstation for that home user at the corporate site.  The dedicated workstation can be a virtual machine if you like.  It is now common to have several virtual workstations just for remote users.  The Terminal server,  physical or virtual workstation, is joined to the domain and accessible through Remote Web Workplace/Access.  Remote clients love this.
    Yes, I've tried to suggest Remote Desktop to the office in the past for this. As we know SBS already supports this through the RWA interface.  But they prefer this user has a laptop to travel with and don't want the extra expense of a 2nd PC that she'd leave in the office to remote into.  Suggestions like virtual machines are WAY more complicated and expensive for this office than what we're trying to do.  It would be way cheaper to just have an extra desktop PC for this user to remote into.  See below comment about costs.

     

    Unfortunately SBS is not an all –in-one solution but it does come darn close.  If you had SBS with the Premium add-on it would include an additional server that could be used as a Terminal Server.  However configuring a single workstation would be far less.>
    Well, agreed, SBS is not an ALL-in-one solution for everyone, but for this office it's good enough.  This is a "SMALL" office, 12 people, of an independent business (one owner, 11 employees).  Cost is a major factor.  They've been using SBS 2003 for 6 years now (first SBS 2003 for 3 years, then SBS 2003 R2) and it's time to upgrade their server again.  Things like a VPN router (for $100 or $150 maybe but definitely not upwards of $500) or another server to virtualize desktops, especially for one person, are cost-prohibitive, especially when it can be done via the VPN on the server.  As I mentioned, they've been using VPN for this user for quite some time now on their existing SBS 2003 server and it's worked well for them.
    Monday, January 30, 2012 7:47 PM
  • No problem at all.  Sorry I wasn't trying to discredit what you were trying to do, just suggesting all options.  And, keep in mind hundreds of others will read this so the suggestions are for their benefit as well.  VPN's still work as mentioned.

    Should it ever be of interest, virtualization is quite affordable with the most expensive additional part often being the desktop operating system license. Often it can be added to existing hardware, and the virtualization software is free.


    Rob Williams
    Monday, January 30, 2012 7:59 PM
  • THANK YOU ROB!!!!  You're a life saver!!  I got it working.  Side note, it's kind of funny but I work a guy named Rob Williams. :)

    First, there is one little thing in your blog instructions.  At least in my case, it did NOT start the service for me automatically.  After the config I had to right-click on the RRAS item in Server Manager, click All Tasks and Start.  (It started the service automatically in several other attempts where I chose the direct "VPN" option in that first screen, but when I go through Custom as you suggest, it does not start the service automatically for me.)

    The key config difference between your setup and what I had been doing was configuring RRAS to use the static IP range on the SAME subnet as the server.  I THOUGHT I had tried that at one time, but maybe I never did, or maybe I only tried it after having used the "VPN" option when configuring RRAS instead of the "Custom" config and something else wasn't configured correctly because of that.  I know I tried the static range on a different subnet per another KB article I found (as mentioned in a previous post).  It's odd though, the DCHP releay does work if I try to use that with RRAS, I just can't see the server with that config.  My DHCP is my router.  I do get a valid IP address on the same subnet as the server assigned to my VPN client when connecting, but for some reason it just will not see the server.  When I changed it to use the static IP range on the same subnet (outside of the range that the DHCP server will dole out), it worked and I could see the server from the VPN client.

    One way I could tell that it worked, vs. when I connected but it wasn't working right, my client is Windows 7 with the "Network and Sharing Center".  When it didn't work, the VPN network after it connected would just show up as another network and it asked me what type of network it was (public, work, home) and I selected "work".  When it finally worked correctly, after the VPN connected it actually showed up in the Network and Sharing Center as a Domain network showing the AD domain of the server.

    Your blog article says that name resolution may not work without additional client config.  It does on mine without anything additional.  Although maybe that's because the client PC is a laptop that was joined to the domain when plugged into the physical LAN with the server and then taken home, so maybe it retains that name resolution as being part of the domain?

    Also, SSTP works just fine.  I even removed the port 1723 forwarding from the router and set the VPN client on the computer to force SSTP to be sure (I did this after I knew it had established a connection using the forwarded port and the client config at the default "Automatic" setting for the protocol).  I didn't have to do anything special to configure it, it just works.  The RRAS config automatically adds ports for it.  This may be an advantage to this being an SBS server though and not typical of a standalone server.  With SBS 2011 Essentials setting up the SSL certificate for you for Remote Web Access using a .remotewebaccess.com URL, I guess that includes what is needed for VPN to work over SSL as well.  Maybe if purchasing a 3rd party certificate, if it's purchased without the required config to support server authentication (as I read in another article somewhere) then maybe it won't work.  But with the certificate I got from Microsoft for just the .remotewebaccess.com URL, SSTP works just fine with the VPN.

    Now the thing I'd like to do is get the server to route external Internet traffic through the VPN.  I know I can set up split tunneling on the client side by unchecking the "Use default gateway" in the VPN connection properties, and that's how it's set up today with this user on their SBS 2003 server, but I read so much about how split tunneling is a security risk and I'd like to lock that down.  But the user absolutely has to be able to browse the regular Internet when connected to the VPN.  I can't seem to find any info anywhere on how to configure the server to route the public Internet traffic through the VPN on a Windows server.  (I've found several posts about how to do it on other VPN servers like on Linux and such, but nothing with direct instructions for a Windows server.)

    • Marked as answer by clh42 Monday, January 30, 2012 9:06 PM
    Monday, January 30, 2012 9:06 PM
  • Glad to hear you were able to get it working.

    >>"it did NOT start the service for me automatically."
    RRAS should automatically start and set the service to "Automatic (Delayed start)". If it doesn't start make sure it configured the later or it will fail after a reboot.

    >>"The key config difference between your setup and what I had been doing was configuring RRAS to use the static IP range on the SAME subnet as the server."
    Though it doesn't have to be the same subnet, if it is not you have to assign a static route to the client. The problem with doing that is the IP, which would be the gateway for the route, changes every time the IP changes. You can push that out in a couple of ways. If you want to do that one method is using CMAK as per another blog article I did entitled "What happened to the SBS Connection Manager" The link is at the bottom of this post.
    DHCP relay can be used as well, but most inexpensive routers will not work properly. Easier to to use a static address pool. 

    >>"Your blog article says that name resolution may not work without additional client config. It does on mine without anything additional. Although maybe that's because the client PC is a laptop that was joined to the domain."
    A domain joined machine would have the domain suffix automatically assigned, which is a key requirement. The link below also explains how to create a deployable client like the old SBS 2003 Connection Manager that will provide proper name resolution, easily.

    >>"Also, SSTP works just fine.......I didn't have to do anything special to configure it, it just works."
    I found this interesting as the certificate creation and distribution is the only lengthy part of setting up SSTP. Configuring RRAS and the client is basically automatic. Normally you have to enable the Certificate Authority Service, create and manipulate the certificate, deploy or set up web deployment for the certificate, and install the certificate on the client. In your case it may be that although SBSe doesn't use self signed certificates, it does create one, and when you run the connection wizard to join the domain it does import that certificate to the PC's trusted root certificate store. You may find your SSTP VPN will not work on non-domain joined PC's. If you have a 3rd party certificate you can make it work, but the process can 'break' parts of RWA, or at least TS Gateway on SBS std, until you tweak it. As for the Microsoft "remotewebaccess" certificate, I am not sure how that would come into play. Even though you have that, I believe the SSTP VPN is using the self signed/internal certificate.


    >>"Now the thing I'd like to do is get the server to route external Internet traffic through the VPN."
    >>"But the user absolutely has to be able to browse the regular Internet when connected to the VPN."
    These two statements conflict one another.
    To route VPN clients internet access through the VPN you check the box "use remote default gateway" which disables split-tunneling and forces all traffic through the VPN. If you want to lock that down, the connection manager article linked below will allow you to do so. 

    http://blog.lan-tech.ca/2012/01/30/windows-vpn-client-deployment/

     


    Rob Williams
    Tuesday, January 31, 2012 2:28 AM
  • >>"it did NOT start the service for me automatically."
    RRAS should automatically start and set the service to "Automatic (Delayed start)". If it doesn't start make sure it configured the later or it will fail after a reboot.

    It did properly configure it for Automatic startup. I even disabled it and reconfigured it again to be sure and it did the same thing (didn't start the service immediately after the config, but did set it for Auto startup). I had noticed when I was trying to configure it myself earlier before you posted that depending on what option you picked on that first screen (like the plain VPN option on the top vs. the VPN and NAT option in the middle) it sometimes started the service automatically and sometimes it prompted with a dialog box I had to click a button to start the service, but it did at least prompt. I don't remember which was which though. But when I went through this Custom option per your blog post, it just plain didn't start the service (didn't even prompt). Could be something in my earlier configuration attempts caused to not operate exactly as expected in this case, but I at least wanted to mention it in case anyone else reading this thread ran into the same thing.

     

    >>"Also, SSTP works just fine.......I didn't have to do anything special to configure it, it just works."
    I found this interesting as the certificate creation and distribution is the only lengthy part of setting up SSTP. Configuring RRAS and the client is basically automatic. Normally you have to enable the Certificate Authority Service, create and manipulate the certificate, deploy or set up web deployment for the certificate, and install the certificate on the client. In your case it may be that although SBSe doesn't use self signed certificates, it does create one, and when you run the connection wizard to join the domain it does import that certificate to the PC's trusted root certificate store. You may find your SSTP VPN will not work on non-domain joined PC's. If you have a 3rd party certificate you can make it work, but the process can 'break' parts of RWA, or at least TS Gateway on SBS std, until you tweak it. As for the Microsoft "remotewebaccess" certificate, I am not sure how that would come into play. Even though you have that, I believe the SSTP VPN is using the self signed/internal certificate.

    Well, in what I've worked with on SBS 2011E so far, I know that Remote Desktop through RWA won't work without a publically trusted certicfiate, unless you want to mess with exporting and importing the self-signed cert from the server, which I don't.  Getting the cert through Microsoft for the <whatever>.remotewebaccess.com URL makes it work without having to actually purchase a cert from a 3rd party provider.  I'm not sure, but I THINK it's using the same cert for the SSTP VPN because I CAN connect to the server over SSTP from another non-domain joined PC (I just tried from one of my personal normal Win 7 PC's at home) and it connects just fine over SSTP.  (Though yes, related to that other question about netbios name resolution, I can't resolve the server name because this PC is not a member of the domain, but I CAN resolve the server name from this PC if I use the FQDN of the server's internal .local domain.)  If it was using the internal self-signed cert, I would think that a non-domain joined PC would not be able to connect to the VPN over SSTP since it wouldn't trust the certificate (unless I went through the trouble again of exporting/importing that cert to the client PC, which I did not do).

    In any case, again, I'm guessing this is a side effect and benefit of SBS 2011 E having already set up the certificate as part of enabling the Remote Web Access.  On a normal Server 2008 server you'd obviously have to set up the certificate yourself.

    I only mention it for the benefit of anyone else reading this thread that if they want to use SSTP, and have configured Remote Web Access already (or do it if they haven't yet), to just give SSTP a try and they might get lucky like I did and it'll just work.

     


    >>"Now the thing I'd like to do is get the server to route external Internet traffic through the VPN."
    >>"But the user absolutely has to be able to browse the regular Internet when connected to the VPN."
    These two statements conflict one another.
    To route VPN clients internet access through the VPN you check the box "use remote default gateway" which disables split-tunneling and forces all traffic through the VPN. If you want to lock that down, the connection manager article linked below will allow you to do so. 

    http://blog.lan-tech.ca/2012/01/30/windows-vpn-client-deployment/

    Slight misunderstanding here.  The statements don't contradict.  What I meant was that the user must have the physical CAPABILITY to browse the normal Internet while connected to the VPN.  I can't force them to have to disconnect the VPN every time they need to browse an external web site.  HOW that's accomplished is the question.  Yes, that's what I meant in my previous post, ONE way to accomplish that is UNchecking the "use remote default gateway" box on the client side to allow split tunneling.  I prefer NOT to do that (although I will if I can't figure anything else out) and prefer have all Internet traffic routed through the VPN through the server.  Right now, when connected to the VPN with the "use remote default gateway" box checked, I am unable to browse the external Internet at all.  The SERVER is not routing the Internet traffic back out through it's own Internet connection.  I need to know what to do on the SERVER to get it to route that Internet traffic from the VPN client back out to the Internet through it's own connection.  (And yes, I know there can be a performance hit on the Internet browsing but I think there's fast enough Internet connections on both the client and the server in the office that it won't be an issue so I'd rather have the security.)
    • Edited by clh42 Tuesday, January 31, 2012 4:13 PM
    Tuesday, January 31, 2012 3:25 PM
  • Hi clh42.

    Sorry I have been so slow to respond.

    As for accessing internet, you can enable split tunneling as discussed or if the "use default remote gateway" option is checked you 'should' be able to access through the remote network.  If it is not working make sure in RRAS "LAN routing is enabled", but I suspect it may be more a DNS issue. Try connecting to a web site using the IP  such as Google  http://74.125.226.52   If that works we can address DNS, if it doesn't try tracert to a public IP and see where it hangs, such as   tracert  74.125.226.42.  There are also possible issue with "Hair-pinning" coming into play here with a single NIC, but I just tested on SBS std with a single NIC and it worked fine.


    Rob Williams

    Friday, February 17, 2012 5:27 PM
  • Thanks much for the suggestions.  You caught me just as I'm going on vacation for a week, but I will check this stuff once I'm back.  Thanks again!
    Friday, February 17, 2012 6:36 PM
  • Rob (or anyone else), I finally had a chance to check your suggestions about why I'm not able to browse the web through the SBS server's VPN connection without enabling split tunneling.  Still not working but here's what I've found.

    DNS IS working.  At a command prompt, I can ping and tracert by the DNS name of a web site just fine. (tracert www.google.com)

    Basic ping and tracert traffic DOES go through.  I get a response from pings, and a tracert does go all the way through to the destination server.

    But in Internet Explorer, when I try to go to a web site either by DNS name or by IP address, it just tries for a long time and eventually times out.  So the IP address doesn't work here either.

    So any other ideas of what I should check on the SBS server?

    EDIT: Actually, just after I typed the above I tried something again.  Actually, Google and most other web sites DO come up in IE, it just take a while (not unexpected over the VPN connection), but at least one other web site will not ping or tracert either, and thus of course does not work in IE either.  It DOES resolve the DNS name to the IP address.  The odd thing is that the tracert gets THROUGH the server, through the local ISP, and dies at the remote web site's end.  BUT, if I enable split tunneling on the VPN connection on the workstation, that same web site works just fine.  (And of course that web site works fine when not connected to the VPN at all.)

    • Edited by clh42 Monday, March 19, 2012 3:24 PM
    Monday, March 19, 2012 3:13 PM
  • >>"The odd thing is that the tracert gets THROUGH the server, through the local ISP, and dies at the remote web site's end. "

    Not all devices/sites wil respond to tracert, even if they respond to pings

    >>"if I enable split tunneling on the VPN connection on the workstation, that same web site works just fine.  (And of course that web site works fine when not connected to the VPN at all.)"

    Same thing. Split tunneling allows you to use the local Internet connection.

    To confirm; browsing websites through the VPN/corporate site works for most sites, but not all?  If so can you give the URL's of a couple of sites that do not wor to try to troubleshoot?


    Rob Williams

    Monday, March 19, 2012 6:08 PM
  • Yeah, I know some sites are configured not to respond to pings or tracert for security, and I'm pretty sure the web site I was talking about is one that is purposely configured so.  What I was really trying to say there was primarily that it was NOT dying at my server, it was getting through my server, so my server wasn't the issue as far as traffic getting through the routing there in general.

    After yet more testing, I think this is more of a latency and timeout issue, and NOT tied to any specific site.

    99% of the time I can not get any web site to come up in IE, it will sit for a minute or two and then finally time out.  But once in a GREAT while, a site will actually come up, after a minute or so delay after I type the address in the address bar.  (And the same thing happens when I try the IP address.)  It's not specific to any particular site though.

    So it appears that the routing of the web traffic through the server takes so long that IE just eventually times out.  Is there anything I can do on the server config to "speed up" the routing through the VPN?

    Tuesday, March 20, 2012 1:20 PM
  • No the routing on the server is pretty much instantaneous.

    What do you get for ping response times when pining the server itself, and a remote web site via the VPN?


    Rob Williams

    Tuesday, March 20, 2012 1:27 PM
  • I didn't try pinging the server itself so I don't know on that (I can try but it'll be a little bit before I can get to it), but ping responses from remote web sites through the VPN were anywhere from 200 to 400 ms.
    Tuesday, March 20, 2012 1:32 PM
  • Though 200-300 MS should load  a web page, that is pretty slow.  if client to server exceeds 125MS, you can have issues maintaining a VPN connection.

    If testing try pinging server, the router at the server site, the ISP's gateway address at the server site, and a web site, just to try to locate the latency



    Rob Williams

    Tuesday, March 20, 2012 1:39 PM
  • Now I'm not so sure again what's going on.  Had a chance to ping the server directly, but also now I'm seeing much better ping times overall than last night.  Though I know ping times can vary depending on time of day (traffic in general at any particular time of day) or the different internet connection my client PC is attached to.

    So the high ping times were last night at home on my cable modem.

    Testing today from another DSL connection we have here at work, I'm seeing much better ping times.  Only about 60 to 65 ms total.  Testing with Google, pinging the server directly is pretty consistently 3 ms.  Pining the router that the server is connected to for its internet connection is consistently 4 ms.  Pinging the first hop on the ISP's network after my router is about 50 to 55 ms.  Then all the way to Google is about 60 to 65 ms.  So there seems to be a definite delay between my router and the ISP.  BUT, to compare I did pings directly from the server itself and I see the same thing.  From the server itself I see about just slighly less (still about 55 to 64 ms) ping times, basically only losing the 3 ms from the client to the server.  And the web browsing works on the server, but still won't on the client.

    I was wondering if maybe something on the buit-in Windows firewall on the SBS Essentials server hampering the routing of the web traffic?  But that wouldn't explain why SOMETIMES (however rarely) it does work.

    Tuesday, March 20, 2012 2:53 PM
  • Agreed, if it works even very rarely it extremly unlikly that it would be related to routing or firewalls.

    Is it possible to test another protocol like RDP or FTP, instead of Http?


    Rob Williams

    Monday, March 26, 2012 2:44 PM
  • I will give RDP and/or FTP a try as soon as I can.  I'm just today though heading out on a business trip so it'll be a week or two before I can try it.
    Monday, March 26, 2012 2:53 PM