PPTP Traffic Analysis

http://www.microsoft.com/technet/community/columns/cableguy/cg0103.mspx

The Point-to-Point Tunneling Protocol (PPTP) is a widely used virtual private networking protocol, included in Windows 98, Windows Millennium Edition, Windows 2000, and Windows XP. PPTP is a tunneling mechanism to transfer Point-to-Point Protocol (PPP) frames across an intermediate network. By leveraging the authentication, encryption, and protocol configuration mechanisms of PPP, PPTP connection provides a way to create secure connections across public networks, such as the Internet, for both remote access and router-to-router virtual private network (VPN) connections. PPTP is described in RFC 2637.

PPTP traffic consists of the following:

• A PPTP control connection

A logical connection representing the PTPP tunnel that must be created, maintained, and terminated through a series of PPTP messages. PPTP control connection traffic uses a dynamically allocated TCP port on the PPTP client, and the IANA-reserved TCP port of 1723 on the PPTP server.

• GRE encapsulation for data

When data is sent across the PPTP connection, PPP frames are encapsulated with a Generic Routing Encapsulation (GRE) header, which includes information that identifies the specific PPTP tunnel for the data packet.

In the most common configuration, a firewall is attached to the Internet and the VPN server (a PPTP server) is an intranet resource that is attached to the perimeter network. This is shown in the following figure.

The VPN server has an interface on both the perimeter network and the intranet. In this configuration, the firewall must be configured with input and output filters on its Internet and perimeter network interfaces, allowing PPTP tunnel maintenance traffic and PPTP tunneled data to pass to the VPN server.

Configure the following input packet filters on the Internet interface of the firewall to allow the following types of traffic:

• Destination IP address of the VPN server's perimeter network interface and TCP destination port of 1723 (0x6BB).

This filter allows PPTP tunnel maintenance traffic to the PPTP server.

• Destination IP address of the VPN server's perimeter network interface and IP Protocol ID of 47 (0x2F).

This filter allows PPTP tunneled data to the PPTP server.

• Destination IP address of the VPN server's perimeter network interface and TCP source port of 1723 (0x6BB).

This filter is required only when the VPN server is acting as a calling router (a VPN client) for router-to-router VPN connections. This filter should be used only in conjunction with the recommended IP packet filters on the perimeter network interface of the VPN server. The recommended packet filters on the VPN server's perimeter network interface include those which allow inbound TCP traffic from port 1723 and outbound traffic to TCP port 1723 for TCP connections originated by the VPN server. For more information about the recommended filters on the perimeter network interface of the VPN server, see VPNs and Firewalls.

Configure the following output filters on the Internet interface of the firewall to allow the following types of traffic:

• Source IP address of the VPN server's perimeter network interface and TCP source port of 1723 (0x6BB).

This filter allows PPTP tunnel maintenance traffic from the VPN server.

• Source IP address of the VPN server's perimeter network interface and IP Protocol ID of 47 (0x2F).

This filter allows PPTP tunneled data from the VPN server.

• Source IP address of the VPN server's perimeter network interface and TCP destination port of 1723 (0x6BB).

This filter is required only when the VPN server is acting as a calling router (a VPN client) in a router-to-router VPN connection. This filter should be used only in conjunction with the recommended IP packet filters on the perimeter network interface of the VPN server.

Configure the following input filters on the perimeter network interface of the firewall to allow the following types of traffic:

• Source IP address of the VPN server's perimeter network interface and TCP source port of 1723 (0x6BB).

This filter allows PPTP tunnel maintenance traffic from the VPN server.

• Source IP address of the VPN server's perimeter network interface and IP Protocol ID of 47 (0x2F).

This filter allows PPTP tunneled data from the VPN server.

• Source IP address of the VPN server's perimeter network interface and TCP destination port of 1723 (0x6BB).

This filter is required only when the VPN server is acting as a calling router (a VPN client) in a router-to-router VPN connection. This filter should be used only in conjunction with the recommended IP packet filters on the perimeter network interface of the VPN server.

Configure the following output packet filters on the perimeter network interface of the firewall to allow the following types of traffic:

• Destination IP address of the VPN server's perimeter network interface and TCP destination port of 1723 (0x6BB).

This filter allows PPTP tunnel maintenance traffic to the PPTP server.

• Destination IP address of the VPN server's perimeter network interface and IP Protocol ID of 47 (0x2F).

