I spent quite a while experimenting with L2TP over IPsec with my iPad 2, and surprisingly found no useful guides as to how to configure it. Judging by what I could find online, most people simply give up and use PPTP instead which has significant security vulnerabilities. Here’s a concise comparison of PPTP versus L2TP/IPsec which describes that weakness:
I had considered using Apple’s support for Cisco IPsec but that would have meant exposing the core switch where I work. It’s old enough to make that a bad idea. The Juniper Netscreen firewall only supports L2TP with certificates and not Pre-Shared Key so that was also ruled out. This post will outline how to configure Windows Server 2008 R2’s NPS/RRAS role to host L2TP/IPsec connections which will allow iPads and iPhones to connect securely into your Windows infrastructure without the need for additional client software.
Firstly, it’s likely that your NPS/RRAS server is behind a perimeter firewall. If this is the case you’ll need to grant IPsec traffic access from the public internet. Using details from this Technet post I created the following custom service object on the Netscreen firewall, and allowed it inbound to the RRAS server (IP protocols 50 and 51, UDP 500 and 4500). For initial testing though you should probably create a rule to allow all traffic to and from your test client.
I am going to assume a knowledge of both NPS and RRAS. For more information on those, other guides exist. As far as I have been able to discover, it seems that the iPad only supports Pre-Shared Key authentication for the IPsec tunnel, rather than certificates-based. The VPN connection settings GUI in Mac OS 10.6 for instance will allow either method, but not in iOS. It may be possible to force your way around this with the iPhone Configuration Utility (designed for applying corporate settings to iOS) but information is pretty scant. I did find a long forum thread about certificate auto-enrollment, and a Microsoft Directory Services team blog post, but I suspect they may relate more to 802.1x:
The L2TP/IPsec Pre-Shared Key is configured by right-clicking on the top level of Routing and Remote Access in Server Manager -> Properties -> Security tab:
It’s useful to keep your VPN clients on a different subnet to your servers, however multihoming with several NICs can cause problems, particularly if your RRAS server is also a Domain Controller. You can define a subnet for this purpose in the IPv4 tab here, but you will need to remember to add a static route entry on your router pointing traffic for this subnet to the RRAS server.
In Server Manager -> NPS -> Policies -> Network Policies create a policy with the following settings, making sure to set the encryption settings. As this Microsoft KB article makes clear, these options actually ensure that IPsec gets used, with the different grades here representing different algorithm proposal combinations. The iPad supports the maximum encryption setting.
Lastly, the Mac OS X and iOS VPN client configuration is pretty self-explanatory. Make sure to use the Pre-Shared Key that you defined on the RRAS server (referred to here as Secret):
I would at this point like to thoroughly recommend iTap RDP as being the best iOS Remote Desktop client I have seen. It has NLA authentication support, a universal iPad/iPhone binary, and by far the most intuitive controls which really puts it ahead of the competition.
UPDATE – I was hoping to use this VPN configuration for all clients, but it seems that Mac OS clients cannot connect. Mac OS apparently didn’t use the standard L2TP UDP port 1701. Someone compiled a fix for Snow Leopard but I could not get it to work. It’s possible that this is all out of date information though.
UPDATE 2 – I did some more troubleshooting from home and discovered that when a tunnel is initiated from a second device on my home network while another tunnel is already up, all further connection attempts then fail for a long while, even when the RRAS server is rebooted. This would suggest that the Netscreen firewall at my work still considers the original session open, and thus it will eventually timeout after 30 minutes. This behaviour had disrupted my Mac OS X test results. Using verbose logging on the Mac and looking at the NPS log I could see that Mac OS X 10.6.8 VPN client does not accept the 128bit encryption setting. Permitting 56bit encryption allows Macs to connect, but perhaps older versions of Mac OS could have difficulties. I have updated the policy settings screenshot above.
UPDATE 3 – I realised that although NATed clients could connect, clients with public addresses could not. I have amended the destination ports for IP protocols 50 and 51 in the firewall IPsec definition screenshot (it had defaulted to 0-0 rather than 0-65535 for some reason). I have verified that this VPN works for Windows XP clients, Windows 7, Mac OS X 10.6, and Mac OS X 10.5, as well as iPhones (mine’s on iOS 3.1.3) and iPads. Once connected to the RRAS server you cannot interact with that server directly, so make sure that the RRAS server’s own DNS settings do not refer to itself as a primary (assuming it’s also a DNS server) – these DNS entries will be inherited by all VPN clients.