PPTP VPN Operation
This was originally submitted to the newsletter but I wanted it to be searchable as well so I'm reposting it here.
The following paper will walk through the step-by-step, packet-by-packet process that occurs when a client PC (192.168.1.3/24) connects to a PPTP VPN Server (18.104.22.168/24) and attempts to access the resources on a web server (22.214.171.124/24). The paper will be divided into two separate processes. The first will be the building of the VPN session, from the initial request to the completed connection and will include actions as they occur on the client PC and the PPTP VPN Server, as well as the data passed between them.
In order to discuss the step-by-step process of a VPN connection, we must first have a minimum of prerequisite knowledge on the subject. A VPN is a virtual private network, in essence a tunnel through a public network (The Internet) which connects a remote PC or LAN to the local LAN, allowing the devices to appear as though they are on the same network, even though they are physically separated. The communication within this tunnel is encrypted to ensure that the private information remains private. The VPN that we are using is a PPTP VPN, most commonly implemented as a Microsoft VPN solution. PPTP (Point-to-Point Tunnelling Protocol) is a combination of PPP (Point-to-Point Protocol) and GRE (Generic Routing Encapsulation). The original IP data is encapsulated using PPP, a protocol which was developed to facilitate the use of IP over dial-up networks. The PPP encapsulated packet is then encapsulated within a GRE packet, which can then be sent across the network using IP. This encapsulation process is demonstrated in Figure 1
Figure 1 - http://www.seeminglyrandom.info/vpn/vpn-1.jpg
Before the connection can take place, configuration is required on both the client and the server. On the server (Windows 2000 in this example) we must enable Routing and Remote Access and then more specifically the VPN server located within it. The server will assign IP Addresses to the clients and will use a local user database instead of a RADIUS server. Two users are created on the server to allow a connection. On the client side we must create a new network connection (Connect to a private network through the internet) and we supply the known IP Address of 126.96.36.199. Now we can open the connection box, enter our username and password and click the ‘Connect’ button. Before we actually click the button, let us look at the results of the commands route print and ipconfig on the client PC so that we can compare them with the output after the tunnel is established.
As you can see in Figure 2 we have a single network on our Windows 2000 client. This is the interface over which we will establish our VPN connection. Figure 3 demonstrates that we have knowledge of routes to our client, our loopback, our directly connected networks and a default gateway of 192.168.1.1, our router on the same Ethernet segment.
Figure 2 - http://www.seeminglyrandom.info/vpn/vpn-2.jpg
Figure 3 - http://www.seeminglyrandom.info/vpn/vpn-3.jpg
Now we will follow the connection process. This process will be walked through step-by-step and will reference Appendix A which contains a block-diagram of the process demonstrating protocols and ports that are used.
- 1. The client will initiate the connection using TCP which requires a three-way handshake. This requires that a TCP synchronize flag (SYN) be sent from the socket (a standard format of IP Address:Port Number) 192.168.1.3:1141 to the PPTP listening port on the PPTP server, more specifically 188.8.131.52:1723.
2. The server responds to SYN with an acknowledge flag (ACK), as well as by sending a SYN of it’s own to the client. This data originates on port 1723 and is destined for port 1141.
3. The final step of the three-way handshake, the client responds to the servers SYN by sending an ACK of its own.
4. The client now sends a PPTP message to the server requesting a new connection.
5. The server responds with a reply message. In this stream we get a chance to view the error correcting abilities of TCP. This initial reply is received with an incorrect checksum. The checksum on the packet is 0x8bc6; however the expected checksum is 0x3f0d.
6. The server retransmits its reply message which this time arrives with the correct checksum.
7. The client now sends an outgoing call request which includes information like the serial number of the call, the maximum and minimum bps of the connection (max/min connection speed) and the receiving window size.
8. The server responds to the call request with information such as the actual connection speed and it’s receiving window size.
9. The client now sends a Set Link Info message which contains two important pieces of information, the Send ACCM and the Receive ACCM. This is a list of characters that the software will escape (protect against incorrect interpretation) so that they can be read as characters and not commands. These values are both set to the default of 0xffffffff which means to escape all ASCII control characters valued 0 to 31.
10. A PPP Link Control Protocol (LCP) packet is now sent by the client. This packet is requesting certain configurations that it would like to see. Some of the options include compression, the multilink MRRU (The multilink version of an MTU (Max Transfer Unit)) and the end-point discriminator.
11. The server requests similar configuration options with its own request packet, but also requests the authentication type of CHAP and a link discriminator.
12. The server also sends out a Configuration ACK, accepting the options that the client has presented.
13. The client sends a Configuration Reject, rejecting a single option provided by the server. The link discriminator option.
14. The server resends a Configuration Request, this time omitting the link discriminator option.
15. The client responds and acknowledges the options provided by the server.
16. The server now sends it’s own Set Link Info message, outlining the same ACCM values as the client has already done (see step 9)
17. The server now sends a CHAP Challenge packet to the client, which clearly contains the local machine name of our PPTP server.
18. The client replies with an LCP Identification packet containing the information MSRAS (Microsoft Remote Access Server) and some additional information.
19. The client sends another LCP Identification packet containing its local machine name.
20. The client once again sends its ACCM information in a Set Link Info packet.
21. The client responds to the CHAP Challenge with a CHAP Response packet which includes the username in clear text.
22. The server authenticates the user against its local database and sends back a CHAP Success message to indicate that authentication was successful.
23. The server now sends a Call Back Control Protocol message. This is an additional security measure that could have been implemented. After a successful authentication, the server could have disconnected the call and called the client back as a way of verifying the identity of the “caller”. This VPN session is not utilizing call backs, so the packet contains information that translates to “no call back”
24. The first GRE packet is seen to cross the network at this point. The client sends PPP encapsulated in the GRE Packet, but there is no data field within the PPP encapsulation.
25. The client responds to with a CBCP Call Back Response to verify that there will be no call back.
26. The server acknowledges the fact that there will not be a call back and the process continues.
27. The server now sends the first in a series of Compression and IP Control protocol (CCP and IPCP respectively) packets. This first packet identifies that the server would prefer that MPPC (Microsoft Point-to-Point Compression) be used and that it will support 40, 56 and 128-bit encryption.
28. The server also sends an IPCP packet containing the IP Address 184.108.40.206, notifying the client that the address is available.
29. The client sends a CCP packet back to the server indicating that it would also desire MPPC and that it is capable of 40, 56 and 128-bit encryption.
30. The server now sends a CCP Configuration NAK, essentially telling the server that since 128-bit encryption is available on both ends it refuses to use 40 and 56-bit encryption. (Reference Step 29)
31. The client sends another request. This request is its way of informing the server that it requires an IP Address, along with DNS and WINS servers.
32. The server sends a CCP Configuration Reject packet, which tells the client that it has no DNS and WINS servers to provide. (Reference Step 31)
33. The client sends a NAK of it’s own, informing the server that it also refuses to use 40 and 56-bit encryption if 128-bit is available (Reference Step 27)
34. Now that an encryption level (128-bit) has been decided on, the server officially requests that configuration, using a Configuration Request packet.
35. At this point the client acknowledges (using a Configuration ACK packet) that the IP Address 220.127.116.11 is available (Reference Step 28).
36. The client now sends its own official request for 128-bit encryption (Reference Steps 33)
37. The server acknowledges the use of 128-bit encryption. (Reference Step 36)
38. Having not received acknowledgement on it’s usage of the 18.104.22.168 address, the client sends out another Configuration Request with an all 0 IP Address (0.0.0.0)
39. The server responds with a NAK, it will not acknowledge the use of the IP Address 0.0.0.0 and suggests the usage of address 22.214.171.124.
40. The client acknowledges the use of 128-bit encryption (Reference Step 34)
41. The client sends an official request to use the 126.96.36.199 address recommended by the server.
42. The server sends one final Configuration ACK, acknowledging the use of the address 188.8.131.52
43. The server sends a TCP ACK to the client and the VPN establishment is finalized. Traffic can now move freely across the tunnel.
The result of these 43 steps is that a VPN Tunnel has be established between the client PC and the PPTP Server. The tunnel is using Microsoft Point-to-Point Compression and 128-bit Encryption. The client is using the dynamically assigned IP Address of 184.108.40.206. Let’s take a look at the output of ipconfig and route print now that we have established the VPN connection. As you can see, we now have a WAN PPP interface. As you can see in Figure 4 our IP Address is 220.127.116.11. This screenshot was taking on a separate connection from the one outlined in the above steps. This was to test and prove a theory that the PPTP Server assigns even addresses first instead of assigning them incrementally. Our client was initially offered .50; however this transaction was never finalized and the server came back offering the address of .52. We wondered why .51 was not offered and decided to tear down the connection and establish another one, as you can see, this time the .54 address was offered and accepted.
Figure 4 - http://www.seeminglyrandom.info/vpn/vpn-4.jpg
You can also see that we have new routes in our route table (Figure 5). The first route is 18.104.22.168 (again this is from a second connection). This route has a gateway of 127.0.0.1, our loopback address. Since this address is associated with one of our interfaces but not on a network we have direct access to, we don’t want to send traffic destined for ourselves across the VPN tunnel so that it can be sent back to us. By adding our IP with our loopback as our default gateway, it ensures that we contact ourselves and never send traffic across the wire. Another addition to our route table is the IP Address of the PPTP server. The gateway to the server is our regular 192.168.1.1 gateway. The last addition is the broadcast address for the remote network 22.214.171.124, which has a default gateway of our IP Address 126.96.36.199. This setup of new routes, allows us to ensure that even though the networks are distant, we don’t send information bound for that network across the default gateway. Instead it is forwarded through our tunnel.
Figure 5 - http://www.seeminglyrandom.info/vpn/vpn-5.jpg
Now that we have a connection established, we can look at what happens when we request a resource from the other side of the VPN Tunnel, more specifically a webpage located on a server (188.8.131.52). The block diagram detailing the steps found in this process can be located in Appendix B.
- 1. The user enters the website address (184.108.40.206) in their browser. After the appropriate actions are taken to determine the correct path for this packet, the data is transmitted using GRE and PPP to the PPTP server at 220.127.116.11
2. The PPTP server broadcasts out an ARP request asking who has the address 18.104.22.168.
3. The web server responds to the PPTP server that it has the address 22.214.171.124 and that its MAC Address is 00:0A:8A:95:00:C0.
4. The PPTP server removes the GRE and PPP encapsulation and forwards out the original IP packet (Containing a TCP SYN), making it look as though it has spoofed the source address 126.96.36.199.
5. The Web server broadcasts an ARP request asking who has the address 188.8.131.52.
6. The PPTP Server responds on behalf of 184.108.40.206 providing its own MAC Address – 00:11:2F:56:10:41. This is essentially ARP poisoning being used legitimately.
7. A GRE/PPP Encapsulated packet is sent off to the Client PC.
8. The web server responds to the TCP SYN by sending a SYN/ACK to 220.127.116.11. This is received by 18.104.22.168 because of the ARP Poisoning.
9. The PPTP server encapsulates the SYN/ACK and sends it through the tunnel to the client PC
10. The client PC sends an encapsulated response back to the PPTP Server; at this point it can only be assumed that it is a TCP ACK response to the SYN/ACK of step 8.
11. The PPTP server removes the GRE and PPP encapsulation and forwards out a TCP ACK (proving our assumption in step 10 is correct)… again sending out the original IP Packet so that it appears as though 22.214.171.124 has spoofed the IP Address 126.96.36.199
12. The client sends another encapsulated packet to the PPTP server; this can be assumed to be the HTTP GET Request by anyone with knowledge of TCP and HTTP operation.
13. The PPTP server again removes the GRE and PPP encapsulation and forwards out the packet with its original IP Header intact, the packet appears to be coming directly from 188.8.131.52 to 184.108.40.206.
14. The HTTP 200 OK response is sent by the web server and received by the PPTP server due to the ARP poisoning in step 6.
15. The PPTP server encapsulates the HTTP 200 OK message and sends it to the client PC.
This process will now continue as the remainder of the website is sent across. Plain text transactions occurring between the PPTP server and the Web server, and encrypted, compressed transactions between the Client PC and the PPTP Server. While it appears as though the address is spoofed (if you look at Layer 2 information it technically is) you have to remember that the PPTP Server is simply relaying the information that it finds in the GRE and PPP encapsulated packets.
plz update the links!!!!!!!!!!!!