This filter allows PPTP tunneled data to the PPTP server.

• Destination IP address of the VPN server's perimeter network interface and TCP source port of 1723 (0x6BB).

This filter is required only when the VPN server is acting as a calling router (a VPN client) in a router-to-router VPN connection. This filter should be used only in conjunction with the recommended IP packet filters on the perimeter network interface of the VPN server.

A PPTP control connection is established with the following process:

1. A TCP connection is established from a dynamically allocated TCP port on the PPTP client to TCP port 1723 on the PPTP server.
2. The PPTP client sends a PPTP Start-Control-Connection-Request message, which is used to establish a PPTP control connection.
3. The PPTP server responds with a PPTP Start-Control-Connection-Reply message.
4. The PPTP client sends a PPTP Outgoing-Call-Request message and selects a call ID to identify the PPTP tunnel for data sent from the PPTP client to the PPTP server. The PPTP client uses the PPTP Outgoing-Call-Request message to request a PPTP tunnel (also known as a call) from the PPTP server.
5. The PPTP server responds with a PPTP Outgoing-Call-Reply message and selects its own call ID to identify the PPTP tunnel for data sent from the PPTP server to the PPTP client.
6. The PPTP client sends a PPTP Set-Link-Info message, to indicate PPP-negotiated options.

The end result of the PPTP control connection creation process is the following:

• The PPTP server has allowed a PPTP tunnel to be created.
• The PPTP client has determined the call ID to use in the GRE header when sending PPTP tunneled data to the PPTP server.
• PPTP server has determined the call ID to use in the GRE header when sending PPTP tunneled data to the PPTP client.

After the PPTP control connection is established, data can be sent between the PPTP client and the PPTP server. The first data packets sent over a PPTP connection are used to establish a PPP connection.

Data packets are first encrypted and encapsulated with a PPP header. The resulting PPP frame is then encapsulated with a Generic Routing Encapsulation (GRE) header, which has been modified for PPTP. The GRE-encapsulated PPP frame is then encapsulated with an IP header, which contains the source and destination IP addresses that correspond to the PPTP tunnel endpoints.

The modified GRE header used for PPTP data packets has the structure shown in the following figure. The original GRE header is defined in RFC 1701.

The fields in the modified GRE header are the following:

• Checksum Present A 1-bit flag that indicates, when set to 1, that a Checksum field is present. For PPTP, this flag is always set to 0.
• Routing Present A 1-bit flag that indicates, when set to 1, that a Routing field is present. For PPTP, this flag is always set to 0.
• Key Present A 1-bit flag that indicates, when set to 1, that a Key field is present. For PPTP, this flag is always set to 1. The Key field is the combination of the Protocol Type, Payload Length, and Call ID fields.
• Sequence Number Present A 1-bit flag that indicates, when set to 1, that the Sequence Number field is present.
• Strict Source Route Present A 1-bit flag that indicates, when set to 1, that a strict source route is present. For PPTP, this flag is always set to 0.
• Recursion Control A 3-bit field used for recursion. For PPTP, this field is always set to 0.
• Acknowledgement Number Present A 1-bit flag that indicates, when set to 1, that the Acknowledgement Number field is present.
• Flags A 4-bit field used for GRE flags. For PPTP, this field is always set to 0.
• Version A 3-bit field used to indicate the version of the GRE header. For PPTP, this field is always set to 1.
• Protocol Type A 16-bit field used to store the EtherType value for the GRE payload. For PPTP, this field is always set to 0x880B, the ~EtherType value for a PPP frame.
• Payload Length A 16-bit field used to indicate the length of the GRE payload.
• Call ID A 16-bit field used to indicate the PPTP tunnel for this packet. For a PPTP connection, there are two different values for the Call ID field. One value is used for data sent by the PPTP client and the other is used for data sent by the PPTP server.
• Sequence Number A 32-bit field used to indicate the sequence number for this packet. This field is present only when the Sequence Number Present flag is set to 1.
• Acknowledgement Number A 32-bit field used to indicate the highest sequence number for a GRE-encapsulated packet received for this tunnel. This field is present only when the Acknowledgement Number Present flag is set to 1.

PPTP uses the Sequence Number and Acknowledgement Number fields to detect dropped data packets.

