Server VPN: konfiguracja w oparciu o Windows 2012 [TUTORIAL]

Good day. Hello everyone to today's webinar. My name is Paweł Telbuch, I am an instructor at Altkom Akademia. I have been working at Altkom for 14 years and basically only deal with Microsoft technologies – mainly server technologies, client technologies – and today I will present you the VPN Server solution based on Windows 2012 operating system. Briefly what this presentation will be about today. Well, I would divide the presentation into 2 blocks: The first block will be such a theoretical block, in which I will tell you about Server VPN, what are the vpn protocols etc stuff.

The second part of this presentation will be a practical part, in which I will present how to build a VPN Server based on Windows Server 2012 version. So the first point is exactly the introduction to remote access services based on the Windows Server 2012 environment – here I will tell about the possibilities that are. The second part is an overview of VPN protocols, that is, a few words about the protocols themselves that will be used in the Servera VPN environment.

And the rest of this presentation will be a practical presentation, in which I will present the installation and configuration of VPN Server based on Server 2012, and configuration of the client of this VPN Server based on Server Windows 8. Of course, Server VPN, as the title says in today's presentation, will be in an extremely condensed form, so like the title – in a nutshell. However, this service is much more widely discussed at authorized courses. The first such course in which this service is discussed, this is the course 20411 "Windows Server Administration 2012 version." The second course that I could recommend to you in the field of which deals with Windows 2012 and the service in fact VPN Server, is 20412 "Upgrading Your Skills to MCSA Windows Server 2012", i.e.

The course is dedicated to administrators familiar with the Windows Server 2008 environment, who would like to expand their knowledge with Server 2012. Access to remote access services. Server VPN – Server VPN is a commonly used solution today in IT environments for various purposes. The basic and the most common scenario of using VPN Server will work remotely. Administrators, employees of my company will be able to connect with the interior of my organization and perform administrative activities, perform your work in my company, physically being elsewhere entirely. This is perhaps the most widely used model, the VPN Server scenario. However, of course, Server VPN can also be used for remote work, but also, for example, to cover the security of the RDP connection, i.e. Remote Desktop Protocol, which is not considered particularly safe. Hence, the system will leave a VPN tunnel first and within the VPN tunnel launched an RDP connection. Yet another use of VPN Servers, or VPN connections in general, there will be a set of such tunnels between 2 departments of the organization, in which tunnel the information of the given organization will be sent, i.e.

The Active Directory database will be replicated, for example, DNS replication, or some other database systems. These are the most common VPN Server solutions. Remote access methods. The first remote access method we used a while ago, was the method using analog telephone lines, or PSTN. PSTN was not a great solution, because generally a very slow connection – in theory, 56 kilos of transmission. It also differs with security – analog transmission via generally available analog lines, so it was generally not common. I mean, it was common in those days, maybe the greatest advantage of the PSTN connections was the accessibility of the links. Over time, PSTN was replaced by a digital telephone line, or ISDN. The advantage of ISDN and such a revolutionary advantage of these ISDN connections was the fact that that there were 2 communication channels, each 64 kb, so you could talk on the phone at the same time, you could download data at that time, which is a completely revolutionary approach to the PSTN. However, the disadvantage of these 2 solutions, i.e. both PSTN and ISDN, there were certainly costs, as in both cases a combination, information exchange between organizations is called impulse billing.

Hence, it's a very expensive thing. Today, the most expensive connections are analog ones, so in the case of PSTN, these costs are really unbelievable. And PSTN, as I said, is probably not practically used anymore today. On the other hand, ISDN networks are still in use, because very often organizations use ISDNs as Internet backup links. And now, maybe a few words how the VPN Server was created, how the VPN approach was invented. It turns out that if the company had a branch in the States and its headquarters somewhere in Australia, is the exchange of information between these organizations, or between these divisions of my organization, is a telephone connection between these countries here, between these continents even, so it was tremendously expensive. Therefore, someone came up with the idea "OK, but I am dialing my Internet Service Provider, for example and I can browse sites standing up on servers in the United States at the same time without incurring the costs of a telephone connection with this Server. And this is how the VPN Server was invented, i.e. a sealed tunnel, theoretically indecipherable, not interceptable in real time by public internet connections. VPN is, as I said, widely used today.

A few words about the next solution that appeared in Microsoft server systems in the 2008 R2 system for the first time. This is Direct Access. The Direct Access service is supposed to be something better and maybe different than Server VPN, but it is also supposed to provide users with external access to my network. The main advantage of the Direct Access service is the fact that that the connection with the Server within my environment will of course be implemented by the user. The user does not need to run any additional client, with which you join your organization, only the workstation at which the user will work, it will automatically establish a connection to the Server itself and give it access to its resources. However, Direct Access is not a very popular solution so far. For a simple reason – it requires, of course, Server 2008 R2, 2012 minimum. Of course, it supports it natively, but requires the client to have the highest version, that is, in the Enterprise version, which not every organization is able to afford.

