如何让PPTP协议通过juniper防火墙

在juniper的官网上找到一片关于PPTP的KB

 

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
ScreenOS

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 calls. 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 calls. 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 particular PPP packet for which it belongs to. 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 diagram 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 ---->
       <---- scrp ----- [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 ID's, 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 direction. 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.

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 Server's 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 PC's 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,vsd 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,vsd 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,vsd 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,vsd 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 the second session, id 1048567, the client PC 60.60.60.2 is initiating a connection request to port 1723. The source port 4762 is translated to 7263.

NOTE: This source port will be used in the xlate table entry to match the data session.

Xlate Table Entry

The xlate table shows there is a pair of xlate entries per connection, in the forward and reverse direction, as there will be two GRE sessions per connection.

nsisg2000-> get alg pptp xlate
2 out of 2000 pptp xlate entries are used.
Failed count 0.
---------- xlate table ----------
60.60.60.2/32768->172.19.50.129 xlated to 172.19.51.234/7264->172.19.50.129(0), src-port:4762, time:100
60.60.60.3/16384->172.19.50.129 xlated to 172.19.51.234/7258->172.19.50.129(0), src-port:2249, time:110
---------- rev xlate table ----------
60.60.60.3/16384->172.19.50.129 xlated to 172.19.51.234/7258->172.19.50.129(0), src-port:2249, time:110
60.60.60.2/32768->172.19.50.129 xlated to 172.19.51.234/7264->172.19.50.129(0), src-port:4762, time:100

• The table for client 60.60.60.2 shows that source IP is translated to 172.19.51.234.
• 32768 is the Call ID generated by the client1, and the firewall translated the Call ID of 32768 to 7264.
• At the end of each entry, the source port is specified.  Note that 4762 is mapped, which was used when initiating the Control Connection in the initial connection request.
• The table for client 60.60.60.3 shows that source IP is translated to 172.19.51.234.
• 16384 is the Call ID generated by the client2, and the firewall translated the Call ID of 16384 to 7258,
• The source port 2249 is mapped, which was used when initiating a control connection the initial connection request

 

GRE Data Session

The firewall will create a pair of GRE session per connection in both directions, so note that there are four GRE sessions in the table:

nsisg2000-> get sess protocol 47
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 4 sessions according filtering criteria.

id 1048544/s**,vsys 0,flag 00001000/0002/0003,policy 1,time 180, dip 0 module 1, resource 3-50000-124999
 if 38(nspflag 800801):60.60.60.3/0->172.19.50.129/999,47,000c29e91032,sess token 3,vlan 0,tun 0,vsd 0,route 6
 if 37(nspflag 800900):172.19.51.234/7258<-172.19.50.129/999,47,00c09f21c24f,sess token 4,vlan 0,tun 0,vsd 0,route 4
id 1048573/s**,vsys 0,flag 00001000/0002/0003,policy 1,time 180, dip 0 module 1, resource 3-50000-125000
 if 37(nspflag 800801):172.19.50.129/0->172.19.51.234/7258,47,00c09f21c24f,sess token 4,vlan 0,tun 0,vsd 0,route 4
 if 38(nspflag 800900):172.19.50.129/999<-60.60.60.3/16384,47,000c29e91032,sess token 3,vlan 0,tun 0,vsd 0,route 6

id 1048568/s**,vsys 0,flag 00001000/0002/0003,policy 1,time 179, dip 0 module 1, resource 3-49999-124997
 if 38(nspflag 800801):60.60.60.2/0->172.19.50.129/17382,47,000c29686775,sess token 3,vlan 0,tun 0,vsd 0,route 6
 if 37(nspflag 800900):172.19.51.234/7264<-172.19.50.129/17382,47,00c09f21c24f,sess token 4,vlan 0,tun 0,vsd 0,route 4
id 1048566/s**,vsys 0,flag 00001000/0002/0003,policy 1,time 179, dip 0 module 1, resource 3-49999-124998
 if 37(nspflag 800801):172.19.50.129/0->172.19.51.234/7264,47,00c09f21c24f,sess token 4,vlan 0,tun 0,vsd 0,route 4
 if 38(nspflag 800900):172.19.50.129/17382<-60.60.60.2/32768,47,000c29686775,sess token 3,vlan 0,tun 0,vsd 0,route 6

• Session id 1048544 is the session established between client2 and the PPTP server. The session has a destination port of 999; this is the Server Call ID.  The source port remains zero, due to the NAT.  The source port is being translated to the Client Call ID 7258, which was generated in the initial connection as per the xlate table. 
• Session id 1048573 is the session established in the opposite direction, from the PPTP server, which has the destination port as the client's translated Call ID. The source port remains zero, due to the NAT.  The IP 172.19.51.234 is translated to the client2 IP address, and the source port and destination port are translated to the respective Server Call ID and Client Call ID.
• Session id 1048568 is the session established between client1 and the PPTP server. The session has a destination port of 17382; this is the Server Call ID. The source port remains zero, due to the NAT.  The source port is being translated to the Client Call ID 7264, which was generated in the initial connection as per the xlate table.
• Session id 1048566 is the session established in the opposite direction, from the PPTP server, which has the destination port as the client's translated Call ID. The source port remains zero, due to NAT. The IP 172.19.51.234 is translated to the client1 IP address, and the source port and destination port are translated to the respective Server call ID and Client call ID.

Once the GRE session is installed, the only way to clear the xlate table entry is when the PPTP connection is disconnected normaly, where the user says disconnect the PPTP connection.

In the event if the PPTP connection is disconnected abruptly, for example the PC crashes or the network cable is disconnected, then the firewall does not receive a Close Connection Request, so the GRE session and the xlate table for that session will remain on the firewall and wait for the session timeout to be cleared.  Once the session timeout reaches zero, the GRE session and the xlate entry will be deleted.  If in the event customer wants to clear the session before the timeout, this is not possible as these sessions are RM (resource manager) based and cannot be cleared with "clear session".

id 1048544/s**,vsys 0,flag 00001000/0002/0003,policy 1,time 180, dip 0 module 1, resource 3-50000-124999

"module 1" in the session output indicate that this is a RM based session.

Configuration details required :

The lab firewall was configured with the following config:

set interface "ethernet4/1" zone "Untrust"
set interface "ethernet4/2" zone "Trust"
set interface "ethernet2/1" zone "Trust"
set interface "ethernet2/2" zone "Untrust"
unset interface vlan1 ip

set interface ethernet4/1 ip 172.19.51.234/23
set interface ethernet4/1 route
set interface ethernet4/2 ip 60.60.60.1/24
set interface ethernet4/2 nat

exit
set policy id 1 from "Trust" to "Untrust"  "Any" "Any" "ANY" permit
set policy id 1

nsisg2000-> get alg
DNS          ALG : enabled
FTP          ALG : enabled
H323         ALG : disabled
HTTP         ALG : enabled
MGCP         ALG : disabled
MSRPC        ALG : disabled
PPTP         ALG : enabled

 

ScreenOS Recommendation

  If your environment is running PPTP connections thru the Juniper firewall, then Juniper strongly recommends running ScreenOS 6.1.0r4 or later, in order to get the latest PPTP fixes.

Purpose:

Configuration