Resolving the problem that PPTP cannot transmit data when accessing intranet resources

PPTP has two streams, one is the control flow (RFC2637 definition), and the other is a data stream (GRE, RFC2784). And the general ALG different is (such as FTP), Nat encountered PPTP, not the port or IP, but PPTP inside Callid (throw a ball to everyone, why does PPTP call ID whole to the PPTP control stream?). In the PPTP protocol, with the concept of a call ID, the client initiates a connection to the server, tells the service what my called ID is, and the service side responds to the client what its call ID is, and, more importantly, some later (note not all) It needs to be used in the control transfer, in all data transmissions (GRE). And then we'll take a look at two aspects to see how the problem arises and how to solve it:

Initiating PPTP connection requests from intranet to extranet

Initiate PPTP connection request from extranet to intranet (commonly known as static mapping)

Let's go and see the world outside.

(Note: The following structure is 1) to mention the PPTP protocol, 2 to mention the GRE protocol, 3 How to handle the GRE data stream, 4 How to handle the PPTP control flow. )

The PPTP server is listening on the tcp/1723 port. The first packet that the client sends to carry the call ID is a packet called Outgoing-call-request, as shown in the following image (ignoring the front Ethernet header, IP header, and TCP header):

You can see that the example client on our side has a call ID of 16384 (which is assigned to itself), so I'm going to say client-call-id.

After the server receives this packet, it then responds to a packet called outgoing-call-reply, as shown in the following example:

This shows that the server's own call ID is 107 (this server is assigned to itself, I am server-call-id), but also the Client-call-id back to the client. Gee, this seems to be no problem, anyway, this call ID change, for this connection has no effect, NAT can also function. But, you reader, PPTP also needs to use a protocol, which is GRE (RFC 2784). The GRE is a protocol that is in the same horizontal line as TCP and UDP. But unlike TCP/UDP, the GRE does not carry port information, and it uses the call ID for multiplex and Demultiplex. Let's take a look at a GRE packet sent to the server by the client (hint, the PPP protocol package is behind the GRE head, but there is no need to care):

There is a call ID, which is not to say your own, but to say the other side (right, that is, the PPTP inside the Server-call-id), that is, the service side, that is, my GRE data to the service end of the 107 "port."

The server also uses the same strategy, except that the call ID indicates the client, and an example is as follows:

(Note: The above are the principles of some protocols, if you read the RfC, you may not understand these.) Insert a scene from a movie: C drive A car on the road, ahead of a man D ride a bike. C in pursuit of D, c Nervous said: "You ... You may not ride a bike faster than me! "

The problem is that these packets go through our poor NAT, and GRE asks NAT: "My call ID, the tube or whatever?" Nat replied: "No matter." "That said, but not easy, because the GRE has no port, if NAT does not forge a port, the following scenario is unthinkable:

The IP address of a host A is 192.168.1.2, to the 1.1.1.1 (disclaimer: Here is just the assumption that there is no real test of it, 1.1.1.1 please do not be offended) to initiate a PPTP connection request, Client-call-id is 16384, Server-call-id is 107;

There is also a host B in the network, IP address is 192.168.1.3, also to 1.1.1.1 to initiate PPTP connection request, Client-call-id2 is 16385, Server-call-id2 is 108.

Nat if the only conversion IP address (assuming NAT's public IP is 116.238.184.159), then the data to be able to reach 1.1 1.1, but the GRE packets back to 116.238.184.159, is NAT supposed to send it to 192.168.1.2 or 192.168.1.3? In this case, Nat must find a "port" to determine who this packet is sent to, and "port" needs to meet the following characteristics:

On a host, this is the only one;

must exist in each packet.

While scanning the entire GRE packet, only the call ID has this attribute. So the relationship is, because there is no port information like TCP/UDP in the GRE packet, so a message is needed, and the presence of the call ID satisfies such a condition. But the call ID and TCP/UDP port have different places:

The TCP/UDP port is the same in the transport layer, the relative offset is 0, and the call ID's offset in the transport layer is 6;

TCP/UDP ports carry both source and destination ports in each packet, but the call ID only carries one and refers to the other.

It is important to realize that these differences affect the fact that NAT treats TCP/UDP and GRE in a completely different way, and that is one of the reasons for the PPTP ALG!

Hey, is there any reason why you need to deal with GRE? Well, let's see if the GRE packets are guaranteed to pass NAT smoothly.