Find a piece of pptp kb on juniper's official website.
How PPTP connections are established and maintained through Juniper firewall
Knowledge Base ID:
KB12423
Version:
4.0
Published:
10 Mar 2009
Updated:
10 Mar 2009
Categories:
Firewall/IPSec_VPN
GRE
PPTP
Screnos
Synopsis:
This tech note discusses how PPTP connections are established and maintained through Juniper firewall, which is helpful for troubleshooting PPTP connection issues.
Problem:
Solution:
Introduction
PPTP (Point-to-Point Tunneling Protocol) is used to provide IP security at the network layer. PPTP uses TCP 1723 for its control connection and GRE (IP protocol 47) for its PPP data.
PPTP has problems working with PAT. PPTP uses GRE encapsulation to carry tunneled data. the Juniper firewall currently cannot handle PAT for GRE traffic. this is because GRE traffic carries NO port number so the box has no way to distinguish between 2 clients having the same public IP. another problem is that PPTP uses the source IP address and the call ID field in the GRE header to identify a tunnel. when multiple clients that share the same public IP address open up tunnels to the same PPTP server, then they may pick up the same call ID. this is an error because multiple sessions between the same client-server pair with the same call ID cannot be opened. hence, a pptp alg is needed to translate the call ID value sent by the client.
NOTE: The main part of the PPTP protocol is based on the call id, when configured the firewall to handle NAT for PPTP the firewall translates both the IP address and the call id generated by the Client and Server
Protocol Overview
The PPTP protocol consists of a control connection and a data tunnel. the control connection runs over TCP and is used to establish and disconnect CILS. the data tunnel carries PPP packets encapsulated in GRE packets which are carried over IP.
Control Connection Message
After TCP connection is established with control port 1723, either the client or server can send a Start Control Connection Request message to establish a control connection. the other end replies with a Start Control Connection Reply message. either end can then request a call to be established. we only consider client-initiated CILS. in this scenario, the client sends an Outgoing Call Request message. it assigns a call ID that is unique to the tunnel. the call ID is used to identify the call for a special PPP packet for which it belongs. the server replies with an Outgoing Call Reply message, which carries its own call ID and the client's call ID.
Network Topology
The PPTP clients are located behind a Juniper firewall with private IP addresses.
The Juniper firewall translates the clients 'private IP addresses to a pool of public IP addresses (NAPT ).
The PPTP servers are located on the Internet.
PPTP Client PC ---> Firewall <--- Internet ---> PPTP Server
PPTP Operation thru Juniper firewall
The following flow dimo-will be referenced in the details that follow.
Client <--- TCP syn/syn-ack/ack ----> server
---- Ocrq ---> [Here pptp xlate entry is created]
<---- Ocrp ----
<---- GRE ----> [They are used to negotiate PPP parameters and transfer data...]
<---- GRE ---->
----- Ccrq ---->
<---- Cdn ------
----- Scrq ---->
<---- Encrypted ----- [Here the pptp xlate entry is removed]
<---- TCP fin/fin-ack ------>
Control and data session details:
Initially the TCP connection for the control port 1723 is established between the client and the server, and the firewall creates the session for the control port. next, the client sends a OCRQ (Outgoing Call Request) message to the server along with Client Call ID. after seeing the OCRQ message, the xlate table is created for that session and translated the Client Call ID. the server responds with the message OCRP (Outgoing Call Reply) along with the Server Call ID and the translated Client Call ID. now both the client and server know there respective Call IDs, and the firewall keeps track of the same with the xlate table created with the Client Call ID.
After the above stage, the control connection is UP.
Now the client and server will negotiate the GRE session for data and PPP negotiation parameters like authentication.
For PPTP to pass the data traffic, the ALG will create a session for data traffic arriving in a specific ction. this means that there will be two data sessions opened for each tunnel: one for client-to-server traffic using the server's call ID as the destination port and the other for server-to-client traffic using the client's translated Call ID as the destination port. the source port will not be used for session match (it will be shown as 0 ). at this stage the firewall will open the ALG gate for GRE traffic by creating a GRE session in both directions ctions.
With the GRE session in place, the data traffic will be passed matching the data session and the xlate table.
Call Clear or Disconnection Details
After the data transfer over the GRE tunnel is complete, the client sends the CCRQ (Call Clear Request) message along the Client Call ID. the server responds with CDN (Call Disconnect Notification) message with the Servers Call ID. the firewall will clear the GRE data session and remove the xlate table. the TCP connection is torn down by sending a FIN.
Lab Output-explaining the above details
The lab setup contains the following devices:
Two client PCs on the Trust side
ISG2000 firewall running 6.1r3 patched release
PPTP server is on the Untrust side
The firewall trust interface is in NAT mode, and the output below explains the PAT operation for PPTP which is commonly used by the customer.
IP address details:
Client 1 = 60.60.60.2
Client 2 = 60.60.60.3
PPTP server = 172.19.50.129
Each client has a PPTP session established for the control connection. The output of get session show two sessions established:
Nsisg2000-> get session dst-port 1723
Alloc 6/max 1048576, alloc failed 0, mcast alloc 0, di alloc failed 0
Total reserved 0, free sessions in shared pool 1048570
Slot 2: hw0 alloc 2/max 1048575
Total 2 sessions according filtering criteria.
Id 1048505/s0 *, vsys 0, flag 08000400/0000/0003, policy 1, time 177, dip 2 module 0
If 38 (nspflag 801801): 60.60.60.3/2249-> 172.19.50.129/1723,6, 000c29e91032, sess token 3, vlan 0, tun 0, sealing 0, route 6, wsf 0
If 37 (nspflag 10801800): 172.19.51.234/7257 <-172.19.50.129/1723,6, 00c09f21c24f, sess token 4, vlan 0, tun 0, sealing 0, route 4, wsf 0
Id 1048567/s0 *, vsys 0, flag 08000400/0000/0003, policy 1, time 178, dip 2 module 0
If 38 (nspflag 801801): 60.60.60.2/4762-> 172.19.50.129/1723,6, 000c29686775, sess token 3, vlan 0, tun 0, ASD 0, route 6, wsf 0
If 37 (nspflag 10801800): 172.19.51.234/7263 <-172.19.50.129/1723,6, 00c09f21c24f, sess token 4, vlan 0, tun 0, sealing 0, route 4, wsf 0
In the first session, id 1048505, the client PC 60.60.60.3 is initiating a connection request to port 1723. The source port 2249 is translated to 7257.
In