Server requirements and placement
The URA server role poses very few requirements, technically. To be compatible with the operating system itself, you need a 64-bit CPU running at 1.4 GHz or faster and at least 512 MB of memory. 32 GB of disk space are also required, and if your server meets this, you're off to a solid start. It's kind of a "duh", but we'll say it anyway; you need a network card. Beyond that, keep in mind that the server is going to have to do a lot of work accepting connections, encrypting and decrypting traffic, dealing with authentication, and more. Unless this is just a trial-run or lab environment, don't skimp on the hardware. It's not easy calculating the capacity requirements of URA, but in the following sections you can find some more information about capacity planning.
Something that may be of far bigger importance is the placement of the server. We already said you need a network card, and you need to make sure traffic from the Internet can come into the server. You also need to allow traffic from the server to the internal network. Most organizations will prefer to put the server inside their DMZ, with some kind of firewall in front of it. An extra firewall is not a requirement, because Windows Server 2012 contains an enterprise-class firewall that has proven itself well since its introduction in Windows Server 2008. If, however, you place the URA server behind additional firewalls or routers, make sure that the appropriate ports and protocols are not filtered. The URA server needs you to provision access to the following:
- Protocol 41
- UDP port 3544
- TCP port 443
- ICMPv6 Echo
Each of these needs bi-directional access. Protocol 41 is required for the 6to4 client connections, UDP 3544 is required for Teredo client access, and TCP 443 is required for IP-HTTPS client access. The ICMPv6 Echo traffic is used by the system to test and qualify the network connections. If you are exceptionally apprehensive about incoming traffic, URA can still function without the first two, which would force all clients to connect by using IP-HTTPS.
As for traffic coming from the URA server into your network, it's really simple—you should allow any and all traffic in both directions. We treat URA connected clients as being part of the internal network, and so you need them and their applications to have access to any resources that they would normally have access to while inside the office. Allowing all traffic gives them the ability to work at full capacity, even while working remotely.
Capacity planning for URA
If you are planning to deploy URA for a large user base, proper capacity planning is of critical importance, allowing you to choose the appropriate hardware to service your intended audience and provide an acceptable service level.
Key facts to keep in mind about capacity planning for this sort of technology are that resource utilization is rarely fixed and client distribution has some random elements to it. This means that in a real-world environment, it's hard to predict how many clients will be using 6to4, how many will use Teredo, and how many will use IP-HTTPS. Also, you might have a large number of concurrent connections, but some users will be idle and send only small amounts of traffic, while others may be moving tons of data around constantly (for example, if they RDP into computers on the internal network). This also means that there's no specific finite number of concurrent users that a certain combination of hardware supports, and that there's no mathematic formula that will tell you exactly what hardware you need for a specific number of users. If you are asking your server to handle a number of users that exceeds its capacity, the server won't turn itself off like an overloaded fusebox, but as it struggles to handle the work, service level will degrade and you might find yourself getting calls from people complaining that their connection takes a long time to establish, or that it takes forever to open sites or documents.
As a general rule, the most important resource for a URA server is network bandwidth. If your server needs to service 1,000 users, and your WAN connection to the Internet is a fourth level T-carrier line running at 274 Mbps (this is in bits, which is equivalent to 34.272 Megabytes per second), it can provide an average transfer rate of only 274 Kbps (34 Kilobyte per second) per user. It's commonly agreed that a transfer rate of less than 500 Kbps is considered to be "slow", though yours or your organization's concept of what is an acceptable speed may vary.
The second important resource is CPU, as the URA server needs to do a lot of math when it encrypts and decrypts the data for the IPsec tunnels, as well as the certificate-related work. The server memory is of lower importance. If your server is hosted as a virtual machine, make sure you plan for Single Root I/O Virtualization (SR-IOV) hardware, as it allows the virtual machine to use all the cores of the host CPU.
Another consideration is the Receive Side Scaling (RSS) configuration of the network card. RSS is a technology that enables packet receive processing to scale with the number of available computer cores. Different network cards support a different number of RSS queues, and if that number is lower than the actual number of CPU cores your server has, the CPU will be under-utilized, and cores are a terrible thing to waste. In such a situation, you can reduce the waste by using more network cards and teaming them together. Windows Server 2012 supports a new teaming feature called Load Balancing and Failover (LBFO). To use this feature, you have to specify the BaseRssProcessor and NumRssProcessors settings for each of the teamed NICs. This can be done in the advanced properties of the adapter in Device Manager. If you have 16 available cores and are teaming two adapters, one would use eight cores starting at CPU 0 and the other would use another eight cores starting at CPU 8. For more information about this and to learn how to configure this with PowerShell, refer to the article available at http://technet.microsoft.com/en-us/library/jj574168.aspx.
Another thing you need to configure to make the best of the network interface card (NIC) teaming is to configure it for switch-dependent teaming mode. This mode depends on the network switch that the NICs are connected to distribute incoming data across all the NICs. To configure this, you can use the LbfoAdmin utility, which is part of the operating system.
You can also use the New-NetLbfoTeam PowerShell cmdlet. For more information about the New-NetLbfoTeam cmdlet , visit http://technet.microsoft.com/en-us/library/jj130847.aspx.
If you are planning to service a large amount of users, you might consider using a load-balanced array. This is something that we recommend whole-heartedly, as it also helps in case of a server crash. In case you plan for using multiple servers, a second server can double your capacity, but keep in mind what we said earlier about network bandwidth, as having more servers doesn't make your network any faster.
Another thing to keep in mind about load balancing is that it obeys the law of diminishing returns—with more servers, the servers have to work harder to keep track of each other, and so at some point, the benefit gained from adding another server may not be worth its cost.
One last thing to keep in mind is that even though URA doesn't use a lot of memory, do keep an eye on it and don't skimp too much. The reason for this being important is that if memory utilization increases, the system might need to do more paging (where chunks of memory are written to the hard drive to free up memory), which can put a load on the CPU itself.
Finally, here are some test results that we have obtained in the test lab. The tests were performed with RSS enabled and with an RSS queue size set to 8. During the tests, test clients were distributed to have 30 percent Teredo clients and 70 percent IP-HTTPS clients.
The server was running a 4 Core Intel Processor from the Westermere family and 4 GB of memory. One set of tests included 750 clients and another 1000 clients, both with a throughput of about 80 to 85 Mbps. With both tests, the CPU usage was around 50 percent and memory utilization was around 25 percent.
Server requirements – considerations
Before proceeding into any further scenarios, here are the things that you should be jotting down as part of your planning:
- Does your intended server meet the memory and CPU requirements of the operating system?
- Does the server have a fast enough CPU to service the targeted number of clients and what is the type of work they will be doing while connected?
- Are you planning on connecting the server with one leg on the Internet and one on the corporate network, or some other topology? If so, do you require any routing configuration or changes to be performed?
- Do the network infrastructure and ISP connection have sufficient bandwidth to support the requirements while providing a reasonable user experience? If you have an existing VPN solution in place, it could help you get an idea about how much traffic is going on.
- Will your organizational security policy allow you to open the required ports? Will it require some kind of change management procedure?
- Will you be using split tunneling or forced tunneling?