Published on February 3, 2009 by · No comments

If you missed the previous parts of this article series, please read:

The first two parts of this series of articles are about how to create an SSL VPN server based on Windows Server 2008, we looked at some of the basics of building VPN networks and then discussed setting up a server. On at this stage We are ready to complete some minor changes to the Active Directory configuration and the CA website. Once we've made these changes, we'll focus on the VPN client configuration and finally create the SSL VPN connection.

Configuring a user account to use Dial-up connections

User accounts require dial-up access permissions before they can connect to Windows server VPN that is part of an Active Directory domain. Most The best way to do this is to use the Network Policy Server (NPS) and also permission account default user that allows remote access based on NPS policy. However, in our case, we did not install an NPS server, so we will have to configure the user's dial-in access permission manually.

In the next article I will focus on using the NPS server and EAP User Certificate authentication to create connections with an SSL VPN server.

In order to allow a specific user account dial-in access to connect to the SSL VPN server, you need to run next steps. In this example, we will enable dial-in access permission for the default domain administrator account:

Configuring IIS on the Certificate Server to allow HTTP connections for the CRL Directory

For some reason, when the installation wizard installs the Certificate Services website, it configures the CRL directory to request an SSL connection. While this seems like a pretty good idea from a security perspective, the problem is that the Uniform Resource Identifier (URI) on the certificate is not configured to use SSL. I'm guessing you could create a CDP record for the certificate yourself so it can use SSL, but I'd bet that Microsoft company I didn't mention this problem anywhere. Since we are using the standard settings for CDP in this article, we need to disable the SSL requirement on the CA website for the directory CRL path.

To disable the SSL requirement for a CRL directory, follow these steps:

Setting up a HOSTS file for a VPN client

Now we can give our full attention to the VPN client. The first thing we need to do with the client is to configure HOSTS file, so that we can simulate the public DNS infrastructure. There are two names that we need to enter into the HOSTS file (the same needs to be done for the public DNS server that you will use in production networks). The first name is the name VPN servers, as determined by the common/subject name of the certificate we have bound to the SSL VPN server. The second name we need to enter into the HOSTS file (and public DNS server) is the CDP URL name, which is on the certificate. We looked at the location of CDP information in Part 2 of this series.

The two names that need to be entered into the HOSTS file in this example would be:

192.168.1.73 sstp.msfirewall.org

192.168.1.73 win2008rc0-dc.msfirewall.org

To configure the HOSTS file for the Vista SP1 VPN client, follow these procedures:

1. Close the file and select the option save changes.

Using PPTP to connect to a VPN server

We are gradually getting closer to creating an SSL VPN connection! The next step is to create a VPN connector on the Vista SP1 client, which will allow us to create an initial VPN connection to the VPN server. In our case, this needs to be done because the client computer is not a member of the domain. Because the machine is not a member of a domain, the CA certificate will not be automatically installed in its Trusted Root Certificate Authorities store. If the machine were part of a domain, automatic registration would have taken care of this problem for us since we installed the Enterprise CA.

The easiest way to complete this step is to create a PPTP connection from the Vista SP1 VPN client to the Windows Server 2008 VPN server. By default, the VPN server will support PPTP connections, and the client will try PPTP first before trying L2TP/IPSec and SSTP. To do this, we need to create a VPN Connector or connection object.

To create a connector on the VPN client, follow these steps:

Obtaining a CA Certificate from an Enterprise CA

The SSL VPN client must trust the CA that issued the certificate used by the VPN server. To create this trust, we need to install a CA certificate on the CA that issued the certificate for the VPN server. We can do this by connecting to the CA registration website on the internal network and installing the VPN client's certificate into its Trusted Root Certification Authorities store.

To obtain a certificate from the registration site, follow these steps:

1. Click Close in the dialog box.
2. Closing Internet Explorer .

Now we need to install the CA certificate in the Trusted Root Certification Authorities Certificate Store of the VPN client machine. To do this you need to do the following:

1. Close the MMC console.

Configuring the client to use SSTP and connecting to the VPN server via SSTP

And now everything is almost ready! Now we need to disable the VPN connection and configure the VPN client to use SSTP for VPN protocol. In a production environment, you won't have to use this step for users because you will be using the Connection Manager package Administration Kit to create a VPN connection object for the user that will include a client using SSTP, or you will only configure SSTP ports on the VPN server.

It all depends on your environment configuration, as you need to schedule the time so that users can use PPTP for some time while you install the certificates. Of course, you can install CA certificates offline, that is, by downloading from a website or by e-mail, in which case you won't have to allow PPTP users. But then, if some clients don't support SSTP, you'll need to enable PPTP or L2TP/IPSec, and you won't be able to disable all non-SSTP ports. In such a case you will have to rely on manual setting or to the updated CMAK package.

Another option here would be to bind the SSTP client to a specific IP address on the RRAS server. In this case, you can create a custom CMAK packet that refers only to the IP address on the SSL VPN server listening to the network for incoming SSTP connections. Other addresses on the SSTP VPN server will listen to the network for PPTP and/or L2TP/IPSec connections.

Follow these steps to disable the PPTP session and configure the VPN client connection object to use SSTP:

Figure 29

Conclusion

In this final part of our series on how to put together an SSL VPN server using Windows Server 2008, we've finished setting up a user account, a website CRL, and an SSL VPN client. We also finished creating the SSTP connection and confirmed that it was successful. Thank you

Source www.windowsecurity.com

See also:

Readers Comments (No comments)

Exchange 2007

If you would like to read the previous parts of this article series, please follow the links: Monitoring Exchange 2007 Using System Manager...

Introduction In this multi-part article, I want to show you the process I recently used to migrate from an existing Exchange 2003 environment...

