Figure 1
After creating the connection, you can right-click the VPN connection in the Network Connections window and click Status . In the Status dialog box, click the Details tab, where you will see the details of the PPTP connection. You can see the WAN Miniport (PPTP) protocol used, the authentication method and the IP address information, as shown in Figure 2.
In the TMG firewall console, the Dashboard directive, you can see the connection in Sessions as shown in Figure 3 below.
When switching to the Monitoring button in the left pane of the TMG firewall console and clicking the Sessions tab, you will see the VPN client connection. If the VPN server is remotely busy, you can use the filtering feature included in the Sessions tab and configure the filter to show only remote access VPN client connections. Note that this button also provides information related to the VPN protocol used to connect the TMG firewall's remote access VPN server as well as the username of the connected user. See the figure shown in Figure 4 below.
Easy? Now you know why administrators like to configure ISA and TMG as PPTP remote access VPN servers. You can be attracted and enable EAP / TLS authentication, use RADIUS server and do some things to extend PPTP VPN server security and configure access control - but if you Just want an easy and fast solution, PPTP is what you need to choose (at least from the configuration server).
However, all you have done so far is configure the TMG firewall to become a remote access VPN server and verify that the PPTP connection can be established. What we haven't done is connect to the resources on the intranet to make sure that the connection really works.
An easy way to test this is to see if we can ping a domain controller on the internal network. The IP address of the domain controller is 10.0.0.2 . Figure 5 below shows the result of the ping action.
What's up with that? TMG firewall requires many VPN connections. Remember, when setting up the TMG firewall, by default, no traffic can move through the firewall. You need to create rules that allow traffic to pass through the firewall.
OK, let's create those rules.
On the left pane of the TMG firewall console, click the Firewall Policy button. In the right pane of the console, click the Tasks tab. In the Tasks tab, click the Create Access Rule link , as shown in Figure 6.
In the Welcome to the New Access Rule Wizard dialog box, shown in Figure 7, enter the name of the rule in the Access Rule name text box. In this example, we have named the rule VPN Clients to Internal and then click Next .
In the Rule Action page, shown in Figure 8, select the Allow option, since we want to use this rule to allow traffic from the VPN client network to the internal network by default. Click Next .
On the Protocols page, shown in Figure 9, you can choose which protocols are allowed from the source network to the destination network (or computer or other network object). In this example, we allow all traffic from the VPN client network to the internal network, so select the All outbound traffic option from the This rule applies to drop down list . Click Next .
On the Malware Inspection page, shown in Figure 10, we will select the option Do not enable malware inspection for this rule . The reason we choose this option is for convenience in this example. Note that in a production environment, you need to protect clients from malware, because of split tunneling (the process of allowing remote VPN users to access the Internet when allowed to access resources on the VPN, this method gives allowing users to access remote devices such as printers in the network, while still able to access the Internet) is disabled by default. Because split tunneling is disabled, VPN clients will have to access the Internet through the resources you create on the corporate network. That resource could be another TMG firewall or web proxy, or it could be the TMG firewall that the VPN client is connecting to to set up a remote access VPN client session.
See page 2
In this example, we will not go into creating rules that allow Internet access when connecting to VPN - your policies will determine if you want to allow Internet access while the VPN client is connected. no and want to allow split tunneling when the VPN client is connected to the TMG remote access VPN server.
On the Access Rule Source page, click the Add button and click the Networks button. Then double-click the VPN Clients Network and click Close in the Add Network Entities dialog box, as shown in Figure 11. Click Next .
On the Access Rule Destination page, click the Add button. In the Add Network Entities dialog box shown in Figure 12, click the Networks button, and then double-click Internal Network. Click Close in the Add Network Entities dialog box. Click Next .
On the User Sets page, shown in Figure 13, use the default entry, All Users . Note that in a production environment, you can restrict which users connect through this rule, or create other rules to apply to remote access VPN clients. Be aware that, when a computer connects via a remote access VPN connection, the TMG firewall will have the user context of the session. That's a good thing - because VPN clients are the same as Firewall Clients (TMG Clients) where the user context is available for connections created through the TMG firewall and allows you to create user-based rules. or a group of users to allow VPN clients to connect to resources behind the TMG firewall.
Click Next .
On the Completing page of the New Access Rule Wizard , shown in Figure 14, click Finish .
In the middle pane of the TMG firewall console, you will see a new rule appear. Click the Apply button, see Figure 15, to save the changes to the firewall policy.
Now let's test the configuration, using the ping command to the domain controller on the corporate network. And the result is what you see in Figure 16 below, it worked because the rule allowed the connection.
What else do we have to do? Since we have enabled all traffic, we can connect to SMB shares or at least see a list of them on the domain controller. All you see is as shown in Figure 17.
So far everything we have done is good. Next, let's look at the TMG filewall log files, shown in Figure 18, and find out what happens here. You can see details about the ping process that the VPN Clients to Internal rule is allowed to ping the destination 10.0.0.2 . What is most interesting is that there is a user context, which is not what you expect from non-firewall clients. However, as we mentioned earlier, when users connect as a remote access VPN client, you will have user information through the firewall and this information can be used in firewall rules. Note that when user information is received when done with the Firewall (TMG) client, we will not have support for complex protocols as we do with the Firewall (TMG) client.
Figure 18
Conclude
In the second part of this article series, I have shown you a simple PPTP remote access VPN connection. We have configured the PPTP VPN server and then created an Access Rule to allow the connection between the VPN client and the resources on the default internal network. However, PPTP is just the beginning, we think we will start with a few simple things and move on to more complex configurations, so in the next part of this series we will figure out how to develop. declare L2TP / IPsec VPN server.
This deployment is a little more complicated because we need to deploy certificates for both VPN clients (CA certificates) and TMG firewall (server certificates). This process requires dexterity because the admissions site utility has changed for Windows Server 2008 R2, which means we won't be able to use that tool to get website certificates easily. easy. In addition, there is a problem with RPC filter and this problem makes using MMC certificates more difficult. Even so we will introduce you to the right solutions to solve those problems in the next section.