An additional onerous requirement for Direct Access, which is probably still today there is a requirement to have a public IP version 6, that is, just using a version 6 address. It is still not common today, after all. A few words about VPN protocols, i.e. what VPN protocols in Server 2012 I can use. The first basic and so-called hassle-free VPN protocol there will be PPTP (Point to Point Tunneling Protocol), i.e. the basic tunneling protocol, which is perhaps the easiest to implement probably in the entire environment of Microsoft server systems, how is it basically installing Server VPN on the so-called Enterach, i.e. Next, Next, Next, Finish and connection via this protocol should work without any additional configuration. This protocol is used to encrypt traffic within the VPN tunnel uses Microsoft's MPPE (Microsoft Point-to-Point Encryption) encryption mechanism. There is no additional authentication in the tunnel – like I said, the simplest – there is no problem with the machine standing behind the NAT service.

In fact, it always works. All Microsoft customers, including the really old ones, so to speak, in quotation marks, that is, the famous 9X ran on this protocol. Further, the second protocol is L2TP (Layer Two Tunnelling Protocol), that is, the second layer tunneling protocol. The protocol is already more advanced in terms of design. First of all, this encryption protocol uses a fairly strong mechanism like IPSec. And like IPSec, there will definitely be 2 additional functionalities within the tunnel, that is, authentication within the user tunnel, two – the encryption mechanism. IPSec is an encryption mechanism, that is, the encryption of the entire contents of the tunnel. This is L2TP. This protocol has a problem with data transmission when the machine is behind the NAT. Not so much the protocol as NAT has a problem with passing this information. And here you need to apply the correct version of the protocol, the NAT service. No protocol. Sorry, NAT services. It must be NAT t – traversal NAT, and then there is no problem with this protocol.

NAT t was already implemented in the 2003 system, so we can basically conclude that there is no problem with this protocol either. The third VPN protocol that has been available since Windows Server 2008 – since 2008 it has appeared – there is SSTP protocol. This protocol seems to be a very interesting solution in many organizations, as this protocol uses standard SSL for encryption. Hence? To release tunneling, traffic to the VPN Server within my organization, all I have to do is put out the protocol, which is usually released anyway, which is 443; in any additional configuration on the Firewall device to release this traffic. The fourth protocol is the Internet Key Exchange, that is, a protocol that has already appeared somewhere before; version 2 is here. The use of this protocol in the VPN Server is only possible from version 2008 R2. 2008 R2 introduces this protocol and the biggest advantage of this IKE version 2 protocol is the fact that that it is possible to resume the session in case of its disconnection. So when the VPN session was disconnected, we would normally lose it. Here the system can resume it. This is a very important thing when you pull the cable out of your network card.

Moreover, in the case of networks built with Wi – Fi, when the user changes his location and the Access Point is switched, the user can resume this VPN session. A few words about authentication protocols. I will not go into technical details here. However, here we have four standard protocols: The first protocol is PAP. This protocol is characterized by having all the credentials within this protocol they are sent in plain text, so be careful. The second protocol is CHAP, the third is MS-CHAP – Microsoft's implementation of the CHAP protocol – and the last one is EAP (Extensible Authentication Protocol) used for all the other authentication mechanisms out there, where the so-called complex credentials, for example, that is, other than login name and password – certificates for example. These are the protocols. The protocols will be configured from the side of the Server itself, i.e.

With the VPN Server and the service, which controls access to the VPN Server. For example, NAP or NPS, i.e. Microsoft's RADIUS Server, will be able to define the rules, which will have to be met in order for the user to connect to the Server. One of them will be e.g. the use of an appropriate authentication protocol. VPN Server Requirements. The first element that is required when installing Server VPN are 2 network interfaces: One directs movement inside the organization, the other, of course, directs traffic outside. In addition, the next element that I will be asked for when configuring the VPN Server, is the decision whether the clients who connect to the VPN Server they get the IP address directly from the DHCP Server whether this address will be directly assigned from the VPN Server from the static pool, which pool I will define in the process of VPN Server configuration.

The next question I will have to answer when installing VPN Server, is how users are authenticated. And here I can choose two: The first is Server VPN, i.e. whether the VPN Server has direct contact with the Active Directory database and this Server will authenticate the user in the AD database, or the second, more secure, but more advanced mechanism – whether Server VPN will be a client of RADIUS Server and the RADIUS Server will authenticate the user against the Active Directory database. The next item is the DHCP Relay Agent. If the administrators chose that the client connecting to my infrastructure, will get the IP address from the DHCP Server, then I have to ensure that this IP address can be retrieved from the DHCP Server for the client.