The use of a separate mechanism for PPTP data encapsulation has an interesting side effect for network address translators (NATs). For more information about NATs, see Windows 2000 Network Address Translator (NAT) (the March 2001 Cable Guy article). Most NATs can translate TCP-based traffic for PPTP tunnel maintenance. However, PPTP data packets with the GRE header are not typically translated without using either a static address mapping or a PPTP NAT editor.

When a PPTP server is behind a NAT, the NAT must be manually configured with a static address mapping that maps all the traffic for a specific public address to a specific private address. In this case, only the addresses in the IP header are modified.

When a PPTP client is behind a NAT, a PPTP NAT editor is typically used. A NAT editor is an additional software component on the NAT that performs translation services beyond IP addresses, TCP ports, and UDP ports. Although it is a simple matter for the PPTP NAT editor to monitor incoming packets for GRE payloads and translate the IP addresses in the IP header, there might be multiple PPTP clients behind the NAT. In this case, the NAT is unable to determine to which private client the incoming PPTP data packet is destined, because the same public address is being used for multiple private clients. To determine the private client to which an incoming packet is destined, the PPTP NAT editor uses the Call ID field in the GRE header. However, when two different PPTP clients use the same Call ID, the NAT is unable to determine to which private client the packet is destined.

To provide correct multiplexing of GRE-encapsulated traffic to different private clients, the PTPP NAT editor monitors the PPTP control connection setup and translates both the PPTP client's Call ID field in the PPTP messages and the GRE-encapsulated data packets in the same way that it translates TCP or UDP source ports. By translating the PPTP client Call ID field, the NAT ensures that a unique Call ID is used for each PPTP tunnel, and for each PPTP client.

To maintain the PPTP control connection, the PPTP client sends a PPTP Echo Request message every 60 seconds, regardless of whether there is GRE-encapsulated data being sent between PPTP client and server. Upon receipt of the PPTP Echo Request message, the PPTP server sends a PPTP Echo Reply message. The PPTP Echo Request message contains an Identifier field, and its value is echoed in the PPTP Echo Reply message so that the PPTP client can match a sent PPTP Echo Request with its reply.

In order to terminate the PPTP connection, the PPP connection, the PPTP control connection, and the TCP connection must all be terminated. When a PPTP client terminates a PPTP connection, the following packets are exchanged:

1. The PPTP client sends the PPTP Set-Link-Info message, which specifies the PPP parameters of the link.
2. The PPTP client sends the Link Control Protocol (LCP) Terminate-Request message to terminate the PPP connection. LCP is a protocol in the PPP suite that manages configuration and maintenance of the logical PPP connection.
3. The PPTP server sends the PPTP Set-Link-Info message, which specifies the PPP parameters of the link.
4. The PPTP server sends the LCP Terminate-Ack message in response to the LCP Terminate-Request message. The PPP connection is now terminated.
5. The PPTP client sends a PPTP Clear-Call-Request message, which indicates to the PPTP server that the PPTP control connection is about to be terminated.
6. The PPTP server responds with a PPTP Call-Disconnected-Notify message.
7. The PPTP client sends a PPTP Stop-Control-Connection-Request message to terminate the PPTP control connection.
8. The PPTP server responds with a PPTP Stop-Control-Connection-Reply message.
9. The TCP connection is terminated.

If the PPTP server terminates the connection, the set of messages exchanged is the same, except that PPTP client is replaced with PPTP server (and vice-versa) in the previous process.

For more information about PPTP in Windows, see the following:

• Microsoft Virtual Private Networks Web site
• Windows 2000 Server Documentation (Networking\Virtual Private Networks)
• Windows 2000 Server Resource Kit
• Microsoft Product Support Services Knowledge Base

For any feedback regarding the content of this column, please write to Microsoft ~TechNet. Please be aware that a response is not guaranteed.

Ricetta da verificare (soprattutto le implicazioni di sicurezza).

Scenario: client PPTP in roaming, firewall GNU/Linux con interfaccia internet eth1 e interfaccia LAN eth0, all'interno della LAN il server PPTP ha indirizzo 192.168.1.35.

Con queste regole sul firewall si ridirige verso il server interno il traffico della sessione di controllo (TCP 1723) e tutto il protocollo GRE:

iptables -I FORWARD -i eth1 -o eth0 --protocol gre -j ACCEPT
iptables -t nat -I PREROUTING --proto gre -j DNAT --to-destination 192.168.1.35
iptables -t nat -I PREROUTING --proto tcp --dport 1723 -j DNAT --to-destination 192.168.1.35