Test Lab Guide (Part 4) – Demonstrate TMG PPTP, L2TP/IPsec and SSTP Remote Access VPN Server (Cont.)

If you would like to read the other parts of this article series please go to:

Introdcution

In the previous article (part 3) of this series, we completed the configuration of the TMG firewall’s VPN server component. In this article, Part 4, we’ll complete the configuration by setting up the Windows 7 VPN client and we’ll also configure the public DNS server on INET1 in this lab, so that name resolution will work correctly in light of the particular setup for the PKI that we have in the Test Lab. Let’s get started!

Configure the VPN Client

Log on to CLIENT1 as CORP\User1. Make sure that CLIENT1 is connected to the Corpnet subnet. Click the Start button and in the Search box, enter network. In the Control Panel list, click the Set up a connection or network link, as seen in Figure 1 below.


Figure 1

On the Choose a connection option  page, click the Connect to a workplace, as seen in Figure 2 below, and then click Next.


Figure 2

On the How do you want to connect page, select the Use my Internet connection (VPN) option, as seen in Figure 3 below.


Figure 3

On the Do you want to set up an Internet connection before continuing page, select the I’ll set up an Internet connection later option, as seen in Figure 4 below.


Figure 4

On the Type the Internet address to connect to page, shown in Figure 5, enter EDGE1.corp.contoso.comm in the Internet address text box. In the Destination name text box, enter VPN to Corpnet. It’s important to note here that the name you enter in the Internet address text box needs to match the common or subject name of the certificate that is being used by the TMG firewall’s VPN server. In this Test Lab example, that is the case, so we know that we have the correct entry in that box.

Click Next.


Figure 5

On the Type your user name and password page, which is shown in Figure 6, enter User1 in the User name text box. Enter [email protected] in the Password text box. Enter CORP in the Domain (optional) text box. Click Create.


Figure 6

On the The connection is ready to use page, shown in Figure 7, click Close.


Figure 7

Click the Start button and enter network connections in the Search box. In the Control Panel section, shown in Figure 8, click View network connections.


Figure 8

In the Network Connections window that’s shown in Figure 9, right click the VPN to Corpnet entry and then click Properties.


Figure 9

In the VPN to Corpnet Properties dialog box that you see in Figure 10, click the Security tab. On the Security tab, click the Advanced settings button. In the Advanced Properties dialog box, on the L2TP tab, select the Use preshared key for authentication option. This option will allow you to connect CLIENT1 to the TMG firewall’s VPN server without requiring certificate deployment.

Note that in the Test Lab Base Configuration, you have already deployed certificates to the TMG firewall (EDGE1) and all the other systems, including CLIENT1. We could have bypassed this step and the L2TP/IPsec connection would have worked with no problem. However, I wanted to show you where this configuration is located, in case you wanted to use pre-shared keys for a while before you get around to deploying certificates.

Click OK in the Advanced Properties dialog box.


Figure 10

Click OK in the VPN to Corpnet Properties dialog box that’s shown in Figure 11.


Figure 11

Create the Split DNS Zone on INET1

One issue we have with the Test Lab is related to the names on the certificates. In a production environment, you would request a certificate that is dedicated to the VPN server function on the TMG firewall. You would not use the computer certificate assigned to the TMG firewall as part of the autoenrollment process. However, in order to keep things relatively simple, we didn’t go through the process of requesting the custom certificate designed only for VPN server use. Instead, the TMG firewall’s VPN server is using the computer certificate that was assigned via enrollment. The subject/common name on this certificate is the FQDN of the machine on the internal network. This isn’t something you would do in a production environment because you don’t want external users to have access to your internal machine names.

Since we’re not going to request a new certificate to be used for the VPN function on the TMG firewall, we need to deal with name resolution issues that the current situation introduces. The common/subject name on the certificate is EDGE1.corp.contoso.com, which is the FQDN of EDGE1 on the intranet. INET1 doesn’t have a zone for corp.contoso.com, so the VPN client won’t be able to resolve the name on the certificate to an IP address on the external interface of the TMG firewall. Since this is required, we need to update the DNS server on INET1 and create a split DNS configuration. This is a split DNS because we will host the same domain name on both an internal and an external DNS server, but the same name on the external DNS server resolves to a different IP address than the name would on the internal DNS server.

Okay, here’s how to do it: Go to INET1 and open the DNSManager console. In the left pane of the console, right click Forward Lookup Zones. Then click New Zone, as shown in Figure 12.


Figure 12

On the Welcome to the New Zone Wizard page, shown in Figure 13, click Next.


Figure 13

On the Zone Type page, shown in Figure 14, select the Primary zone option and then click Next.


Figure 14

On the Zone Name page, shown in Figure 15, enter corp.contoso.com in the Zone name text box. Click Next.


Figure 15

On the Zone File page, shown in Figure 16, confirm that Create a new file with this file name is selected and click Next.


Figure 16

On the Dynamic Update page, shown in Figure 17, confirm that Do not allow dynamic updates is selected and then click Next.


Figure 17

On the Completing the New Zone Wizard page, shown in Figure 18, click Finish.


Figure 18

Ah, but you’re not done yet. Now click on the corp.contoso.com entry in the left pane in the console, which you can see in Figure 19. In the right pane of the console, right click in an empty area and selectNew Host (A or AAAA).