The entire process of obtaining an IP address from the DHCP Server is done using Broadcast traffic. Hence? Services, devices that stand between VPN Server and DHCP Server, generally they do not run this type of traffic. Hence the problem of assigning an automatic IP address. The DHCP Relay Agent is designed to redirect the request retrieving the IP address from this client segment to the DHCP Server.

In short, the DHCP Relay Agent will communicate on behalf of the client using Unicast with a DHCP Server, will get this IP address for the client and pass it on to the client on his network segment. The last element that is necessary to install VPN Server, these are, of course, powers. So, you need administrative privileges on the machine on which I will install the VPN Server. Let's move on to the practical part, in which I will present you VPN Server setup process on my lab machines. In my lab environment, I have 3 running machines: This is my domain controller, it is the Server that will act as the VPN Server, and a Windows 8 client that will serve as a client in my environment. First of all, we will install the VPN Server service on the Server. And here it has changed a bit compared to the Windows 2008 version, how the role of the VPN Server has been grouped differently, grouped differently than in the 2008 environment. As a role, Microsoft has given a new facility called Remote Access and generally, this Remote Access role groups both VPN and Direct Access services.

Of course, today we will focus only on the role of VPN, so on the so-called Enterach, I click Next, Next, Next, Finish. We will install the VPN Server service. After the installation, the administration console for the remote access service will appear. So an additional MMC console will appear in the Tools section, which is called Remote Access Management – it is a console for managing remote access to my Server. This role is primarily used to configure the Direct Access role. When I run a wizard here to configure remote access, it's him in the background anyway, choosing remote VPN access, will open the old, probably well-known RRAS, that is the Routing and Remote Access console.

So I will configure everything within RRAS right away. Configure and Enable Routing and Remote Access, i.e. enable and configure the RRAS role. How will the Wizard appear in Microsoft systems, in which I will decide what to install. The first choice is Dial-Up, or VPN, which is the type of connection. NAT – I can install NAT with a VPN, secure the connection between 2 networks, or in the Custom Configuration section, I can even choose the rooter, i.e. the Microsoft system as the rooter. As this session is dedicated to VPN Server, I will choose Server VPN. Please note that we will be installing the VPN Server role. And the first question: Which of the network interfaces on my machine is the interface to the Internet? In my case, it is the one known as VAN. And here the information appears below: Do you want to secure this interface RRAS's built-in packet filter? At this point, perhaps administrators of older systems – read 2003 – they recall such a message.

When installing the VPN Server, the RRAS service asked to disable the Firewall service in the system, what would seem like a strange operation, because we are starting remote access services, and we have been asked to disable the Firewall service, which, however, is closely related to the remote access service. Why is it like that? Because RRAS has always had its packet filter built in, which is basically such a basic Firewall. We will secure this interface immediately with this Firewall. The next question is asking for an IP address for the client who will connect from the outside. It is known that clients connect to my infrastructure from the outside will have a completely different address pool, and in my network segment you must have my address pool. From here I can assign this address either from the DHCP Server as I said before, but then we have to remember about the DHCP Relay Agent service, or assign an IP address from a DHCP Server.

Sorry, from the static pool of, of course, my VPN Server. And I will prepare such a static pool. The internal address pool on my network is 172.16.0. We will do from address 100 to 172.16.0.150, that is, 51 addresses reserved for clients connecting to RRAS. Next. Question: Will we use RADIUS Server for authentication, i.e. Microsoft NPS, will Server VPN itself authenticate users? Well, I don't have a RADIUS server here. RADIUS Server is configured in these more advanced courses.

Here we will take care of such a simple configuration of VPN Server, so we will select without RADIUS Server, finally Finish. A message for administrators who have chosen that the IP address will be obtained from the DHCP Server, that you should remember about Relay. OKAY. And basically at this point, we have already installed Server VPN. So, as I said, VPN Server configuration in Microsoft systems it is not particularly advanced.

In the RRAS Server console I have information about the interfaces connected to my environment, about the ports that were being created. And by default, 128 ports of each protocol supported by Server VPN should be created here. Connected clients, event logging options, packet filters for IP version 6 and version 4. The VPN server is ready. I will now switch to the client system – it's Windows 8 – and create a connection to the VPN Server. We will create a connection to the VPN Server in the Network and Sharing Center console, we will select the Setup, New Connection or Network section.

I am interested in connecting to a VPN, please use my connection. The system detected that the virtual machine has no Internet access, that is, it suggests that he configured this output to the Internet here. This is unnecessary for the lab, so I will choose the configuration later, I will enter the IP address of the VPN Server – for me it is 10/10/10/10. – I will create a connection to the VPN Server, it appears here, we will display the properties of that connection. And here we have important information: definitely the IP address of the VPN server and on the Security tab, the authentication protocols: EAP and all of those mentioned before, i.e. PAP, CHAP and MS-CHAP. These are the protocols. Please note that in the Windows 8 client, after establishing an object of the connection to VPN network, none of the protocols is selected. In previous client editions, after the establishment of this object, one of the protocols, as far as I can remember, I think Microsoft CHAP was always selected, so basically it was enough to create a connection and you could try to connect.

