Welcome back to our Test Lab Guide series. Last time, we configured the TMG Core Lab. Now we can start having fun with it and you can find out how you can use the Test Lab Guides to learn about TMG firewall features and functionality. In part 1 of this latest Test Lab Guide article, you will learn how to configure the TMG firewall as a remote access VPN server that supports PPTP, L2TP/IPsec and SSTP.
The first step is to restore your TMG Core Lab snapshot. If you haven’t completed the TMG Core Lab yet, then check it out over at here.
Once you’ve restored the snapshot, log into TMG1 as CORP\User1. Then open the TMG firewall console. In the TMG firewall console, click the Remote Access Policy (VPN) node in the left pane of the firewall console as shown in Figure 1.
In Tasks Tab in the Task Pane, click the Enable VPN Client Access link, as seen in Figure 2 below.
Next you’ll see an error message with an ominous red “X” as shown in Figure 3. Ouch! What happened? Apparently you have to define how you want to assign IP addressing information to the VPN clients before you can enable the VPN configuration. Actually, if you know how the ISA VPN server worked, this wouldn’t be unexpected –we saw the same thing with the ISA firewall. Tom and I always considered this a bug, but some folks consider it a feature. It’s all in the eye of the beholder.
It’s hard to say who’s at fault here. Did I do something wrong, or was this coded badly? If you look in the middle pane of the TMG firewall console, you’ll see that Step 1 is to Configure Address Assignment Method and Enable VPN Client Access. Okay, maybe it’s because I went rogue and headed to the Tasks Tab first, instead of reading the instructions in the middle pane. I’m feeling properly chastised and ready to toe the line now, at least for a little while.
Click the Configure Address Assignment Method link in the middle pane of the TMG firewall console, as seen in Figure 4 below.
This opens the Remote Access Policy (VPN) Properties dialog box and lands you on the Address Assignmenttab. Here you have two options:
- Static address pool. If you select this option, you can configure a static address pool for IP addresses you want to be assigned to the VPN clients. You can assign on-subnet or off-subnet addresses. If you assign on-subnet addresses, they will likely be part of the current definition of the default Internal Network. If that’s the case, you will need to remove the on-subnet addresses you want to be in your static address pool from the list of the addresses included in the default Internal Network. If you use off-subnet addresses, then make sure your routing infrastructure knows the path to the off-subnet ID hosted on the TMG firewall VPN server.
- Dynamic Host Configuration Protocol. If you select this option, a DHCP server on the Internal Network that is accessible from the TMG firewall’s internal interface can be used to assign IP addresses to the VPN clients. If you use on-subnet addresses, you do not need to remove them from the default Internal Network or any other TMG Firewall Network definition, because the firewall will do this automatically and dynamically add the addresses to theVPN Clients Network.
In the bottom section of the dialog box, which is shown in Figure 5, notice the drop down box under Use the following network to obtain DHCP, DNS and WINS services. The DHCP and WINS server configured on the NIC you select here will be used to assign similar DNS and WINS server addresses to the VPN clients.
For the purposes of this Test Lab Guide, select the Dynamic Host Configuration Protocol (DCHP) option. From theUse the following network to obtain DHCP, DNS and WINS services drop down box, make sure you selectInternal. Click Apply and then click OK.
In the middle pane of the TMG firewall console, click the Enable VPN Client Access link in the middle pane, as seen inFigure 6 below.
After you click the Enable VPN Client Access link in the middle pane of the TMG firewall console, note in the Tasks Tab of the Task Pane that the option changes to Disable VPN Client Access, as seen in Figure 7 below.
In the Tasks Tab in the Task Pane, click the Configure VPN Client Access link. This brings up the VPN Clients Properties dialog box. On the General tab, confirm that there is a checkmark in the Enable VPN client accesscheckbox and then change the value in the Maximum number of VPN clients allowed text box to 10, as seen in Figure 8 below.
Click the Groups tab. Note that user accounts that belong to the domains you select here should have VPN access, as configured in the accounts’ dial-in options, set to Control access through remote access policy. If that option isn’t available (for example, with Windows 2000 functional level domains), then select the Allow Access option in the dial-in properties of the account. We’ll see those account settings in the Active Directory Users and Computers console shortly.
For this Test Lab Guide, click the Add button. This brings up the Select Groups dialog box. In the Select Groupsdialog box, click the Locations button and select corp.contoso.com. In the Enter the object names to select (examples) test box, enter Domain Users. Click Check Names and confirm that Domain Users gets underlined. Click OK in the Select Groups dialog box, which you can see in Figure 9.
You should now see Domain Users in the Select the domain groups for which remote access is allowed list that’s shown in Figure 10.
Move to DC1 and log on as CORP\Administrator. Open the Active Directory Users and Computers console from the Administrative Tools menu in the Start menu. In the left pane of the console, click the Users node. In the right pane of the console, double click User1. In the User1 dialog box, click the Dial-in tab that’s shown in Figure 11. Notice that the default setting is Control access through the NPS Network Policyin the Test Lab. This confirms that the settings we configured on the Groups tab seen in the figure above will work as expected.
Click on the Protocols tab. Here you select the protocols you want the TMG VPN server to support. Put a checkmark in the Enable PPTP, Enable L2TP/IPsec and Enable SSTP checkboxes, as seen in Figure 12 below. Click on theSelect Listener button that sits to the right of the Enable SSTP option so that we can configure a Web listener to support incoming SSTP connections.
This brings up the Choose Web Listener for SSTP dialog box that’s shown in Figure 13. There are no Web Listeners available yet for SSTP, so we need to create one. Click the New button.
This in turn brings up the Welcome to the New Web Listener Wizard page, which you can see in Figure 14. EnterSSTP Listener in the Web listener name text box and click Next.
On the Web Listener IP Addresses page, shown in Figure 15, select External by putting a checkmark in the checkbox next to it. This means that the VPN server will accept incoming VPN client connections using SSTP on the External Network interface. Notice that you have the option to enable incoming SSTP connections on other interfaces. This is especially useful if you want to create multiple DMZ networks. For example, you might create a guest network, but then want to VPN into the internal network from the Guest Network (that’s only one scenario, but there are many different scenarios in which you might want to allow VPN client connections to interfaces other than the default External Interface).
After putting a checkmark in the External checkbox, click the Select IP Addresses button. This will bring up theExternal Network Listener IP Selection dialog box. Select the Specified IP addresses on the Forefront TMG firewall in the selected network option. We need to do this because the SSTP listener can only listen on a single IP address. That’s because we bind the SSL certificate to that address and map this address to the name on the certificate in the public DNS (we’ll do this later in this Test Lab Guide).
In the Available IP Addresses section, click 220.127.116.11 and then click the Add button. This moves the IP address to the Selected IP Addresses list, as seen in Figure 15 below. Click OK in the External Network Listener IP Selection dialog box.
Confirm that 18.104.22.168 appears next to External in the Web Listener IP Addresses page that’s shown in Figure 16, and then click Next.
On the Listener SSL Certificates page, select the Use a single certificate for this Web Listener, as seen in Figure 17 below, and then click the Select Certificate button.
In the Select Certificate dialog box, notice that we already have a certificate with the common nameEDGE1.corp.contoso.com, which was assigned to this computer when it joined the domain during the Base Configuration Test Lab. We can use this computer certificate, since the certificate contains the intended purpose of “server authentication”. In a production environment, you will probably want to request another certificate to use exclusively for the SSTP connection. Just make sure that the certificate includes the OID for “server authentication” and you’ll be able to use it for your SSTP certificate.
For this Test Lab Guide, select EDGE1.corp.contoso.com from the list on top and then click theSelect button shown at the bottom of the dialog box in Figure 18.
On the Listener SSL Certificates page that you see in Figure 19, notice that EDGE1.corp.contoso.comnow appears. Click Next.
Review the settings on the Completing the New Web Listener Wizard page shown in Figure 20, and if they are all as you wish, click Finish.
In the Choose Web Listener for SSTP dialog box, shown in Figure 21, you can see the settings for the SSTP Listener you created. This will be used to accept incoming SSTP VPN client connections. Click OK.
Now click the User Mapping tab that’s shown in Figure 22. Be aware that you would use this tab and the settings here if you were using RADIUS or EAP authentication. We’re not going to use either of those in this Test Lab Guide because we’re taking advantage of native Windows authentication. Do not make any changes on this tab.
Click on the Quarantine tab that you see in Figure 23. Here you can configure settings that will enable VPN quarantine. We will not enable VPN quarantine in this Test Lab Guide, but we will do this in the future and when we do, we’ll base it on the Test Lab Guide. Do not make any changes on this tab.
Click Apply and then click OK. Notice that you receive a warning that you might need to restart some of the services, as shown in Figure 24. An alert will be triggered for each computer in the array where the services need to be restarted. In this Test Lab Guide, there is no reason for us to manually restart any services so we’ll just click OK to dismiss this dialog box.
In this, part 1 of the TMG VPN server Test Lab Guide, we went through some of the configuration steps that are required to get the TMG VPN server working. Note that the configuration is not done yet! There will be two more parts to this Test Lab Guide, so don’t get started yet on putting together your TMG Test Lab. In the next part of this series on the TMG VPN server Test Lab Guide, we’ll continue configuring the VPN server and then we’ll configure INET to host the corp.contoso.com domain so that CLIENT1 can reach the SSTP and L2TP/IPsec listeners. See you then! –Deb .
Thanks for sharing this such a great information.I really appreciate your work i share this link to my facebook friend as well as Digg and twitter this info helps to everyoneAntwortenLöschen
Nice post. Thanks for sharing.AntwortenLöschen
Scratching my head a bit here. I set up a file server for a client yesterday with Server 2012 behind a BT Business Hub 5. All ports are forwarded on the BT hub for PPTP, L2TP and SSTP, and all are clear on the Server 2012 firewall and has been verified with netstat. My machine or location are not at fault as I can connect to every other VPN client in australia I have set up. If I go in the Remote Access Management Console I can see "1" client showing when I try to connect which disappears when my connection fails. I used a network monitor and captured the traffic which confirms that my public IP is making a request that gets through to the Server 2012 system but then it just closes.AntwortenLöschen
Tried various users and my Admin account, all of which have remote access authorised, but no dice?
Can anybody spare a minute to help troubleshoot this with me?
It is truly a well-researched content and excellent wording. I got so engaged in this material that I couldn’t wait reading. I am impressed with your work and skill. Thanks. Best Free Trial VPN Services CanadaAntwortenLöschen