DirectAccess in Windows 7. Part 2
In the first part, dedicated to DirectAccess, I began to look at the technological foundation of this solution. Let me remind you that this foundation consists of: IPv6, IPsec over IPv6, Name Resolution Policy Table (NRPT) table. We discussed the reasons why DirectAccess uses IPv6 as the underlying protocol. Does this mean that now, in an era of apparent IPv4 dominance, including on the Russian Internet, using DirectAccess is impossible? Not. With transit technologies, DirectAccess feels great in an IPv4 environment.
IPv6 transit technology
With DirectAccess, IPv6 information is transferred from a DA client on the Internet through a DA server in the perimeter zone to a server (or client) on the corporate network. That is, it is assumed that all three participants of this information channel support IPv6. For the DA client and the DA server, IPv6 support is strictly required. Consequently, transit technologies can help in three situations:
- when the Internet segments between the DA client and the DA server do not support IPv6;
- when the corporate network segments between the DA server and the destination server to which the traffic is intended do not support IPv6;
- when the destination server itself does not support IPv6.
Consider all three cases in the listed order.
')
Transit between the DA client and the DA server
Once the DA client is on the Internet, he tries to establish an IPsec over IPv6 tunnel with a DA server. How such a tunnel is built depends directly on what kind of IP configuration the client receives from the ISP. In the ideal and, accordingly, the least likely case, the DA client receives an IPv6 address. That is, the DA client was lucky to be on the IPv6 Internet, its packets are simply routed to the DA server.
A more realistic option is that the DA client receives a public IPv4 address from the provider. In this case, the client will use 6to4 transit technology (RFC 3056). Thanks to this technology, an IPv6-address of the type 2002: WWXX: YYZZ :: / 48, starting from 2002, is formed on the client (the prefix 2002 just indicates that 6to4 transit technology is taking place) and contains a public IPv4-address in the WWXX: YYZZ fields (see fig. 1):
Fig. one
The IPv6 packet generated in this way is now packaged in an IPv4 packet and routed over the IPv4 Internet.
A more realistic option is that the DA client receives a private IPv4 address from the provider, for example, 192.168.200.111. In this case, another transit technology is used - Teredo (RFC 4380). The task of Teredo is to ensure the passage of the original IPv6 packet not only through the IPv4 environment, but also through NAT. In this regard, the principle of operation of Teredo is somewhat more complicated than 6to4, and the structure of the formed IPv6 address is:
Fig. 2
All Teredo addresses begin with the prefix 2001, and the Obscured External Port and Obscured External Address fields contain the external UDP port and external IP address used by NAT, respectively. I will only clarify what is contained not in an explicit form, but as the result of an XOR operation with a predetermined number. The formed packet is packed into a UDP packet, which, in turn, is packed into an IPv4 packet. Now everything is ready to send information through NAT. In more detail with the transit technologies 6to4 and Teredo, as well as the ISATAP technology mentioned later, you can get acquainted, for example, here .
There is another quite possible option, when a DA-client receives a certain IPv4-address from the provider, but at the same time, communication with the outside world is allowed only on 80 and 443 TCP ports. In this case, a protocol that is no longer an RFC standard and which is supported only in Windows 7 and Windows Server 2008 R2 will help. The protocol is called IP-HTTPS and, as the name implies, enables the transmission of IPv6 packets using HTTPS over IPv4. I emphasize that this protocol will be activated only if the use of the above transit technologies was unsuccessful.
Finally, if only port 80 is allowed, then a surprise surprise, DirectAccess will not work, and access to corporate resources from the outside will be impossible. Who would have thought. :)
Transit between DA-server and destination server
OK, the IPv6 packets reached the DA server. In accordance with its own settings, the DA server forwards the IPv6 packets further to the corporate network to the destination server, either with or without encryption. And here the question is, does your organization’s network environment support IPv6? More specifically, do active communication equipment, especially routers, know how to work with IPv6?
Consider a situation where the destination server supports IPv6, and the communication equipment does not. Then another transit technology comes to the rescue - ISATAP (Intra-Site Automatic Tunnel Addressing Protocol, RFC 4214). When using ISATAP, it is assumed that the host has at least one IPv4 address assigned in any manner accepted by the organization. Otherwise, how the host generally interacts with other machines on the network. Then the host's IPv6 address is generated automatically, with the last 32-bits of its IPv6 address corresponding to its IPv4 address. For example, if two hosts from different segments start interacting, their addresses may look like this (see Table 1):
Field Value
IPv6 Source Address FE80 :: 5EFE: 10.40.1.29
IPv6 Destination Address FE80 :: 5EFE: 192.168.41.30
IPv4 Source Address 10.40.1.29
IPv4 Destination Address 192.168.41.30
Table 1
Therefore, when a DA server needs to send an IPv6 packet through an IPv4 router, the DA server uses DNS to determine the recipient's IPv4 address, builds an ISATAP type IPv6 packet based on this information, packages it into a normal IPv4 packet and forwards it to the recipient. The latter unpacks the information in the reverse order and receives the original IPv6 packet, from the header of which it is clear that the packet is really intended for this host and can be subjected to further processing.
NAT-PT
The last option that needs to be noted is the option when the destination server in principle cannot work with IPv6. By the way, I note that if we talk about Windows, then support for IPv6 in the operating systems of the family is implemented starting with Windows XP., Well, for example, Windows 2000? I really want to get access to such machines from outside using DirectAccess. In this case, a device supporting the NAT-PT specification (RFC 2766) is required. NAT-PT is responsible for translating IPv6 addresses to IPv4 addresses, thereby allowing DA clients in our case to access IPv4-only hosts. NAT-PT is not supported in either Windows 7 or Windows Server 2008 R2. However, support for this mechanism is implemented in the Forefront Unified Access Gateway (UAG) product. Being installed on Windows Server 2008 R2 and configured as a DA server, UAG offers some advanced DirectAccess features, including NAT-PT. A UAG review is beyond the scope of this discussion. Well, in addition, the implementation of NAT-PT can be found in other products, including non-Microsoft.
Summing up the transit theme, it is important to note that from the administrator, and even more so from the user, there is no need for special separate configuration of all these technologies. All that is needed to ensure transit is configured by the wizard when setting up the DA-server. On DA clients, 6to4, Teredo, IP-HTTPS, ISATAP support is enabled automatically and is used when necessary.
IPsec over IPv6
IPsec is the foundation for protecting traffic between participants in a DirectAccess solution. For IP protocol of the fourth version, the IPsec specification appeared much later than the IP protocol itself. This, in particular, has led to the emergence of various implementations of IPsec over IPv4, sometimes not fully compatible with each other. IPsec for IPv6 was designed simultaneously with the new IP protocol. Support for IPsec headers is a requirement for implementing an IPv6 stack. This creates the prerequisites for maximum compatibility of solutions from different suppliers. On the other hand, this does not mean that when using IPv6 you must use IPsec. But in the case of DirectAccess based on IPv6, the use of IPsec is the most logical way to protect the transmitted traffic.
As with the fourth version of IPsec for IPv6, there are two security options: Authentication header (AH) and Encapsulating Security Payload (ESP). In the first version, each package is, in fact, signed with a digital signature, which ensures the authentication of the data, guaranteeing their integrity during transmission. However, the packet data is transmitted in clear text without encryption. In the second variant, plus to the whole, the packet data is also encrypted, which ensures the confidentiality of the transmitted information. Combinations of these options determine the so-called access model when deploying DirectAccess.
The first model is called Full Intranet Access (End-to-Edge). In this model, encrypted traffic is transmitted over IPsec from the DA client to the DA server. The DA server decrypts the traffic and forwards the packets to the internal network in the open form. In practice, this means that by reaching the DA-server, the DA-client further potentially gets access to the entire internal network. Most often, this logic is used in VPN solutions.
In the Selected Server Access (Modified End-to-Edge) model, traffic is still encrypted only up to the DA server. And on the internal network, only authentication (AH) is used. This approach allows only certain DA clients to access certain servers and applications on the corporate network (see Figure 3).
Fig. 3
It should be borne in mind that the OS to Vista IPsec over IPv6 is not fully implemented, therefore, in the figure, the servers that the DA client can reach through this model are labeled as Windows Server 2008 or later.
Finally, in the End-to-End model (Figure 4), packets are encrypted on the DA client and decrypted already on the destination server. DA-server just passes through this traffic.
Fig. four
This approach provides the highest level of protection.
In the end, specific IPsec settings are set in group policies, which can always be changed. Thus, by manipulating the IPsec settings, you can apply the hybrid models that best suit your particular situation. This is the added flexibility of the DirectAccess solution.
Name Resolution Policy Table
The latest technological foundation of DirectAccess is the Name Resolution Policy Table (NRPT), or rather the way to resolve names using this table and the DNS system. When a DA client is on the Internet, it must understand which names are internal, and, accordingly, must be resolved by the corporate DNS server, and which ones by external ones, which must be resolved by DNS servers on the Internet.
So the NRPT table allows you to specify a DNS server not for the network interface, but for a certain namespace. Each time, while outside the corporate network, when resolving a name, for example srv1.contoso.com, the DA client first checks if there is a line for the given name or part of it in the NRPT. If it does, the client contacts the DNS server specified in the corresponding NRPT line for the given namespace for resolving this name (see Figure 5). If not, then the call occurs in the DNS server specified in the network interface settings, that is, to the DNS provider.
Fig. five
In addition, there are so-called exemption-policies. The names specified in these policies are always resolved only by external Internet DNS servers.
However, it is important to emphasize once again that such a “non-standard” version of name resolution using NRPT is applied only when the DA client “understands” that it is on the Internet, outside. If it is in the internal grid, why make such a garden. Therefore, there is an algorithm for determining the location of the DA client. This algorithm, as well as infrastructure requirements and settings for the DA server itself, will be discussed in the third final post on DirectAccess.
IPv6 transit technology
With DirectAccess, IPv6 information is transferred from a DA client on the Internet through a DA server in the perimeter zone to a server (or client) on the corporate network. That is, it is assumed that all three participants of this information channel support IPv6. For the DA client and the DA server, IPv6 support is strictly required. Consequently, transit technologies can help in three situations:
- when the Internet segments between the DA client and the DA server do not support IPv6;
- when the corporate network segments between the DA server and the destination server to which the traffic is intended do not support IPv6;
- when the destination server itself does not support IPv6.
Consider all three cases in the listed order.
')
Transit between the DA client and the DA server
Once the DA client is on the Internet, he tries to establish an IPsec over IPv6 tunnel with a DA server. How such a tunnel is built depends directly on what kind of IP configuration the client receives from the ISP. In the ideal and, accordingly, the least likely case, the DA client receives an IPv6 address. That is, the DA client was lucky to be on the IPv6 Internet, its packets are simply routed to the DA server.
A more realistic option is that the DA client receives a public IPv4 address from the provider. In this case, the client will use 6to4 transit technology (RFC 3056). Thanks to this technology, an IPv6-address of the type 2002: WWXX: YYZZ :: / 48, starting from 2002, is formed on the client (the prefix 2002 just indicates that 6to4 transit technology is taking place) and contains a public IPv4-address in the WWXX: YYZZ fields (see fig. 1):
Fig. one
The IPv6 packet generated in this way is now packaged in an IPv4 packet and routed over the IPv4 Internet.
A more realistic option is that the DA client receives a private IPv4 address from the provider, for example, 192.168.200.111. In this case, another transit technology is used - Teredo (RFC 4380). The task of Teredo is to ensure the passage of the original IPv6 packet not only through the IPv4 environment, but also through NAT. In this regard, the principle of operation of Teredo is somewhat more complicated than 6to4, and the structure of the formed IPv6 address is:
Fig. 2
All Teredo addresses begin with the prefix 2001, and the Obscured External Port and Obscured External Address fields contain the external UDP port and external IP address used by NAT, respectively. I will only clarify what is contained not in an explicit form, but as the result of an XOR operation with a predetermined number. The formed packet is packed into a UDP packet, which, in turn, is packed into an IPv4 packet. Now everything is ready to send information through NAT. In more detail with the transit technologies 6to4 and Teredo, as well as the ISATAP technology mentioned later, you can get acquainted, for example, here .
There is another quite possible option, when a DA-client receives a certain IPv4-address from the provider, but at the same time, communication with the outside world is allowed only on 80 and 443 TCP ports. In this case, a protocol that is no longer an RFC standard and which is supported only in Windows 7 and Windows Server 2008 R2 will help. The protocol is called IP-HTTPS and, as the name implies, enables the transmission of IPv6 packets using HTTPS over IPv4. I emphasize that this protocol will be activated only if the use of the above transit technologies was unsuccessful.
Finally, if only port 80 is allowed, then a surprise surprise, DirectAccess will not work, and access to corporate resources from the outside will be impossible. Who would have thought. :)
Transit between DA-server and destination server
OK, the IPv6 packets reached the DA server. In accordance with its own settings, the DA server forwards the IPv6 packets further to the corporate network to the destination server, either with or without encryption. And here the question is, does your organization’s network environment support IPv6? More specifically, do active communication equipment, especially routers, know how to work with IPv6?
Consider a situation where the destination server supports IPv6, and the communication equipment does not. Then another transit technology comes to the rescue - ISATAP (Intra-Site Automatic Tunnel Addressing Protocol, RFC 4214). When using ISATAP, it is assumed that the host has at least one IPv4 address assigned in any manner accepted by the organization. Otherwise, how the host generally interacts with other machines on the network. Then the host's IPv6 address is generated automatically, with the last 32-bits of its IPv6 address corresponding to its IPv4 address. For example, if two hosts from different segments start interacting, their addresses may look like this (see Table 1):
Field Value
IPv6 Source Address FE80 :: 5EFE: 10.40.1.29
IPv6 Destination Address FE80 :: 5EFE: 192.168.41.30
IPv4 Source Address 10.40.1.29
IPv4 Destination Address 192.168.41.30
Table 1
Therefore, when a DA server needs to send an IPv6 packet through an IPv4 router, the DA server uses DNS to determine the recipient's IPv4 address, builds an ISATAP type IPv6 packet based on this information, packages it into a normal IPv4 packet and forwards it to the recipient. The latter unpacks the information in the reverse order and receives the original IPv6 packet, from the header of which it is clear that the packet is really intended for this host and can be subjected to further processing.
NAT-PT
The last option that needs to be noted is the option when the destination server in principle cannot work with IPv6. By the way, I note that if we talk about Windows, then support for IPv6 in the operating systems of the family is implemented starting with Windows XP., Well, for example, Windows 2000? I really want to get access to such machines from outside using DirectAccess. In this case, a device supporting the NAT-PT specification (RFC 2766) is required. NAT-PT is responsible for translating IPv6 addresses to IPv4 addresses, thereby allowing DA clients in our case to access IPv4-only hosts. NAT-PT is not supported in either Windows 7 or Windows Server 2008 R2. However, support for this mechanism is implemented in the Forefront Unified Access Gateway (UAG) product. Being installed on Windows Server 2008 R2 and configured as a DA server, UAG offers some advanced DirectAccess features, including NAT-PT. A UAG review is beyond the scope of this discussion. Well, in addition, the implementation of NAT-PT can be found in other products, including non-Microsoft.
Summing up the transit theme, it is important to note that from the administrator, and even more so from the user, there is no need for special separate configuration of all these technologies. All that is needed to ensure transit is configured by the wizard when setting up the DA-server. On DA clients, 6to4, Teredo, IP-HTTPS, ISATAP support is enabled automatically and is used when necessary.
IPsec over IPv6
IPsec is the foundation for protecting traffic between participants in a DirectAccess solution. For IP protocol of the fourth version, the IPsec specification appeared much later than the IP protocol itself. This, in particular, has led to the emergence of various implementations of IPsec over IPv4, sometimes not fully compatible with each other. IPsec for IPv6 was designed simultaneously with the new IP protocol. Support for IPsec headers is a requirement for implementing an IPv6 stack. This creates the prerequisites for maximum compatibility of solutions from different suppliers. On the other hand, this does not mean that when using IPv6 you must use IPsec. But in the case of DirectAccess based on IPv6, the use of IPsec is the most logical way to protect the transmitted traffic.
As with the fourth version of IPsec for IPv6, there are two security options: Authentication header (AH) and Encapsulating Security Payload (ESP). In the first version, each package is, in fact, signed with a digital signature, which ensures the authentication of the data, guaranteeing their integrity during transmission. However, the packet data is transmitted in clear text without encryption. In the second variant, plus to the whole, the packet data is also encrypted, which ensures the confidentiality of the transmitted information. Combinations of these options determine the so-called access model when deploying DirectAccess.
The first model is called Full Intranet Access (End-to-Edge). In this model, encrypted traffic is transmitted over IPsec from the DA client to the DA server. The DA server decrypts the traffic and forwards the packets to the internal network in the open form. In practice, this means that by reaching the DA-server, the DA-client further potentially gets access to the entire internal network. Most often, this logic is used in VPN solutions.
In the Selected Server Access (Modified End-to-Edge) model, traffic is still encrypted only up to the DA server. And on the internal network, only authentication (AH) is used. This approach allows only certain DA clients to access certain servers and applications on the corporate network (see Figure 3).
Fig. 3
It should be borne in mind that the OS to Vista IPsec over IPv6 is not fully implemented, therefore, in the figure, the servers that the DA client can reach through this model are labeled as Windows Server 2008 or later.
Finally, in the End-to-End model (Figure 4), packets are encrypted on the DA client and decrypted already on the destination server. DA-server just passes through this traffic.
Fig. four
This approach provides the highest level of protection.
In the end, specific IPsec settings are set in group policies, which can always be changed. Thus, by manipulating the IPsec settings, you can apply the hybrid models that best suit your particular situation. This is the added flexibility of the DirectAccess solution.
Name Resolution Policy Table
The latest technological foundation of DirectAccess is the Name Resolution Policy Table (NRPT), or rather the way to resolve names using this table and the DNS system. When a DA client is on the Internet, it must understand which names are internal, and, accordingly, must be resolved by the corporate DNS server, and which ones by external ones, which must be resolved by DNS servers on the Internet.
So the NRPT table allows you to specify a DNS server not for the network interface, but for a certain namespace. Each time, while outside the corporate network, when resolving a name, for example srv1.contoso.com, the DA client first checks if there is a line for the given name or part of it in the NRPT. If it does, the client contacts the DNS server specified in the corresponding NRPT line for the given namespace for resolving this name (see Figure 5). If not, then the call occurs in the DNS server specified in the network interface settings, that is, to the DNS provider.
Fig. five
In addition, there are so-called exemption-policies. The names specified in these policies are always resolved only by external Internet DNS servers.
However, it is important to emphasize once again that such a “non-standard” version of name resolution using NRPT is applied only when the DA client “understands” that it is on the Internet, outside. If it is in the internal grid, why make such a garden. Therefore, there is an algorithm for determining the location of the DA client. This algorithm, as well as infrastructure requirements and settings for the DA server itself, will be discussed in the third final post on DirectAccess.
Source: https://habr.com/ru/post/109963/
All Articles