Figure 19

In the New Host dialog box, which is shown in Figure 20, enter edge1 in the Name text box. In the IP address text box, enter 131.107.0.2 and then click Add Host.


Figure 20

A dialog box tells you that the record was created, as you can see in Figure 21. Click OK.


Figure 21

Click Done to dismiss the New Host dialog box.

You can now see the new record for edge1 in the right pane of the DNS console, as shown in Figure 22. When CLIENT1 is moved to the Internet subnet, it will be resolve the name edge1.corp.contoso.com to the IP address on the external interface of EDGE1.


Figure 22

Test the VPN Client Connections

That’s it! Now we’re ready to test the VPN connections and see if they work. First, move CLIENT1 to the Internet subnet. The procedure will vary, depending on whether you’re using VMware or Hyper-V, but make sure to move CLIENT1 to the Internet subnet now.

On CLIENT1, click Start and then enter Network Connections in the Search box. In the Control Panel section, click View network connections, as shown in Figure 23.


Figure 23

In the Network Connections window, double click on VPN to Corpnet, as shown in Figure 24. In the Connect VPN to Corpnet dialog box, enter User1 and the password for User1. (Remember that you assigned a password to User1 when you created the Base Configuration).

Click Connect.


Figure 24

You should now see the Connecting to VPN to Corpnet dialog box that’s shown in Figure 25. Here you will see it work through several VPN protocols until it finds one supported by both the client and server.


Figure 25

After the connection is established, right click on VPN to Corpnet and click Status, as shown in Figure 26.


Figure 26

In the VPN to Corpnet Status dialog box that’s shown in Figure 27, you’ll see that a PPTP connection was established.


Figure 27

Right click VPN to Corpnet and click Disconnect, in the menu that’s shown in Figure 28, to disconnect the VPN connection.


Figure 28

Now right click VPN to Corpnet again and click Properties. In the VPN to Corpnet Properties dialog box, click the Security tab. On the Security tab, which is shown in Figure 29, click the down arrow from the Type of VPN drop down box. Select Layer 2 Tunneling Protocols with IPsec (L2TP/IPsec).


Figure 29

Click OK in the VPN to Corpnet Properties dialog box that’s shown in Figure 30.


Figure 30

Double click on VPN to Corpnet. Enter User1 for User name and User1’s password and click Connect as shown in Figure 31.


Figure 31

Right click on VPN to Corpnet after the connection is established and click Status. In this case, you can see in Figure 32 that the VPN protocol is L2TP and is using IPsec: AES 128 encryption. Click Close to close the dialog box.


Figure 32

Right click on VPN to Corpnet and click Disconnect, as shown in Figure 33.


Figure 33

Open the VPN to Corpnet Properties dialog box as you have in previous steps and then click the Security tab again. In the Type of VPN drop down box, select Secure Socket Tunneling Protocol (SSTP)as shown in Figure 34, and then click OK.


Figure 34

Log on to the VPN as User1, as you have in previous steps and as is shown in Figure 35.


Figure 35

Oops! What happened? You got an error message. As you can see in Figure 36, the error states 0x80092013: The revocation function was unable to check revocation because the revocation server was offline.

What’s up with that?


Figure 36

Looks as if we have more work to do.

Repairing the SSTP Configuration

The problem with SSTP is right now is that the CRL check failed because the VPN client can’t reach the CRL Distribution Point (CDP). There are at least three ways you can fix this:

  • Publish your internal CDP
  • Use a commercial certificate for the VPN connection (in that case, the commercial certificate publisher will make sure that the CDP is available to your VPN clients)
  • Configure the Registry on the SSTP client so that it won’t perform a CRL check

The first option is certainly doable but it means that you’ll need to configure your internal certificate server with a publicly accessible address to be assigned to the CDP section of the certificates so that external users can create the internal certificate server. The second option is the easiest, and is the most common option in a production environment.

For the test lab, the more simple (and cost effective) option is to configure the Registry on CLIENT1. To disable CRL checking, create a registry setting at the following location:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Sstpsvc\parameters

The setting must be a DWORD value named NoCertRevocationCheck. Set the value to 1.

Make the change on CLIENT1 and establish the SSTP connection. Now it should succeed and you’ll see that SSTP is the protocol used when you check the Status of the connection.

Snapshot the Configuration

The last step of this Test Lab Guide (and all TLGs) is for you to snapshot the configuration. This will allow you to come back to your working TLG configuration and start playing with other things you might want to do with the working TMG VPN server. Close all the consoles and open windows and gracefully shut down all machines. Then snapshot all of the machines and name the snapshots TMG VPN Server TLG. We might want to restore this TLG in the future and build upon it, so save that snapshot!

Summary

In this four part series, we completed the TMG VPN server Test Lab Guide. We configured the server and the clients to support PPTP, L2TP/IPsec and SSTP. After making a small change in the public DNS, we established connections to the TMG VPN server and observed which VPN protocol was used. That’s it! I hope you enjoyed this TLG.  Please let me know if you’d like to see TLGs for other subjects. If you want to try out TLGs for other topics, make sure to check the TechNet wiki here.

If you would like to read the other parts of this article series please go to:

Leave a Comment

Your email address will not be published.

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top