If you missed the first part of this series, please read it at Using the Exchange Server Remote Connectivity Analyzer Tool (Part...

| To the list of publications

Secure remote access via SSL VPN

Boris Borisenko, expert

TECHNOLOGY VPN has become widespread as a means of providing secure employee access to an enterprise’s local network from some physically remote point. SSL-based VPNs were developed as a complementary and alternative technology for remote access via IPsec VPN. However, the cost and reliability of organizing secure communication channels have made SSL VPN a very attractive technology. SSL VPN concentrators have additional capabilities (compared to traditional VPN devices). Most firewalls provide publishing of Web applications to the Internet through ports, broadcast network addresses(NAT) and network routing, but do not provide cryptographic data protection beyond the level provided by the applications. IPsec VPN users can establish a connection to the corporate network similar to a direct connection to a local network. This encrypts all data transmitted between the VPN server and the client. However, most VPN devices require a special client program. SSL VPN concentrators use the browser to allow remote workers to access not only internal Web sites, but also applications and file servers. Let's look at some of the most interesting solutions on organizing remote access using SSL VPN.

ZyWALL SSL 10

This is a virtual private network gateway with support for SSL encryption, which allows you to organize secure remote access to networks and applications via a VPN connection without first installing the client part. The device is offered for small and medium business networks.

To connect to the Internet or DMZ, there is a WAN interface, a switch with four LAN ports, an RS 232 DB9 port - for management via the console (in this device fewer features are provided than in the same ZyWALL 1050). ZyWALL SSL 10 supports not only direct access to intranet user databases, but also work with Microsoft Active Directory, LDAP and RADIUS. In addition, it is possible to use two-factor authentication(using ZyWALL OTP key fobs).

Direct access to corporate network resources is provided by the SecuExtender client, which is downloaded to the computers of remote users. After this, with the permission of administrators, certain categories of users can easily organize network tunnels using IPsec. Administrators can also configure security policies for user groups, network address ranges, or different applications.

ZyWALL SSL 10 supports 10 simultaneous secure sessions, expandable to 25 SSL sessions. In a network, the device can be used either behind an existing gateway (Figure 2) or as a new gateway (Figure 3). In the first case, ZyWALL SSL 10 can be connected to the DMZ port to improve security. In the second - to the modem, and the Web server - to ZyWALL. Traffic from the Web server to the remote user passes through the VPN tunnel.

Supported options include TLS protocol, encryption, certificates - 256-bit AES, IDEA, RSA, hashing - MD5, SHA-1. Interesting feature is enough big choice attachments for power plugs (for any sockets and networks).

Netgear ProSafe SSL VPN Concentrator SSL312

The device allows you to simultaneously work with a corporate network of up to 25 remote clients. The connection is made using ActiveX components, which can be downloaded and installed directly from the device.

However, the client must have administrative access to the system to install the appropriate ActiveX components. In addition, your browser must be configured to allow the use of ActiveX components. You may also need to install Windows updates. Hardware includes two LAN ports and one serial port. When logging into the system, an authentication option is selected: user database, Windows NT domain, LDAP, Microsoft Active Directory, RADIUS (PAP, CHAP, MSCHAP, MSCHAPv2). When accessing through a remote server, the latter must be accessible and traffic routing must be configured to it.

If the amount of DRAM memory is the same for both the Netgear SSL312 and the ZyWALL SSL 10, then the Netgear flash memory is clearly inferior (16 versus 128 MB). The Net-gear SSL312 processor also loses to ZyWALL (200 versus 266 with a cryptographic accelerator). Unlike Netgear SSL312, ZyWALL supports version 2.0 of the SSL protocol.

There are two possible options for using the device. In the first case, only one of the two Netgear SSL312 Ethernet ports is used. The gateway must access Netgear SSL312 over HTTPS. Another use case uses both Netgear SSL312 Ethernet ports without SSL traffic going through the firewall. One Ethernet port of the device is assigned a public IP address, and the second is assigned a private IP address of the internal network. It should be noted that Netgear SSL312 does not perform NAT or firewall functions and does not replace them.

To work with network services on a remote local network, there are two options: a VPN tunnel, which is established between the user and the device, or port forwarding. Both methods have advantages and disadvantages. The VPN tunnel allows you to organize full communication with a remote local network, but at the same time does not allow you to make separate settings for each service. Port forwarding allows you to work only with TCP connections (UDP and other IP protocols are not supported); rules for each application are set separately.
Dynamic DNS Netgear does not support SSL312, which is also a disadvantage.

SSL VPN Juniper Networks Secure Access 700

A remote access solution using SSL VPN is also designed for small and medium-sized companies. The interface for both the user and administrator is organized in the form of a Web browser. There is no need to install a VPN client on the remote computer. There are two RJ-45 Ethernet ports and one serial port. Juniper SA 700 automatically checks the remote computer and, depending on the results of the installed software, assigns various access rights.

Capable of supporting no more than 25 concurrent users. Among authentication and authorization, the following options are possible: Microsoft Active Directory/Windows NT, LDAP, NIS, RADIUS, RSA, SAML, certificate server. The device provides access to file resources Windows/SMB, Unix/NFS, Web applications, including those using JavaScript, XML, Flash; requests via Telnet protocols and SSH. Access to corporate email is organized on the basis of regular mail client, which is configured to connect securely over SSL to the Juniper SA 700. However, this will require a "Core Clientless Web Access" license.

Juniper SA 700 provides automatic verification remote computer, if anti-virus software, personal firewall, and other security programs are installed on it. All proxy downloads and temporary files required during the session are deleted after the session ends.

Remote Access is very important today. With more people needing to access information stored on home and work computers, the ability to access it from anywhere has become critical. Gone are the days when people said, “I’ll send you this information as soon as I get to my computer.” You need this information immediately if you want to compete in today's business world.

In the Stone Age of computerization, the way to gain remote access to your computer was to use a dial-up connection. RAS dial-up connections operated over regular POTS (Plain Old Telephone Service) lines at data rates up to approximately 56kbps. Speed ​​was the main problem with these connections, but an even bigger problem was the cost of the connection when access required long distances.

With the growing popularity of the Internet, RAS connections have become less and less used. The reason for this was the advent of VPN (virtual private network) connections. VPN connections provided the same point-to-point connectivity as dial-up RAS connections, but did it faster and cheaper, since the speed of a VPN connection can be the same as the speed of an Internet connection, and the cost of the connection does not depend on the location of the destination. The only thing you have to pay for is an Internet connection.

Virtual Private Networking

A VPN connection allows your computer to create virtual And private connection to the network via the Internet. Compound virtual because when a computer creates a VPN connection over the Internet, the computer creating this connection acts as a node directly connected to the network, as if it were connected to the network via cable local networks Ethernet. The user has the same access to resources that he would have if he were connected directly to the network using a cable. However, in the case of a VPN client connecting to the VPN server, the connection virtually because there is no valid Ethernet connection to the destination. VPN connection private, since the content of the data stream inside this connection encrypted, so no one on the Internet can intercept and read data transmitted via a VPN connection.

Windows Servers and clients have supported VPN connections since the days of Windows NT and Windows 95. Although Windows clients and servers have supported VPN connections for a decade, the type of VPN support has evolved over time. Windows Vista Service Pack 1 and Windows Server 2008 currently support three types of VPN connections. These are the following types:

• L2TP/IPSec

PPTP is a point-to-point tunnel protocol. PPTP is the easiest way to create a VPN connection, but, unfortunately, it is also the least secure. The reason this type is the least secure is because user credentials are sent over an insecure channel. In other words, VPN connection encryption begins After that how the mandates were transferred. Although actual credentials information is not transmitted between VPN clients and servers, the transmitted hash values ​​can be used by sophisticated hackers to gain access to VPN servers and connect to the corporate network.

The L2TP/IPSec VPN protocol is more reliable. L2TP/IPSec was jointly developed by Microsoft and Cisco. L2TP/IPSec is more secure than PPTP because a secure IPSec session is created before credentials are sent over the wire. Hackers cannot access the credentials and therefore cannot steal them for later use. Moreover, IPSec provides mutual authentication between machines, so unknown machines will not be able to connect to the L2TP/IPSec VPN channel. IPSec provides mutual authentication, data integrity, confidentiality, and non-repudiation. L2TP supports PPP and EAP user authentication mechanisms, which provide high security login because authentication of both the machine and the user is required.

Windows Vista SP1 and Windows Server 2008 currently support new type VPN Secure Socket Tunneling Protocol or SSTP. SSTP uses SSL encrypted HTTP connections to create VPN connections to VPN gateways. SSTP is secure because user credentials are not transmitted until a secure SSL tunnel to the VPN gateway is established open SSTP is also known as PPP over SSL, which means you can use PPP and EAP authentication mechanisms to make your SSTP connection more secure.

Private doesn't mean secure

It should be noted that VPN connections are private rather than secure. While I recognize that privacy is a fundamental component of secure communications, it does not in itself ensure that security. VPN technologies provide a private component to your Internet connection that prevents third parties from reading the content of your communications. VPN technologies also allow you to ensure that only authorized users can connect to a given network through the VPN gateway. However, private component,authentication and authorization does not provide comprehensive,security.

Let's say you have an employee for whom you have granted VPN access. Since your Windows Server 2008 VPN protocol supports EAP user authentication, you decide to create smart cards for your users and use the L2TP/IPSec VPN protocol. The combination of smart cards and L2TP/IPSec protocol allows you to require user authentication and use of a healthy machine. Your smart card and L2TP/IPSec solution works great and everyone is happy.

Everyone is happy until one day one of your users logs into your SQL server to get accounting information and starts sharing it with other employees. What happened? Was the VPN connection insecure? No, the VPN connection was secure enough to provide the private component, authentication and authorization, but it did not provide access control, and access control is one of the fundamental components computer security. In fact, one could even argue that without access control, all other security measures are of relatively little value.

For VPNs to be truly secure, you need to ensure that your VPN gateway is capable of providing user/group access control so that you can grant the required level of access to VPN users. More advanced VPN gateways and firewalls, such as the ISA Firewall, can provide such control on VPN connections. Plus, firewalls such as the ISA Firewall can provide address packet and application layer inspection on client VPN connections.

Although Windows Server 2008 VPN does not provide user and group access controls, there are other ways you can configure access controls on the server itself if you don't want to pay to purchase more advanced firewalls and VPN gateways. In this article, we focus our attention only on the components of VPN servers. If you would like to learn more about ISA firewalls and their capabilities for VPN servers, go to www.isaserver.org

Why use the new VPN protocol?

Microsoft has already created two viable VPN protocols that allow users to connect to the corporate network, so why create a third? SSTP is a great addition for Windows users VPN because SSTP does not have problems with firewalls and NAT devices, unlike PPTP and L2TP/IPSec protocols. For PPTP to work over a NAT device, the device must support PPTP using a NAT editor for PPTP. If there is no such NAT editor for PPTP on this device, then PPTP connections will not work.

L2TP/IPSec has problems with NAT devices and firewalls because the firewall needs to have an L2TP port UDP 1701 open for outgoing connections, an IPSec IKE port UDP 500 open for outgoing connections, and an IPSec NAT traversal port UDP 4500 open for outgoing connections (L2TP port is not required when using NAT-T). Most firewalls are in public places such as hotels, convention centers, restaurants, etc. have a small number of ports open for outgoing connections, such as HTTP, TCP port 80 and HTTPS (SSL), TCP port 443. If you need support for more than just HTTP and SSL protocols when you leave the office, your chances of a successful connection are significantly reduced . You may not receive the ports required for PPTP or L2TP/IPSec.

Unlike previous protocols, SSTP VPN connections go over an SSL channel using TCP port 443. Since all firewalls and NAT devices have open port TCP 443, you can use SSTP anywhere. This makes life much easier for travelers who use VPN connections to connect to the office, and also makes life much easier for corporate administrators who need to support travelers, as well as help employees in public places provide Internet access in hotels, conference centers, etc.

SSTP connection process

1. The SSTP VPN client creates a TCP connection to the SSTP VPN gateway between a random TCP source port of the SSTP VPN client and TCP port 443 of the SSTP VPN gateway.
2. SSTP VPN client sends SSL Client-Hello message, indicating that he wants to create an SSL session with the SSTP VPN gateway.
3. SSTP VPN gateway sends computer certificate SSTP VPN client.
4. The SSTP VPN client validates the computer's certificate by checking the Trusted Root Certification Authorities certificate database to ensure that the CA certificate signed by the server is in that database. The SSTP VPN client then determines the encryption method for the SSL session, generates the SSL session key and encrypts it with the public gateway's SSTP VPN key, and then sends the encrypted form of the SSL session key to the SSTP VPN gateway.
5. The SSTP VPN gateway decrypts the encrypted SSL session key using the private key of the computer's certificates. All subsequent connections between the SSTP VPN client and the SSTP VPN gateway will be encrypted using the agreed upon encryption method and SSL session key.
6. The SSTP VPN client sends an HTTP over SSL (HTTPS) request message to the SSTP VPN gateway.
7. The SSTP VPN client negotiates an SSTP channel with the SSTP VPN gateway.
8. The SSTP VPN client negotiates a PPP connection with the SSTP server. These negotiations include authenticating user credentials using the standard PPP authentication method (or even EAP authentication) and configuring settings for Internet Protocol Version 4 (IPv4) or Internet Protocol Version 6 (IPv6) traffic.
9. The SSTP client begins sending IPv4 or IPv6 traffic over the PPP connection.

Those who are interested in the characteristics of the VPN protocol architecture can see them in the figure below. Please note that SSTP has an additional header unlike the other two VPN protocols. This is thanks to additional HTTPS encryption in addition to the SSTP header. L2TP and PPTP do not have application layer headers to encrypt the connection.

Picture 1

We will take for example simple network from three machines to see how SSTP works. The names and characteristics of these three machines are as follows:

Vista Business Edition

Vista Service Pack 1

Non-domain member

W2008RC0-VPNGW:

Two NICs "Internal and External

WIN2008RC-DC:

Windows Server 2008 Enterprise Edition

Domain Controller of MSFIREWALL.ORG domain

Certificate Server (Enterprise CA)

Please note that Vista Service Pack 1 is used as a VPN client. While there have been discussions in the past about Windows XP Service Pack 3 supporting SSTP, this may not be the case at all. I recently installed a trial version of Windows XP Service Pack 3 on a test computer and found no evidence of SSTP support. And that's really bad, because too many laptops today use Windows XP, and the evidence suggests that Vista is too slow for laptops to run. Vista performance issues may be resolved with Vista Service Pack 1.

The high-level configuration of an example network is shown in the figure below.

Figure 2

Configuring Windows Server 2008 as a Remote Access SSL VPN Server

I'm not going to cover all the steps starting from the very basics. I would venture to assume that you have installed a domain controller and enabled the DHCP, DNS and Certificate Services roles on this server. The server certification type must be Enterprise and you have a CA on your network. The VPN server must be connected to the domain before continuing with the following steps. Before you begin, you need to install SP1 for the Vista client.

We need to follow the following procedures in order for our solution to work:

• Install IIS on VPN server
• Request a machine certificate for the VPN server using the IIS Certificate Request Wizard
• Install the RRAS role on the VPN server
• Activate RRAS Server and configure it to work as a VPN and NAT server
• Configure a NAT server to publish CRL
• Set up a User Account to use dial-up connections
• Configure IIS on Certificate Server to allow HTTP connections for the CRL directory
• Configure HOSTS file for VPN client
• Use PPTP to communicate with the VPN server
• Obtain CA Certificate from Enterprise CA
• Configure the client to use SSTP and connect to the VPN server using SSTP

Installing IIS on a VPN server

You may find it strange that we're starting with this procedure, since I recommend never installing a web server on a network security appliance. The good news is that we won't have to store the webserver on the VPN server; we'll only need it for a while. The reason is that the registration site included with Windows Server 2008 Certificate Server is no longer useful for requesting computer certificates. In fact, it's completely useless. The interesting thing is that if you do decide to use the registration site to obtain a computer certificate, it will appear as if the certificate has been received and installed, but in fact this is not the case, the certificate has not been installed.

To solve this problem, we will take advantage of the fact that we are using an enterprise CA. When using Enterprise CA, you can send a request to an online certificate server. An interactive request for a computer certificate is possible when you use the IIS Certificate Request Wizard and request what is now called a "Domain Certificate". This is only possible if the requesting machine belongs to the same domain as the Enterprise CA.

To install the IIS Web server role on the VPN server, follow these steps:

1. Open Windows 2008 Server Manager.
2. In the left panel of the console, click on the tab Roles.

Picture 1

1. Click on the menu Add roles With right side right panel.
2. Click Further On the page Before you start.
3. Place a check mark next to the line Web Server (IIS) On the page Select server roles. Click Further.

Figure 2

1. You can read the information on the page Web Server (IIS), if you wish. This is quite useful general information about using IIS 7 as a web server, but since we are not going to use the IIS web server on a VPN server, this information is not entirely applicable in our situation. Click Further.
2. On the page Select role services several options are already selected. However, if you use the default options, you will not be able to use the Certificate Request Wizard. At least that's how it was when I tested the system. There is no role service for the Certificate Request Wizard, so I tried checking the boxes next to each option Safety, and it seems to have worked. Do the same for yourself and click Further.

Figure 3

1. Review the information on the page Confirm settings selection and press Install.
2. Click Close On the page Installation results.

Figure 4

Request a Machine Certificate for a VPN server using the IIS Certificate Request Wizard

The next step is to request a machine certificate for the VPN server. The VPN server requires a machine certificate to create an SSL VPN connection with the SSL VPN client's computer. The common name of the certificate must match the name that the VPN client will use to connect to the SSL VPN gateway computer. This means that you will need to create a public DNS record for the name on the certificate that will resolve to the external IP address of the VPN server, or the IP address of the NAT device in front of the VPN server that will forward the connection to the SSL VPN server.

To request a machine certificate to the SSL VPN server, follow these steps:

1. IN Server Manager, expand the tab Roles in the left pane and then expand the tab Web Server (IIS). Press .

Figure 5

1. In the console Internet Information Services (IIS) Manager that appears on the right in the left panel, click on the server name. In this example the server name would be W2008RC0-VPNGW. Click on the icon Server certificates in the right pane of the IIS console.

Figure 6

1. In the right panel of the console, click on the link Create a domain certificate.

Figure 7

1. Enter information on the page Defined Name Properties. The most important object here will be Common name. This is the name that VPN clients will use to connect to the VPN server. You will also need a public DNS record for this name in order to recognize the external interface of the VPN server, or the public NAT address of the device in front of the VPN server. In this example we are using the common name sstp.msfirewall.org. Later we will create HOSTS records file on the VPN client's computer so that it can recognize the name. Click Further.

Figure 8

1. Click the button on the page Choose. In the dialog box Select certificate source, click on the Enterprise CA name and click OK. Enter a friendly name in the line Friendly name. In this example we used the name SSTP Cert to know that it is used for the SSTP VPN gateway.

Figure 9

1. Click Finish On the page Online certificate source.

Figure 10

1. The wizard will start and then disappear. You will then see the certificate appear in the IIS console. Double-click on the certificate and see the common name in the section Appointed to, and now we have the private key corresponding to the certificate. Click OK to close the dialog box Certificate.

Figure 11

Now that we have the certificate, we can install the RRAS Server Role. Please note what is very important install certificate before installing the RRAS Server Role. If you don't do this, you'll be setting yourself up for major headaches as you'll have to use a fairly complex command line routine to associate the certificate with the SSL VPN client.

Installing the RRAS Server Role on the VPN server

To install the RRAS Server Role, you need to complete the following steps:

1. IN Server Manager, click on the tab Roles in the left panel of the console.
2. In section General information roles click on the link Add roles.
3. Click Further On the page Before you start.
4. On the page Select server roles check the box next to the line. Click Further.

Figure 12

1. Read the information on the page Network Policy and Access Services. Most of it concerns Network Policy Server (which was previously called Internet Authentication Server and was essentially a RADIUS server) and NAP, none of the elements are applicable in our case. Click Further.
2. On the page Select role services put a check mark next to the line Routing and Remote Access Services. As a result, the items will be selected Remote Access Services And Routing. Click Further.

Figure 13

1. Click Install in the window Confirm selected settings.
2. Click Close On the page Installation results.

Activating RRAS Server and configuring it as a VPN and NAT server

Now that the RRAS role is installed, we need to activate the RRAS services, just like we did in the previous Windows versions. We need to activate VPN function NAT servers and services. Activating the VPN server component is all clear, but you may be wondering why you need to activate the NAT server. The reason for enabling the NAT server is so that external clients can access the Certificate Server to connect to the CRL. If the SSTP VPN client fails to download the CRL, the SSTP VPN connection will not work.

In order to open access to the CRL, we will configure the VPN server as a NAT server and publish the CRL using reversible NAT. In a corporate network environment, you will likely have firewalls, such as the ISA Firewall, in front of the certificate server, so you will be able to publish CRLs using the firewalls. However, in this example the only firewall we will be using is the Windows Firewall on the VPN server, so in this example we need to configure the VPN server as a NAT server.

To activate RRAS services, follow these steps:

1. IN Server Manager expand the tab Roles in the left panel of the console. Expand the tab Network Policy and Access Services and click on the tab. Right-click on the tab and click Configure and enable routing and remote access.

Figure 14

1. Click Further in the window Welcome to the Routing and Remote Access Server Setup Wizard.
2. On the page Configuration select option Access to Virtual Private Networks and NAT and press Further.

Figure 15

1. On the page VPN connection select NIC in section Network Interfaces, which represents the external interface of the VPN server. Then click Further.

Figure 16

1. On the page Assignment of IP addresses select option Automatically. We can select this option because we have a DHCP server installed on the domain controller behind the VPN server. If you do not have a DHCP server, then you will need to select the option From a specific address list, and then enter a list of addresses that VPN clients can use when connecting to the network through the VPN gateway. Click Further.

Figure 17

1. On the page Managing remote access of multiple servers choose No, use routing and remote access to authenticate connection requests. We use this option when NPS or RADIUS servers are unavailable. Since the VPN server is a member of a domain, you can authenticate users using domain accounts. If the VPN server is not part of a domain, then only local VPN server accounts can be used, unless you choose to use an NPS server. I will write an article about using an NPS server in the future. Click Further.

Figure 18

1. Read general information On the page Completing the Routing and Remote Access Configuration Wizard and press Finish.
2. Click OK in the dialog box Routing and remote access which tells you that DHCP message distribution requires a DHCP distribution agent.
3. In the left pane of the console, expand the tab Routing and remote access and then click on tab Ports. In the middle pane you will see that WAN Miniport connections for SSTP are now available.

Figure 19

Configuring a NAT server for CRL publishing

As I said earlier, the SSL VPN client must be able to download a CRL to verify that the server certificate on the VPN server has not been corrupted or revoked. To do this, you need to configure the device in front of the certification server to send HTTP requests for the location of the CRL to the Certificate Server.

How do I know which URL the SSL VPN client needs to connect to in order to download the CRL? This information is contained in the certificate itself. If you go back to the VPN server and double-click on the certificate in the IIS console as you did before, you should be able to find this information.

Click on the button Details on the certificate and scroll down to the entry CRL distribution points, then click on this entry. The bottom panel shows the different distribution points based on the protocol used to access those points. In the certificate shown in the image below, we can see that we need to allow the SSL VPN client access to the CRL via a URL:

http://win2008rc0-dc.msfirewall.org/CertEnroll/WIN2008RC0-DC.msfirewall.org.crl

Figure 20

This is why you need to create public DNS records for this name so that external VPN clients can assign this name to an IP address or device that will perform a reverse NAT or reverse proxy to access the certificate server's website. In this example we need to bind win2008rc0-dc.msfirewall.org with an IP address on the external interface of the VPN server. When the connection reaches external interface VPN server, the VPN server will redirect the NAT connection to the certification server.

If you are using an advanced firewall, such as the ISA Firewall, you can make publishing site CRLs more secure by allowing access only to the CRL, not to the entire site. However, in this article we will limit ourselves to the possibility of a simple NAT device, such as the one that provides RRAS NAT.

It should be noted that using the default site CRL name may be a less secure option because it reveals the computer's private name on the Internet. You can create a custom CDP (CRL Distribution Point) to avoid this if you think that exposing your CA's private name to the public DNS records poses a security risk.

To configure RRAS NAT to route HTTP requests to the certificate server, follow these steps:

1. In the left panel Server Manager expand the tab Routing and remote access, and then expand the tab IPv4. Click on the tab NAT.
2. In the tab NAT right-click on the external interface in the middle panel of the console. IN in this example the external interface name was Local Area Connection. Press Properties.

Figure 21

1. In the dialog box, check the box next to Web Server (HTTP). This will bring up a dialog box Editing service. In a text line Private address Enter the IP address of the certification server on the internal network. Click OK.

Figure 22

1. Click OK in the dialog box Local Area Connection Properties.

Figure 23

Now that the NAT server is installed and configured, we can turn our attention to configuring the CA server and SSTP VPN client.

Configuring a user account to use Dial-up connections

User accounts require dial-up access permissions before they can connect to a Windows VPN server that is part of an Active Directory domain. The best way to do this is to use the Network Policy Server (NPS), as well as the default user account permission, which allows remote access based on the NPS policy. However, in our case, we did not install an NPS server, so we will have to configure the user's dial-in access permission manually.

In the next article I will focus on using the NPS server and EAP User Certificate authentication to create connections with an SSL VPN server.

To allow a specific user account dial-in access to connect to an SSL VPN server, you need to complete the following steps. In this example, we will enable dial-in access permission for the default domain administrator account:

1. On the domain controller, open the console Active Directory users and computers from the menu.
2. In the left pane of the console, expand the domain name and click on the tab users. Double click on the account Administrator.
3. Go to the tab Dial-in. The default setting will be Access control via NPS network policy. Since we don't have an NPS server in this scenario, we'll change the setting to Allow access, as shown below in Figure 1. Click OK.

Picture 1

Configuring IIS on the Certificate Server to allow HTTP connections for the CRL Directory

For some reason, when the installation wizard installs the Certificate Services website, it configures the CRL directory to request an SSL connection. While this seems like a pretty good idea from a security perspective, the problem is that the Uniform Resource Identifier (URI) on the certificate is not configured to use SSL. I'm guessing you could create a CDP record for the certificate yourself so it can use SSL, but I'm betting Microsoft hasn't mentioned this issue anywhere. Since we are using the standard settings for CDP in this article, we need to disable the SSL requirement on the CA website for the directory CRL path.

To disable the SSL requirement for a CRL directory, follow these steps:

1. On the menu Administration Tools open manager Internet Information Services (IIS) Manager.
2. In the left pane of the IIS console, expand the server name, and then expand the Websites. Expand the tab Default website and click on the tab CertEnroll, as shown in Figure 2.

Figure 2

1. If you look at the middle panel of the console you will see that CRL is located in this virtual directory, as shown in the figure below. To view the contents of this virtual directory, you need to click the button View content at the bottom of the middle panel.

Figure 3

1. Click on the button View options at the bottom of the middle panel. At the bottom of the middle panel, double-click on the icon SSL Settings.

Figure 4

1. A page will appear in the middle panel SSL Settings. Uncheck the box Require SSL. Click Apply in the right pane of the console.

Figure 5

1. Close the IIS console after you see the notification Changes were successfully saved.

Figure 6

Setting up a HOSTS file for a VPN client

Now we can give our full attention to the VPN client. The first thing we need to do with the client is set up a HOSTS file so that we can simulate a public DNS infrastructure. There are two names that we need to enter into the HOSTS file (the same needs to be done for the public DNS server that you will use in production networks). The first name is VPN name server, as determined by the common/subject name of the certificate that we have bound to the SSL VPN server. The second name we need to enter into the HOSTS file (and public DNS server) is the CDP URL name, which is on the certificate. We looked at the location of CDP information in Part 2 of this series.

The two names that need to be entered into the HOSTS file in this example would be:

192.168.1.73 sstp.msfirewall.org

192.168.1.73 win2008rc0-dc.msfirewall.org

To configure the HOSTS file for the Vista SP1 VPN client, follow these procedures:

1. On the menu Start enter c:\windows\system32\drivers\etc\hosts into the search bar and press ENTER.
2. In the dialog box To open with select Notebook.
3. Enter entries into the HOSTS file in the format as shown in the image below. Be sure to press enter after last line so that the cursor is under it.

Figure 7

1. Close the file and select the option save changes.

Using PPTP to connect to a VPN server

We are gradually getting closer to creating an SSL VPN connection! The next step is to create a VPN connector on the Vista SP1 client, which will allow us to create an initial VPN connection to the VPN server. In our case, this needs to be done because the client computer is not a member of the domain. Because the machine is not a member of a domain, the CA certificate will not be automatically installed in its Trusted Root Certificate Authorities store. If the machine were part of a domain, automatic registration would have taken care of this problem for us since we installed the Enterprise CA.

The easiest way to complete this step is to create a PPTP connection from the Vista SP1 VPN client to the Windows Server 2008 VPN server. By default, the VPN server will support PPTP connections, and the client will try PPTP first before trying L2TP/IPSec and SSTP. To do this, we need to create a VPN Connector or connection object.

To create a connector on the VPN client, follow these steps:

1. On the VPN client, right-click on the network icon and click Network and switching center (Sharing Center).
2. In the Switching Center Network window, click on the link Create a connection or network on the left side of the window.
3. On the page Select connection options click on entries Connect to workplace, then click Further.

Figure 8

1. On the page How do you want to connect select option Use my Internet connection (VPN).

Figure 9

1. On the page Enter the Internet address to connect enter the name of the SSL VPN server. Make sure this name and the common name on the certificate used by the SSL VPN server are the same. In this example the name was sstp.msfirewall.org. Enter Recipient's name. In this example we will use the recipient's name SSL VPN. Click Further.

Figure 14

1. In the window Network and switching center, click on the link Show status In chapter SSL VPN, as shown in the figure below. In the dialog box SSL VPN Status you will see that the VPN connection type is PPTP. Click Close in the dialog box SSL VPN Status.

Figure 15

1. Open the window command line and send a ping command to the domain controller. In this example, the IP address of the domain controller would be 10.0.0.2 . If your VPN connection is successful, you will receive a ping response from the domain controller.

Figure 16

Obtaining a CA Certificate from an Enterprise CA

The SSL VPN client must trust the CA that issued the certificate used by the VPN server. To create this trust, we need to install a CA certificate on the CA that issued the certificate for the VPN server. We can do this by connecting to the CA registration website on the internal network and installing the VPN client's certificate into its Trusted Root Certification Authorities store.

To obtain a certificate from the registration site, follow these steps:

1. On the VPN client connected to the VPN server via a PPTP connection, enter http://10.0.0.2/certsrv in the address bar in Internet Explorer and press ENTER.
2. Enter the username and password used in the credentials dialog box. In this example, we will use the username and password of the default domain administrator account.
3. On the page Greetings registration site follow the link Upload a CA certificate, certificate chain, or CRL.

Figure 17

1. A dialog box warning you that A website wants to open web content using this program on your computer, press Allow. Then click Close in the dialog box Have you noticed the information window?, if it appears.Download complete.
2. Closing Internet Explorer.

Now we need to install the CA certificate in the Trusted Root Certification Authorities Certificate Store of the VPN client machine. To do this you need to do the following:

1. Click Start, then enter mmc in the search bar and press ENTER.
2. Click Continue in the UAC dialog box.
3. In the window Console1 click menu File, and then click Add/Remove Snap-in.
4. In the dialog box Add or Remove snap-ins choose Certificates on the list Available accessories, then press Add.
5. On the page Certificate snap-ins select the option Computer account and click Finish.
6. On the page Select computer select the option Local computer and click Finish.
7. Click OK in the dialog box Add or remove snap-ins.
8. In the left panel of the console, expand the tab Certificates (Local Computer) and then expand the tab Click Finish On the page Completing the import of certificates.
9. Click OK in a dialog box informing you that the import was successful.
10. Now the certificate will appear in the console as shown in the image below.

Figure 24

1. Close the MMC console.

Configuring the client to use SSTP and connecting to the VPN server via SSTP

And now everything is almost ready! Now we need to disconnect the VPN connection and configure the VPN client to use SSTP for the VPN protocol. In a production environment, you will not have to use this step for users, since you will use the Connection Manager Administration Kit to create a VPN connection object for the user that will include a client that uses SSTP, or you will only configure SSTP ports on the VPN server.

It all depends on your environment configuration, as you need to schedule the time so that users can use PPTP for some time while you install the certificates. Of course, you can install CA certificates offline, that is, by downloading from a website or via email, in which case you won't have to allow PPTP users. But then, if some clients don't support SSTP, you'll need to enable PPTP or L2TP/IPSec, and you won't be able to disable all non-SSTP ports. In this case, you will have to rely on manual configuration or an updated CMAK package.

Another option here would be to bind the SSTP client to a specific IP address on the RRAS server. In this case, you can create a custom CMAK packet that refers only to the IP address on the SSL VPN server listening to the network for incoming SSTP connections. Other addresses on the SSTP VPN server will listen to the network for PPTP and/or L2TP/IPSec connections.

Follow these steps to disable the PPTP session and configure the VPN client connection object to use SSTP:

1. On the VPN client computer, open a window Network and switching center, as they did before.
2. In the window Network and switching center click on the link Disconnect, which is located directly below the link Show status. Chapter SSL VPN will disappear from the window Network and switching center.
3. In the window Network and switching center click on the link Managing network connections.
4. Right click on the link SSL VPN and select a tab Properties.

Figure 25

1. In the dialog box SSL VPN Properties go to the tab Net. In the window VPN type click the down arrow and select an option Secure Socket Tunneling Protocol (SSTP), then click

Figure 29

Thomas Shinder

There are currently two types of custom VPNs:
SSL VPN And IPSec VPN and each of them has its own advantages and disadvantages.

The main advantage of SSL VPN is its ease of implementation: all browsers support SSL, all providers allow and do not restrict SSL.
Some types of access via SSL VPN can be achieved with literally any browser and on any platform.

IPSec VPN is considered a more secure protocol.

SSL and TLS

Very often in technical literature you can come across the concepts of SSL and TLS.

Both protocols are cryptographic protocols, providing secure data transfer over the Internet (e-mail, web browsing, instant messaging).
Protocols provide confidentiality, integrity, authentication services.
SSL and TLS work at the level Session Layer OSI model or higher.
Protocols can use public key infrastructure (PKI) as well as certificates for authentication and transfer of symmetric keys to each other.
Just like IPSec, they use symmetric keys to encrypt data.

Most secure browser transmissions are done over SSL or TLS.
SSL was originally developed by Netscape.
TLS is further development SSL, as well as a standard developed by Internet Engineering Task Force (IETF).
For example, TLS 1.0 is based on SSL3.0.
The browsers themselves decide whether to use SSL or TLS: TLS is preferable, but switching to SSL is also possible.

Thus, it is important to understand that when we use the term SSL we mean SSL or TLS.
For example, Cisco SSL VPN actually uses TLS.

SSL Operations

So, SSL is used in most online services that require security.
Let's take a step-by-step look at what happens when a client connects to a banking server using SSL:

• The client initiates a connection to the server to its IP address and port 443. The client’s IP and port higher than 1023 are used as the source, respectively.
• The standard TCP connection process takes place using three-way handshake
• The client requests an SSL connection and the server responds by sending its digital certificate, which contains public key this server.
• After receiving a certificate, the client must decide whether to trust this certificate or not.
  This is where PKI mechanisms come into play.
  If the digital certificate is signed by a CA that the client trusts + the certificate is valid by date + the certificate serial number is not listed in certificate revocation list (CRL)- the client can trust the certificate and use public key this certificate.
• The client generates a symmetric key shared secret, which will be used to encrypt data between the client and server. Next, the client encrypts shared secret using public key and passes it on to the server.
• Server using its private key, decrypts the resulting symmetric key shared secret.
• Both sides now know shared secret and can encrypt SSL Session.

Types of SSL VPN

SSL VPN can be divided into two types:

• Clientless SSL VPN- also called Web VPN. Does not require client installation. Limited opportunities.
• Full Cisco AnyConnect Secure Mobility Client SSL VPN Client- a full-fledged SSL client that requires installation of software on the client that provides full access to the corporate network

Setting up an SSL VPN

1. Copy the Anyconnect PKG file.
   In our case it is anyconnect-win-3.1.08009-k9.pkg
2. We point to the pkg file and enable the Webvpn Anyconnect service.
   

   webvpn anyconnect image disk0:/anyconnect-win-3.1.08009-k9.pkg 1 enable outside2 anyconnect enable

3. We exclude (exempt) SSL WebVPN traffic from checks for outside interface ACL. We need to either make permit rules in the ACL, or use the command:
   

   msk-asa-01(config)# sysopt connection permit-vpn

4. For convenience, let’s set up redirection from 80 to 443:
   

   http redirect outside2 80

5. Let's create IP address pool. These addresses will be issued to remote users.
   

   ip local pool vpnpool_pool 192.168.93.10-192.168.93.254 mask 255.255.255.0

6. We create NAT exemption for traffic between LAN Network and the VPNpool network. We make this exception because encrypted traffic should not go through NAT. This step is necessary if this NAT is configured on the ASA.
   object network vpnpool_obj

   object network vpnpool_obj subnet 192.168.92.0 255.255.255.0 object-group network RFC1918_objg network-object 192.168.0.0 255.255.0.0 network-object 172.16.0.0 255.240.0.0 network-object 10.0.0.0 255 .0.0.0 nat (inside,outside) source static RFC1918_objg RFC1918_objg destination static vpnpool_obj vpnpool_obj no-proxy-arp route-lookup

7. We create a Split-Tunnel ACL; this setting will allow users to simultaneously use the Internet when connected via VPN. Without this setting, all traffic will be turned into the tunnel.
   

   access-list split-tunnel_acl standard permit 192.168.10.0 255.255.255.0

   This setting will wrap only traffic in the network of the same RFC1918 into a tunnel.

8. We create Group Policy.
   We can create several Group Policies, and in each one configure network attributes such as DNS server addresses, split-tunneling settings, default domain, protocol (SSL or IPSec), etc.

   group-policy anyconnect_gp internal group-policy anyconnect_gp attributes dns-server value 192.168.10.5 vpn-tunnel-protocol ssl-client ssl-clientless split-tunnel-policy tunnelspecified split-tunnel-network-list value split-tunnel_acl webvpn anyconnect keep-installer installed anyconnect dpd-interval client 20 anyconnect ask none default anyconnect

9. Let's create Tunnel Group.
   The Tunnel Group in the ASDM interface is called Connection Profile.
   The Tunnel Group should include the Group Policy we just configured and combine it with the IP address pool.
   We can create several such groups, and the user, when logging in, can select the desired Tunnel Group with all the necessary characteristics: inherited parameters from Group Policy + address-pool

   tunnel-group vpn-users_tg type remote-access tunnel-group vpn-users_tg general-attributes address-pool vpnpool_pool default-group-policy anyconnect_gp tunnel-group vpn-users_tg webvpn-attributes group-alias vpn_users-alias enable webvpn tunnel-group- list enable

   The last command allows users to choose a tunnel-group for themselves.
   For users, this group will look like "vpn_users-alias"

Anyconnect should already be working - you can log in using an admin account.

SSL VPN Monitoring

• ASDM: Monitoring > VPN > VPN Statistics > Sessions
• From the CLI:
  

  vpn# show uauth Current Most Seen Authenticated Users 1 1 Authen In Progress 0 0 remote access VPN user "vpn_video_user1" at 192.168.92.25, authenticated access-list #ACSACL#-IP-video_dacl-54ddc357 (*)

  vpn# show access-list access-list cached ACL log flows: total 0, denied 0 (deny-flow-max 4096) alert-interval 300 access-list split-tunnel_acl; 1 elements; name hash: 0xb6fb0e access-list split-tunnel_acl line 1 standard permit 192.168.10.0 255.255.255.0 (hitcnt=0) 0x13482529 access-list #ACSACL#-IP-video_dacl-54ddc357; 1 elements; name hash: 0x6c7d7b7f (dynamic) access-list #ACSACL#-IP-video_dacl-54ddc357 line 1 extended permit ip any4 host 192.168.10.45 (hitcnt=0) 0x4ce5deb8

  Let's see who is logged in

  show vpn-sessiond summary

  show vpn-sessiond anyconnect

  Kick a user from VPN:

  vpn-sessiondb logoff name langemakj

For three days and three nights I fiddled with SSL VPN, looking for clientless software options. And I even found some wonderful version of Hypersocket, positioning itself as .

But when reading the annotation on Sourceforge, I clicked a sentence saying that founders are not pressured to provide access from the browser. So this is an SSL VPN working at the application level, but, unfortunately, based on its own client, which uses the Java engine to work and is loaded with a separate widget that initializes the connection. But despite its apparent simplicity, it does not work on a click and you have to tinker to set up connections, because the main advantage of the client is that it breaks into port 443 of the VPN server, and can be used inside any tortured infrastructure where paranoid administrators hack all output ports.

It is available in a completely free version 1.1 offered on Sourceforge and a commercial version 2.0.5 which is given from the off-site in the form of a fully functional trial for 30 days. And this question is not completely clear to me, since I did not find any prices on the site at all. That is, they apparently roll it out when you have already configured and connected everything, so that you do not immediately abandon their product.

Before starting the installation, you need to be puzzled by the sideboard, because I didn’t find the requirements, but version 1.1 eats about 450Mb in the default installation, so I couldn’t understand why on the cheap VPS for 200 rubles my server was constantly overloaded with any changes. With 1Gb of memory, everything was already extremely stable and without a single break. The second version uses almost 600Mb of RAM.

It is installed simply, except for the standard dances with Oracle Java. , we register all the necessary paths, after which we either install a free server from 2015:
# wget https://sourceforge.net/projects/hypersocket-vpn/files/1.1.0-2269/hypersocket-vpn-gpl-linux-1.1.0-2269.rpm/download

or register on the official website and get from them hypersocket-one-linux-2.0.5-3110.rpm

Then we install the package
# rpm -i hypersocket-one-linux-2.0.5-3110.rpm

After this, we either start the first version of the package
service hypersocket start
and connect to https://IP:443 with login admin:admin where we immediately get to work

or the second
hypersocket-one-console
or at https://IP:443 we complete the web installation, set passwords for the system and feed the pre-downloaded license file

After which you can go inside and set up accesses and so on. The second version, in my opinion, is quicker and a little more thoughtful than the first.

This VPN Server, as I already said, is not particularly suitable for me, because it assumes the presence of a client on the side remote user, but at the same time it has a bunch of interesting additional features, like access to virtual files file system through which you can access Windows sharing, ftp content, NFS volumes, HTTP files, etc.; web page publisher for remote web servers; a bunch of all sorts of security features from PIN codes to one-time passwords; user management via Muscle, AS400, Google Business, LDAP.