Here I will have to specify the protocol by which I will connect. I will also need to specify the VPN protocol, tunneling protocol that I will be using. By default, automatic is set here, which means that the system tries to select protocols one by one when connecting and hit the best or working protocol. Because during the presentation I said that the VPN Server works flawlessly and on the so-called Enter using the PPTP tunneling protocol and if I choose this protocol, basically at this point I should be able to connect to the VPN Server. And I will try to do it now: administrator and password. It turns out that I haven't been able to connect to the VPN Server. Why this connection could not be completed? Because, by default, all accounts in the Active Directory database, that is in the Active Directory Users and Computers console – I will present it in a moment – in the user account properties on the Dial-In tab all users in the domain have the standard marked "Control access to the Server, for remote connection using NPS.

" When installing the VPN Server role, I did not select the NPS role, it is simply not here. So if there is no NPS, I won't be able to verify will I really be able to connect to the VPN. The system will show it to me by forbidding my connection. Therefore, I will change this setting to Allow Access and explicitly allow the administrator user to make connections to the VPN Server. I go back to the client and try to connect to the VPN Server again. Connected to the VPN Server, I can verify it at the moment by verifying the IP address – cmd, IPConfig. It turns out I have 2 interfaces: One my physical interface which is addressed with decimal addressing and the second virtual interface that was created when connecting to the VPN, which is addressed to 172.16.0.101 and this is the address of this pool that the VPN Server stores. OKAY. We disconnect from the VPN Server and now I will try to connect to the VPN Server using the L2TP protocol.

So on the Security tab I will select the L2TP protocol and like I said before some elements will need to be configured in the L2TP protocol, that this connection can be made. The first is the distribution of certificates. If I want to use L2TP with IPSec and certificates, then I will have to prepare a certificate for IPSec in advance and distribute these certificates at the computer account level to IPSec. I will choose a less popular solution, i.e. the preshared key – secret code, same on client side and the same on the Server side, and I'll try to connect. The secret code is like this. OKAY. From the customer's point of view, it has already been prepared, but you have to go back to Server VPN and allow the VPN Server to make client connections using the L2TP protocol and using the secret code preshared key. A message appears that the VPN Server should be restarted after this change and indeed, it is required. I will restart the RRAS service and I will go back to the client and I will try to connect to the VPN Server using the client again.

It lasts for a while. OK, here we are. I am on the client and make the call. It turns out that I was able to connect using the L2TP protocol. IPConfig and I got 172.16 addressing. And that's the entire VPN Server configuration along with the Windows 8 client configuration. Let's go back to the presentation. Finally, a few words about the distribution of the client configuration. Let's imagine that the administrators in the organization have actually launched Server VPN, i.e. they have configured the VPN Server in the environment and told users, "OK, there is VPN Server. Please log in, you can use remotely. " It is clear that this will not be a commonly used connection by users, because the user should know what the address of the VPN Server is, what protocol should he use, what authentication mechanism etc.

This is not obvious to the standard user. Therefore, administrators using such a tool, which is the Connection Manager Administration Kit, the popular CMAK, will be able to create an EXE file, which EXE file is delivered to the workstation running on this workstation, will establish a connection to the VPN Server in exactly the same way, as I did it manually on the Windows 8 client. So I have a tool that will automatically create a connection to the VPN Server in my environment without additional configuration from the administrator side on the workstation. Just running an application that is, Connection Manager Administration Kit. What does it allow? Allows you to create connections to the VPN Server on the client station, that is, creates an object in combination. Generates an EXE file that will create this connection when run; reduces the number of reports to the Help Desk department, because I will configure the connection with one file – I won't have a lot of questions, what protocol, what IP address – and eliminates the problem of incorrect customer configuration, which can in principle always appear here.

That's it when it comes to configuring VPN Server in a really nutshell. The VPN server in this presentation seems to be a very simple and uncomplicated solution and in a nutshell, in such a basic version, it really is. However, the possibilities that RRAS has along with the NPS service with which the RRAS service cooperates, there is a lot, so there is definitely a lot more to say about this solution.

I encourage you to participate in training courses that accurately describe these things. Let me remind you once again, these are trainings: 20411, or Windows 2012 Server Administration and a second course 20412 that is recommended for those who already have experience with Server 2008 and would like to upgrade their skills to version 2012. Thank you for today's presentation. That's it for today. Until then, and see you at the next webinars..

You May Also Like