The Direct Access connection process... according to Netmon.
The direct access connection process is reasonably straight forward at a high level. When the DA client changes networks it will attempt to contact the Network Location Server (NLS) that you defined while implementing the solution. If the NLS is not available, the DA client assumes it is outside the public network and establishes the IPsec tunnels required for secure communication to the corporate environment. Most of the time it works exceptionally well; but when it breaks there are quite a few moving parts we should be aware of to help troubleshoot the problem. I've attached a network trace of the connection process. The trace is started as the client moves from the corporate network (10.0.0.0/8) to a home network behind a NAT router (192.168.0.0/24). Obviously not all the traffic is going to be Direct Access related so lets try to pick out the important bits.
(It is handy knowing what a 'good' trace looks like so you can compare it to a 'bad' trace when you have an issue. For that reason i have uploaded the trace with this blog so you can use it for comparison. Keep in mind, this is a Windows 8 to Server 2012 trace using the HTTPS transport, i will upload a Windows 7 one and compare the two in the next post).
The first few frames, as expected, aren't really relevant to Direct Access, the are more to do with the client changing networks:
The usual suspects are there: In frame 4 the client starts the DHCP dance for the IPv4 stack, eventually being we see an address in frame 11. In Frame 20 and 21 show the ARP process for the default gateway, where the client is figuring out the layer 2 address. But we would see this is just about any trace where a windows client changes networks - jumping forward to some juicy DA bits:
Actually, before we do - frame 26 is interesting if you ever wondered how a client determines it is on the internet - the NCSI (Network Connectivity Status Indicator) looks for a few resources in a domain called msftncsi.com. There is some detail of how to fake it for yourself on this blog site: https://blogs.msdn.com/b/canberrapfe/archive/2012/10/09/fake-internet-connectivity-for-your-lab-tricking-ncsi.aspxand a much more thorough write up on the process here: https://blogs.technet.com/b/networking/archive/2012/12/20/the-network-connection-status-icon.aspx
Back to the DA:
Step 1 - figure out if we are on the corporate network (because the client noticed it changes network locations):
Frame 82: Attempt to resolve the name of the NLS server that has been defined in the Direct Access group policy (automatically created by the DA wizard in most environments)
Frame: Number = 82, Captured Frame Length = 88, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-10-0C-41],SourceAddress:[00-15-5D-10-0C-3F]
+ Ipv4: Src = 192.168.0.100, Dest = 192.168.0.254, Next Protocol = UDP, Packet ID = 26991, Total IP Length = 74
+ Udp: SrcPort = 51531, DstPort = DNS(53), Length = 54
- Dns: QueryId = 0x4707, QUERY (Standard query), Query for directaccess-nls.contoso.com of type Host Addr on class Internet
QueryIdentifier: 18183 (0x4707)
+ Flags: Query, Opcode - QUERY (Standard query), RD, Rcode - Success
QuestionCount: 1 (0x1)
AnswerCount: 0 (0x0)
NameServerCount: 0 (0x0)
AdditionalCount: 0 (0x0)
- QRecord: directaccess-nls.contoso.com of type Host Addr on class Internet
QuestionName: directaccess-nls.contoso.com
QuestionType: A, IPv4 address, 1(0x1)
QuestionClass: Internet, 1(0x1)
"Please give me the IPv4 address of directaccess-nls.contoso.com..."
Frame 103 is the same question, Frame 153 is the same again... And Frame 175 is the last straw... "can we please have the IPv4 address for directaccess-nls.contoso.com!..."
4 attempts, no response, BOOM.
Direct Access client says "enough is enough" and moves on to step 2 - establish connectivity using Direct Access:
The client queries for the A record (IPv4) of the Direct Access endpoint using the local DNS server (Frame 185).
It is able to obtain the IP address of the DA endpoint (Frame 186), and establish a TCP session (187 - SYN; 188 - SYN.ACK; 189 - ACK).
Then, (Frame 190) the client begins to establish the HTTPS tunnel, this will let us transport the IPv6 packets over the IPv4 internet (the other options here are Teredo, and 6to4 but they are a story for another time).
Also note, that the Win 8 client shows support for NULL encryption for HTTPS which gives the performance improvement over IPHTTPS in Windows 7 clients:
Frame: Number = 190, Captured Frame Length = 146, MediaType = ETHERNET
+ Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-15-5D-10-0C-41],SourceAddress:[00-15-5D-10-0C-3F]
+ Ipv4: Src = 192.168.0.100, Dest = 131.107.0.5, Next Protocol = TCP, Packet ID = 24159, Total IP Length = 132
+ Tcp: [Bad CheckSum]Flags=...AP..., SrcPort=58449, DstPort=HTTPS(443), PayloadLen=92, Seq=2257090546 - 2257090638, Ack=273863016, Win=513 (scale factor 0x8) = 131328
TLSSSLData: Transport Layer Security (TLS) Payload Data
- TLS: TLS Rec Layer-1 HandShake: Client Hello.
- TlsRecordLayer: TLS Rec Layer-1 HandShake:
ContentType: HandShake:
+ Version: TLS 1.0
Length: 87 (0x57)
- SSLHandshake: SSL HandShake ClientHello(0x01)
HandShakeType: ClientHello(0x01)
Length: 83 (0x53)
- ClientHello: TLS 1.0
+ Version: TLS 1.0
+ RandomBytes:
SessionIDLength: 0 (0x0)
CipherSuitesLength: 4
+ TLSCipherSuites: TLS_RSA_WITH_NULL_SHA { 0x00,0x02 }
+ TLSCipherSuites: TLS_RSA_WITH_NULL_MD5 { 0x00,0x01 }
CompressionMethodsLength: 1 (0x1)
CompressionMethods: 0 (0x0)
ExtensionsLength: 38 (0x26)
+ ClientHelloExtension: Renegotiation Info(0xFF01)
+ ClientHelloExtension: Server Name(0x0000)
+ ClientHelloExtension: SessionTicket TLS(0x0023)
After a handful of TLS exchanges in the trace, an interesting thing that happens: we see the NCSI process kick off again (frame 201)... Remember NCSI is how an interface determines that it is connected to the internet. The reason this is interesting is that we haven't physically changed networks. I have to check this with the product group, but i think the reason for this is because we have a new interface coming online when the IPHTTPS tunnel is established.
Remember if you do an IPCONFIG you will see the IPHTTPS connection that has an IPv6 address when it is in use:
And Connected:
So because the IPHTTPS interface is started, we need to check if it is connected to the internet. Once we do that, we also check if that interface is able to connect to the NLS server (the server that tells us we are connected to the corporate environment).
Once we determine that we are not, we continue the connection using Direct Access.
In frame 226, we capture the first of the IPv6 frames (remember, DA is an IPv6 technology):
Frame: Number = 226, Captured Frame Length = 100, MediaType = Tunneling Interfaces
- IPv6: Next Protocol = UDP, Payload Length = 60
+ Versions: IPv6, Internet Protocol, DSCP 0
PayloadLength: 60 (0x3C)
NextProtocol: UDP, 17(0x11)
HopLimit: 128 (0x80)
SourceAddress: 2002:836B:5:1000:34CD:1B68:10DC:EAF4
DestinationAddress: 2002:836B:5:0:0:0:836B:5
+ Udp: SrcPort = ISAKMP/IKE(500), DstPort = ISAKMP/IKE(500), Length = 60
+ AuthIP: version 1.0, Notify, Initiator, First Exchange with Unknown peer SPN, 0x00003619 - ERROR_IPSEC_IKE_POLICY_CHANGE - New policy invalidated SAs formed with the old policy. , Payloads = HDR, CRYPTO, N, Flags = ..., Length = 52
We note that this is the establishment of the IPsec tunnels that will be used to secure our data. Frames 270 to 283 will continue this process:
On a side note, remember you can view and troubleshoot the IPsec associations using windows firewall (wf.msc):
Once the IPsec client knows the rules, with main mode security association we see a swag of encrypted frames from frame 284 onwards...
Later we see the quick mode association in frame 305.
If you are interested in the difference between main mode and quick mode in regards to IPsec, i refer to the Cisco page on the subject here: https://www.ciscopress.com/articles/article.asp?p=24833&seqNum=6 and the Microsoft page here: https://technet.microsoft.com/library/bb878063. Generally though, i oversimplify it in my head and think of main mode as the authentication of the computers to each other and master key exchange, then quick mode for specific tasks with potentially different needs inside the IPsec Association.
Once the DA client has the IPHTTPS and IPsec tunnelling down it is ready to transmit data, I haven't included any of this in the trace that is attached to the blog because that trace is for comparing to broken DA clients and i wasn't concerned about what happens once it is working. But it would be interesting to know what SMB or HTTP looks like in a trace going over our IPHTTPS tunnel. Would it be IPv6 traffic? IPv4? ESP? Or would it show as HTTP or SMB...
Lets check:
If you predicted it would be encrypted, you would be right. If everything is working well our frames should be encrypted. The difference will be the interface that is being captured. When you start netmon you have the option to select which interface you are interested in. In my trace, I've selected both the IPHTTPS and the Ethernet interfaces so i see a combination of IPv6 traffic from the HTTPS interface, and IPv4 TLS traffic from the Ethernet interface.
And, that's about it for a Windows 8, HTTPS version of the trace. I will attempt to upload and go through a Windows 7 version in the next couple of days.
Before i finish - if you are interested in DA and haven't read this: https://www.amazon.com/Windows-Server-Unified-Planning-Deployment/dp/1849688281/ref=sr_1_1?ie=UTF8&qid=1358078953&sr=8-1&keywords=unified+remote+access you should check it out. Its the sort of book you can read cover to cover and it has heaps of really valuable information about your DA implementation and troubleshooting. I found that it really filled in some gaps I had in my understanding over the holidays and was definitely worth the time to read.
Hope your DA implementations are going really well. :)