A blog entry on the RRAS team’s blog announced the new Agile VPN feature from Windows 7, http://blogs.technet.com/rrasblog/archive/2008/12/09/ras-features-in-w7.aspx
Cool, very cool. These are the first impressions. I’ve been playing with it for a while.
To summarize, although there is little information for the moment about the Agile VPN feature from Microsoft, I can say from what I’ve seen: IKEv2, MOBIKE and IPsec ESP Tunnel Mode, no IPComp currently, multiple EAP-IKEv2 authentication methods along with the “classic” machine certificates authentication one.
IKEv2 – an "Internet Official Protocol Standards" (STD 1) described in RFC4306 Internet Key Exchange (IKEv2) Protocol. IKEv2 is built on IPsec architecture RFC4301. IKEv2 is used to mutually authenticate two hosts, to establish IPsec Security Associations (SAs) between them and to manage(maintain) these SAs(to delete or to rekey them).
MOBIKE - an "Internet Official Protocol Standards" (STD 1) described in RFC4555 IKEv2 Mobility and Multihoming Protocol (MOBIKE). RFC4555 defines MOBIKE as:
“MOBIKE protocol, a mobility and multihoming extension to Internet Key Exchange (IKEv2). MOBIKE allows the IP addresses associated with IKEv2 and tunnel mode IPsec Security Associations to change. A mobile Virtual Private Network (VPN) client could use MOBIKE to keep the connection with the VPN gateway active while moving from one address to another. Similarly, a multihomed host could use MOBIKE to move the traffic to a different interface if, for instance, the one currently being used stops working.”
The motivation for MOBIKE, from RFC4555, is:
“The main scenario for MOBIKE is enabling a remote access VPN user to move from one address to another without re-establishing all security associations with the VPN gateway. For instance, a user could start from fixed Ethernet in the office and then disconnect the laptop and move to the office's wireless LAN. When the user leaves the office, the laptop could start using General Packet Radio Service (GPRS); when the user arrives home, the laptop could switch to the home wireless LAN. MOBIKE updates only the outer (tunnel header) addresses of IPsec SAs, and the addresses and other traffic selectors used inside the tunnel stay unchanged. Thus, mobility can be (mostly) invisible to applications and their connections using the VPN.
MOBIKE also supports more complex scenarios where the VPN gateway also has several network interfaces: these interfaces could be connected to different networks or ISPs, they may be a mix of IPv4 and IPv6 addresses, and the addresses may change over time. Furthermore, both parties could be VPN gateways relaying traffic for other parties.”
There is an informational RFC, RFC4621, called Design of the IKEv2 Mobility and Multihoming (MOBIKE) Protocol, if you want to find out more technical details about MOBIKE.
All these mean that the user can move from one network to another, or if the current interface which provides Internet access goes down and the user uses another interface for Internet connectivity, the VPN connection will not be disconnected, thus this user will not be prompted to manually re-establish it and to enter his or her credentials, simply the VPN connection will update automatically its local tunnel IP address and the VPN traffic will be sent through the new interface. Pretty cool, as the roaming user is provided with effortless continuous connectivity. Read more about the Mobility Manager from Windows 7 and some real world targeted scenarios along with the current limitations of it in this blog entry from the RRAS team: The Mobility Manager - managing mobility for VPN reconnect connections (IKEv2 based VPN connections).
IPsec ESP Tunnel Mode - IP Encapsulating Security Payload (ESP) is described in RFC4303, an "Internet Official Protocol Standards" (STD 1). The current design of MOBIKE(RFC4555, Section 1.1) focuses on tunnel mode IPsec SAs. ESP provides confidentiality and integrity for our data.
Since tunnel mode is used, basically we have IP-in-IP tunneling. As a comparison, with L2TP/IPsec, the tunnel is provided by L2TP(a mean to carry PPP traffic, our data(the original IP packet) is encapsulated in PPP).
This would imply less overhead for the Agile VPN compared to L2TP/IPsec, see the bellow pictures showing a ping packet over an Agile VPN connection, respectively a ping packet over an L2TP/IPsec connection, for both ESP confidentiality was set to NULL. This overhead of L2TP/IPsec made some people unhappy in the past.
The DHCP INFORM packet is still sent by the VPN client, and I was able to pull some DHCP Options from the DHCP server.
Playing with MOBIKE in a Virtual Lab
I have built a virtual lab in VMware ESXi 3.5U3, so I can be “agile” without moving from my chair(although I’ve experimented some issues with my virtual lab, as I’m on an experimental/unsupported scenario for the moment, that is Windows 7 beta in VMware ESXi). On the Windows 7 beta client VM, I’ve configured two NICs:
- one NIC is directly connected to the VPN server(through the same virtual switch, virtual switch which is connected to a real physical network), and the IP settings for this NIC are obtained from a real DHCP server
- the other NIC is connected to a virtual Vyatta router acting as a NAT device(through a virtual switch). The VPN server can be reached through this NIC through the virtual NAT/Router Vyatta. On this NIC I’ve manually configured the IP settings.
The routing table on the Windows 7 beta VM look like bellow. As you can see there is a persistent route, since I’ve manually configured the default gateway on the second NIC on the Windows 7 Beta VM, however the active DG is the one from the first NIC.
The NICs’ configuration:
I’ve established the Agile VPN connection named IKEv2(the Use default gateway on remote network option was checked on this connection), and as you can see the VPN traffic goes through the first NIC of my Windows 7 VM(the Network Adapter Used), the one directly connected through the virtual switch to the VPN server. Note the Origin address too. I’ve initiated a continuous ping command to a server 192.168.10.2 behind the VPN server. Notice that MOBIKE is supported, for this I’ve checked the Mobility checkbox from the Advanced settings for IKEv2, see bellow.
My routing table after the VPN connection was established looks like bellow:
The new VAN UI (View Available Networks UI) in W7 is quite useful, and shows the networks to which I am connected, see the bellow figure. Read more about it on RRAS Team’s blog at http://blogs.technet.com/rrasblog/archive/2009/01/07/van-ui-view-available-networks-ui-in-w7.aspx.
Then, as shown in the figure with the Windows 7 VM’s settings from above, I’ve unchecked the Connected checkbox for the Network Adapter 1(alternatively I could try to disable and enable from Windows the NICs, but doing that my Windows 7 VM kept crashing(freezing)). And looking at IKEv2’s connection status I can observe that now the VPN traffic is sent through the second NIC(the Network Adapter Used) and the Origin address was updated. And yes I’m still connected, without any input from me. Actually the entire process may go simply unnoticed for me as an end user, all I would know is that I’m continuously connected to my corpnet.
The routing table looks now like:
I’ve played like so unchecking and checking the Connected checkboxes on the virtual NICs in VM’s settings. Sometimes a ping packet was lost, and sometimes not even a single ping packet was lost.
I’ve started a Wireshark capture on the VPN server’s external interface, and bellow we can notice the switch when I’ve disconnected the first NIC on the VPN client’s VM and the IP address of the tunnel was updated due to MOBIKE. Note that the VPN traffic goes through a NAT device(Vyatta VM).
If I uncheck the Connected checkboxes on the both the virtual NICs in VM’s settings, the IKEv2 connection goes in Dormant mode.
If I check the Connected checkbox on one of the virtual NICs in VM’s settings, the connection quickly goes into the Dormant:Waiting to reconnect state, and then very fast goes into the Connected state.
However, if within the specified Network outage time or so I don’t enable back one of the NICs of the Windows 7 VM, I get a message saying that the Link to IKEv2 failed. The default timer is set to 30 minutes.
It would have been useful if the Mobile Manager would “bring back” automatically the VPN traffic through the “preferred” interface, that is, for example in the case of the two NICs, if the VPN traffic is sent through the second NIC because the first NIC is down, in case the first NIC comes up, the VPN traffic to be switched over this NIC, as through this NIC there is a “more direct” path to the VPN server. Simply put, to be able to select a preferred physical interface for the source of the VPN traffic, or to order the preferred physical interfaces(in case there are more of them).
Authentication Methods
For the moment I saw EAP based authentication methods and machine certificates authentication for the Agile VPN.
Note that the EAP IKEv2 authentications happen during IKEv2 negotiations, and are protected(traffic is encrypted and authenticated) by IKEv2. Don't confuse them with the EAP ones from L2TP/IPsec, as those ones happened during PPP authentication, PPP authentication protected by IPsec ESP, when IKEv1 negotiations were completed(IKEv1 authentication completed during IKE Main Mode) and IPsec SAs established(through IKE Quick Mode) to protect the L2TP tunnel(the L2TP tunnel transports the PPP traffic).
Currently I’ve noticed:
- EAP-MSCHAPv2: mutual authentication based on user name and user’s password. Theoretically this method does not require a certificate on the server, as the client does not inspect server’s certificate, however I could not establish an Agile VPN connection until I’ve added a certificate on the VPN server, within the Computer Certificate Store, otherwise I would get the error from the bellow printscreen, a thing that puzzled me a little bit.
- PEAP-EAP-MSCHAPv2: A certificate is configured on the server(the NPS server), and during the authentication phase, a TLS encrypted tunnel is established, the VPN client being specifically instructed to verify server’s certificate. If this certificate is valid, MSCHAPv2 is run over the TLS tunnel, user’s credentials being checked by the server. This may be a convenient authentication method, as it requires a certificate only on server’s side. See Microsoft’s doc Certificate requirements when you use EAP-TLS or PEAP with EAP-TLS, which talks about PEAP-EAP-MSCHAPv2 too.
- PEAP-EAP-TLS: a strong authentication method, where the user uses as user credentials a user certificate. This certificate can be stored on the local machine within the User Certificates Store, or on a smart-card providing dual-factor authentication. A certificate is also configured on the server(NPS server). See Microsoft’s doc PEAP Overviewand Microsoft’s doc Certificate requirements when you use EAP-TLS or PEAP with EAP-TLS. I haven’t tested it yet with IKEv2.
- EAP-TLS: similar with PEAP-EAP-TLS. With EAP-TLS, some “authentication portions” are unencrypted compared with PEAP-EAP-TLS. See Microsoft’s doc EAP Overview and Microsoft’s doc Certificate requirements when you use EAP-TLS or PEAP with EAP-TLS. I haven’t tested it yet with IKEv2.
- Machine certificates: uses “machine” certificates. From what I’ve seen, the certificates need to be stored within the Computer Certificate Store on the VPN client and on the VPN server. For the moment I’ve not noticed an option to manually configure some checks over the server’s certificate on the VPN client, actually I’ve established an Agile VPN connection using the same certificate on the client and on the server. It would be desired(at least from my point of view) that the VPN clients to be configured to accept server’s certificate only if it was issued by a specific CA and to check certain fields from the server’s certificate like the CN, while the server to accept VPN clients’ certificates only if they were issued by a specific CA and the VPN server to be able to inspect too some fields from the VPN clients’ certificates, like the OU, to make sure that those certificates were indeed issued for IKEv2 authentication purposes.
CMAK and IKEv2
The CMAK from the current Windows Server 2008 R2 beta already includes support for IKEv2 and MOBIKE, see the bellow pictures.
Possible Confusing Things
As with this current beta version of Windows 7, there are a few things that might confuse some folks.
If we issue an ipconfig /all command on the Windows 7 beta desktop, the VPN virtual interface is “labeled” as PPP adapter, which may confuse some people, as there is no PPP traffic, we saw from above that IP-in-IP tunneling is used.
The Security logs from the Event Viewer show for an Agile VPN connection that IPsec Main Mode and IPsec Quick Mode SAs were established. However, with IKEv2, within RFC4306, the IPsec Main Mode SA would be called IKE_SA, and the IPsec Quick Mode SA named CHILD_SA.
An “Oakley.log” like for IKEv2
Since this is a new technology, an Oakley.log like for IKEv2 would be very cool. I have found that IKEv2 info gets stored with the ikeext.etl file. However the method described here to get that file in a human-readable format didn’t work for me, as there is no trace message format file(wfp.tmf) within Win7 beta x32, Win7 beta x64 or within Windows 2008 R2 beta. If I’ve “used” such a file from a “normal” Windows, I ended up with a lot of "No Format Information found" messages. For the moment I haven’t figure it out this aspect. Still, I was able to find some useful info about IKEv2 negotiations from the ikeext.etl file, see the bellow figure.
If you want to compare Microsoft’s IKEv2 and MOBIKE implementations with other implementation, you can take a look at strongSwan:
- http://www.strongswan.org/uml/testresults42/ikev2/index.html
- http://wiki.strongswan.org/wiki/MobIke