11. Application Layer Gateways

Search in book...
Toggle Font Controls
Create new playlist

Name your new playlist

Playlist description (optional)
Sign In

Email address

Password

Forgot Password?

or

Continue with Facebook

Continue with Google
Sign Up

Full Name

Email address

Confirm Email Address

Password

or

Continue with Facebook

Continue with Google

Chapter 11. Application Layer Gateways

11.0. Introduction

An application layer gateway (ALG) is a feature on ScreenOS gateways that enables the gateway to parse application layer payloads and take decisions on them. Although there are other ScreenOS features, such as deep inspection, in which the gateway inspects traffic at the application layer, ALGs are typically employed to support applications that use the application layer payload to communicate the dynamic Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) ports on which the applications open data connections. Such applications include the File Transfer Protocol (FTP) and various IP telephony protocols. The dynamic TCP, UDP, or other ports that are opened by the ScreenOS gateway to permit these data or secondary channels are referred to as pinholes, and are active strictly for the duration of activity on the data channel.

An ALG implementation requires a ScreenOS gateway to inspect the application layer payload of a packet and understand the application control messages. An enabled ALG automatically kicks in and performs application layer inspection and the dynamic opening/closing of TCP/UDP ports as well as the associated network/ port address translation when a ScreenOS security policy that uses its associated service is referenced with matching traffic. For instance, a policy that references the FTP service on its default TCP port will automatically use the FTP ALG as long as the FTP ALG is enabled globally or for that particular policy on the ScreenOS gateway. You also can configure ALGs to be triggered when an ALG-supported application is running on a nondefault, custom port.

ScreenOS gateways ship with a wide range of available ALGs. Support for new ALGs is frequently added with new releases of ScreenOS. Additionally, ScreenOS offers a rich suite of ALG debugging capabilities that show ALG hits and dynamic pinholes being opened on the gateway. Several debug output captures are shown in the Discussion sections of the following recipes.

Differences Between ALGs and Deep Inspection

Deep inspection, discussed in Chapter 12, is a technology implemented in ScreenOS that performs application layer attack protection through stateful signatures and protocol anomaly detection for widely used Internet protocols such as the HyperText Transfer Protocol (HTTP), Simple Mail Transfer Protocol (SMTP), and FTP. Deep inspection is a subset of the Juniper Intrusion Detection and Prevention (IDP) suite of products and technologies. The ScreenOS ALG technology, on the other hand, provides application layer inspection of well-known Internet protocols such as the Session Initiation Protocol (SIP) and FTP that typically open data connections which require a secondary firewall session to be opened. Thus, ALGs typically open dynamic pinholes in the firewall, while supporting the associated network/port address translation, to allow data connections for such protocols.

11.1. View the List of Available ALGs

Problem

You want to view the list of available and enabled ALGs on a ScreenOS gateway.

Solution

Based on the release of ScreenOS, a number of ALGs are enabled in the factory default configuration. You can view the list of available ALGs on a ScreenOS gateway with the following code:

	Internal_fw-> get alg

To limit the output list to the ALGs that are enabled on the ScreenOS gateway, use the following syntax:

	Internal_fw-> get alg | include enabled

Discussion

Based on the release of ScreenOS, a number of ALGs are enabled in the factory default configuration. The list of ALGs available on the ISG-2000 platform as of ScreenOS 6.0r2 is:

	nsisg2000-> get alg
	DNS      ALG : enabled
	FTP      ALG : enabled 
	H323     ALG : enabled
	HTTP     ALG : enabled
	MGCP     ALG : enabled
	MSRPC    ALG : enabled
	PPTP     ALG : disabled
	REAL     ALG : enabled
	RSH      ALG : enabled
	RTSP     ALG : enabled
	SCCP     ALG : enabled
	SIP      ALG : enabled
	SQL      ALG : enabled
	SUNRPC   ALG : enabled
	TALK     ALG : enabled
	TFTP     ALG : enabled
	XING     ALG : enabled
	nsisg2000->

Table 11-1 briefly describes the applications representing the ALGs indicated in the preceding code snippet. In the table, the trigger port specifies the TCP or UDP destination port of the first packet in a flow that will activate ALG inspection of the entire conversation.

Table 11-1. ALG application detail

ALG name	Application name	Trigger port	Description
DNS	Domain Name System	UDP/53 and TCP/53	DNS queries ride on UDP/53 and return an IP address response when provided with a hostname. A DNS zone transfer uses TCP/53 and provides a response with zone files associated with a zone.
FTP	File Transfer Protocol	TCP/21	FTP, originally defined in RFC 959, uses TCP/21 on the server and a dynamic port on the client for the control channel. A separate data channel is dynamically opened in FTP applications. Active FTPs open the data channel from the server on source port TCP/20 to a dynamic port on the client. Passive FTPs open the data channel to a dynamic port on the server. RFC 3659 defines extensions to the FTP protocol.
H323	H.323	TCP/1720 for H.225 call control messages	H.323, based on the ITU-T Q.931 recommendation, is a suite of protocols used by audio and video communication sessions. IP telephony systems have used the H.225 component extensively for call control messages such as call setup and teardown.
HTTP	HyperText Transfer protocol	TCP/80	HTTP requests generated by web browers are provided HTTP responses from web servers with web content in formats such as HTML and XML. Standards, such as the HTTP/1.1 specification, define the list of permissible HTTP commands and their boundaries
MGCP	Media Gateway Control Protocol	UDP/2727 for MGCP-CA UDP/2427 for MGCP-UA	MGCP, defined in RFC 3435, is a control channel communications protocol between media gateways and call agents. A call agent is a controller device that sends commands to a media gateway.
MSRPC	Microsoft Remote Procedure Call	TCP/135 and UDP/135	Windows applications/services such as Microsoft Exchange and Active Directory use MS-RPC. A client requesting a connection to an MS-RPC application makes a call to the MS-RPC endpoint mapper on TCP/ UDP 135 and queries for the TCP/UDP port on which the application’s Universally Unique Identifier (UUID) is registered.
PPTP	Point-to-Point Tunneling Protocol	TCP/1723	PPTP, specified in RFC 2637, is a virtual private networking protocol that employs a control connection on TCP/1723 for session setup and a Generic Routing Encapsulation (GRE) tunnel for encapsulating the data payload.
REAL	Real Media	TCP/7070 and TCP/554	Real Media represents audio and/or video content streamed from a Real Networks RealServer that can be viewed and/or heard on a Real Player. Real’s Real Time Streaming Protocol (RTSP) connections use TCP/ 554 whereas Progressive Networks Audio (PNA) connections use TCP/7070.
RSH	Remote Shell	TCP/514	Remote Shell, available on Unix systems, is a tool that allows the execution of a command on a remote system.
RTSP	Real Time Streaming Protocol	TCP/554	RTSP, defined in RFC 2326, is a stateful streaming media control protocol that allows clients to request streaming content from servers. The streaming content is typically sent back over a Real-time Transport Protocol (RTP) stream over UDP, dynamically permitted by the ScreenOS RTSP ALG.
SCCP	Skinny Call Control Protocol	TCP/2000	SCCP is a proprietary call control protocol. The data connection opened for the voice bearer traffic is an RTP stream over UDP.
SIP	Session Initiation Protocol	UDP/5060	SIP, defined is RFC 3261, is a standards-based control protocol widely used by IP telephony vendors for setting up, modifying, and tearing down Voice over IP (VoIP) call sessions. Following session setup, the voice bearer traffic for SIP calls is typically communicated through an RTP over UDP stream.
SQL	Structured Query Language	TCP/1521	Oracle databases use SQLNetV2 and NET8. The ScreenOS SQLNetv2 ALG enables transparent connectivity between clients and Oracle databases.
SUNRPC	Sun Remote Procedure Call	TCP/111 and UDP/111	Unix hosts use Sun-RPC to execute code on other computers. Services on Unix hosts that rely on Sun-RPC use a well-known but unique program number as an identifier and register the dynamic TCP/UDP port they are listening on with the portmapper service on that host. The portmapper service runs on TCP/UDP 111.
TALK	Talk and NTalk	UDP/517-518	Talk and NTalk are client/server applications available on Unix systems for users to chat with each other. The Talk and NTalk server processes, respectively, listen on UDP 517 and UDP 518.
TFTP	Trivial File Transfer Protocol	UDP/69	TFTP servers provide a lightweight, UDP-based file-transfer mechanism.
XING	Xing StreamWorks	UDP/1558	Xing StreamWorks is a live audio/video streaming application. The Xing ALG permits a reverse connection from the StreamWorks server with the UDP content stream to the client.

As we will discuss in Recipe 11.5, in the context of the FTP protocol, you can modify the trigger port(s) for these ALGs by defining a custom service on the new trigger port(s) and mapping the ALG to the policy ID that references the custom service.

11.2. Globally Enable or Disable an ALG

Problem

You want to globally enable or disable an ALG on a ScreenOS gateway.

Solution

To enable an ALG that has been explicitly disabled in the device-specific configuration or is disabled in the default factory configuration, use the set alg <alg_name> enable command:

	Internal_fw-> set alg sip enable

You can globally disable an ALG by using the unset alg <alg_name> enable command. Hence, for instance, you disable the SIP ALG as follows:

	Internal_fw-> unset alg sip enable

Discussion

You may want to disable an ALG in the following cases:

You do not anticipate using the application associated with the specific ALG in your ScreenOS gateway environment. This ALG thus becomes a candidate to be globally disabled.
You are using a custom application that uses a TCP/UDP port that conflicts with the well-known application ports that are standard triggers for enabled ScreenOS ALGs. Based on policy ordering, you could selectively disable this ALG in a specific policy, as discussed in Recipe 11.3.
You are experiencing problems with an application that triggers the associated ALG but does not function correctly due to a difference in the application’s implementation and the ALG’s implementation of the protocol specification. You can thus disable the associated ALG in the specific policy, as discussed in Recipe 11.3.

The service associated with an ALG that has been disabled can continue to be used in a ScreenOS firewall policy. However, the trigger port associated with the ALG service no longer launches application layer inspection of the payload. Instead, the trigger port simply causes a stateful firewall session to be formed with standard TCP/UDP session state.

11.3. Disable an ALG in a Specific Policy

Problem

You want to disable an ALG in a specific ScreenOS policy.

Solution

You can disable an ALG in a specific policy by referencing the specific policy ID and using the application ignore qualifier:

	Internal_fw-> set policy id 5 from trust to untrust any any SIP
	permit log
	Internal_fw->set policy id 5 application ignore

Discussion

By disabling the SIP ALG on the policy identified in this recipe’s solution, the ScreenOS gateway creates a standard TCP/UDP stateful firewall session for traffic that references this policy. However, because the SIP ALG is disabled on this policy, the ScreenOS gateway does not open any dynamic pinholes to permit new inbound connections associated with this traffic stream.

11.4. View the Control and Data Sessions for an FTP Transfer

Problem

You want to view the control and data sessions associated with an FTP transfer.

Solution

Figure 11-1 shows the Orion host and the Phoenix FTP server communicating through the Internal_fw and External_fw gateways.

Figure 11-1. FTP ALG

The Internal_FW ScreenOS gateway has the following configuration, permitting FTP traffic from Orion to Phoenix:

	Internal_FW-> set address Trust orion 192.168.4.10/32
	Internal_FW-> set address Transit phoenix 192.168.9.30/32
	Internal_FW->set policy from Trust to Transit orion phoenix ftp
	permit log

Similarly, the External_FW ScreenOS gateway has the following configuration, permitting FTP traffic from Orion to Phoenix:

	External_FW-> set address Transit orion 192.168.4.30/32
	External_FW-> set address DMZ phoenix 192.168.9.10/32
	External_FW->set policy from Transit to DMZ orion phoenix FTP
	permit log

When an FTP session is initiated from Orion to Phoenix, the control (parent) session is viewed as follows on the Internal_FW ScreenOS gateway:

	Internal_FW-> get session src-ip 192.168.4.10 dst-ip 192.168.9.30
	dst-port 21

When Orion requests and starts to receive a file via an active FTP from Phoenix, a separate FTP data (child) session is opened on the firewalls. You can view this session as follows on the Internal_FW gateway:

	Internal_FW-> get session src-ip 192.168.9.30 dst-ip 192.168.4.10
	src-port 20

Discussion

FTP, originally defined in RFC 959, uses a separate control channel to initiate a session and a separate data channel to transfer files. The control channel listens on TCP/21 on the server while a client connecting to an FTP server initiates the connection using a dynamic source port above TCP/1024. The FTP client and the FTP server use the control channel to communicate with each other using a well-defined list of FTP commands, such as get to receive a particular file and put to upload a particular file.

There are two types of FTP sessions: active and passive.

Active FTPs open the data channel from the server on source port TCP/20 to a dynamic port on the client, often explicitly specified by the client through the PORT command. The ScreenOS FTP ALG parses the FTP stream and allows the FTP server to initiate a back connection from source port 20 to the client on this dynamic port.

A passive FTP session does not require a new connection to be initiated from an FTP server back to the client. Instead, the pasv command, when communicated by a client to an FTP server, instructs the server to start listening on a data port and communicate that port to the client. The client then opens the data channel to the server on this dynamic data port.

Here is the result of the get session command to display the control session on the Internal_FW gateway:

	Internal_FW-> get session src-ip 192.168.4.10 dst-ip 192.168.9.30
	dst-port 21
	alloc 2/max 16064, alloc failed 0, mcast alloc 0, di alloc failed 0
	total reserved 0, free sessions in shared pool 16062
	Total 1 sessions according filtering criteria.
	id 16061/s**,vsys 0,flag 08000040/0400/0001,policy 3,time 178, dip 0
	 module 0
	 if 11(nspflag 801801):192.168.4.10/1197->192.168.9.30/21,6,
	001125150ccd,sess token 4,vlan 0,tun 0,vsd 0,route 3
	 if 0(nspflag 801800):192.168.4.10/1197<-192.168.9.30/21,6,
	0014f6e21c4b,sess token 26,vlan 0,tun 0,vsd 0,route 7
	Total 1 sessions shown
	Internal_FW->

Here is a detailed view of this session:

	Internal_FW-> get session id 16061
	id 16061(00003ebd), flag 08000040/0400/0001, vsys id 0(Root)
	policy id 3, application id 1, dip id 0, state 0
	current timeout 1700, max timeout 1800 (second)
	status normal, start time 16964, duration 0
	session id mask 0, app value 0
	bgroup0(vsd 0): 192.168.4.10/1197->192.168.9.30/21, protocol 6
	session token 4 route 3
	  gtwy 192.168.9.30, mac 001125150ccd, nsptn info 0, pmtu 1500
	  flag 801801, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	ethernet0/0(vsd 0): 192.168.4.10/1197<-192.168.9.30/21, protocol 6
	session token 26 route 7
	  gtwy 192.168.7.2, mac 0014f6e21c4b, nsptn info 0, pmtu 1500
	mac 0014f6e21c4b, nsptn info 0
	  flag 801800, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	Internal_FW->

Active FTP

Here is the result of the get session command to display the data session for the active FTP on the Internal_FW gateway:

	Internal_FW-> get session src-ip 192.168.9.30 dst-ip 192.168.4.10
	src-port 20
	alloc 3/max 16064, alloc failed 0, mcast alloc 0, di alloc failed 0
	total reserved 0, free sessions in shared pool 16061
	Total 1 sessions according filtering criteria.
	id 16062/s**,vsys 0,flag 00001040/0800/0001,policy 3,time 180, dip 0
	module 0,parent 16061
	 if 0(nspflag 801801):192.168.9.30/20->192.168.4.10/1201,6,
	0014f6e21c4b,sess token 26,vlan 0,tun 0,vsd 0,route 7
	 if 11(nspflag 801800):192.168.9.30/20<-192.168.4.10/1201,6,
	001125150ccd,sess token 4,vlan 0,tun 0,vsd 0,route 3
	Total 1 sessions shown
	Internal_FW->

The session is viewed as follows:

	Internal_FW-> get session id 16062
	id 16062(00003ebe), flag 00001040/0800/0001, vsys id 0(Root)
	policy id 3, application id 0, dip id 0, state 0
	current timeout 1800, max timeout 1800 (second)
	status normal, start time 17163, duration 0
	session id mask 0, app value 0
	ethernet0/0(vsd 0): 192.168.9.30/20->192.168.4.10/1201, protocol 6
	 session token 26 route 7
	  gtwy 192.168.7.2, mac 0014f6e21c4b, nsptn info 0, pmtu 1500
	  flag 801801, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	bgroup0(vsd 0): 192.168.9.30/20<-192.168.4.10/1201, protocol 6
	session token 4 route 3
	  gtwy 192.168.9.30, mac 001125150ccd, nsptn info 0, pmtu 1500
	mac 001125150ccd, nsptn info 0
	  flag 801800, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	Internal_FW->

It should be noted that the application ID is set to 1 for the control session and to 0 for the data session as viewed in the detailed session outputs.

Furthermore, the following debug flow basic output shows the ScreenOS gateway attaching the FTP ALG when it sees the first TCP SYN in the three-way handshake for the control channel:

	Internal_FW-> get dbuf stream
	****** 17819.0: <Trust/bgroup0> packet received [48]******
	  ipid = 19652(4cc4), @035cb0b0
	  packet passed sanity check.
	  bgroup0:192.168.4.10/1228->192.168.9.30/21,6<Root>
	  no session found
	  flow_first_sanity_check: in <bgroup0>, out <N/A>
	  chose interface bgroup0 as incoming nat if.
	  flow_first_routing: in <bgroup0>, out <N/A>
	  search route to (bgroup0, 192.168.4.10->192.168.9.30) in vr trust-vr
	 for vsd-0/flag-0/ifp-null
	  [ Dest] 7.route 192.168.9.30->192.168.7.2, to ethernet0/0
	  routed (x_dst_ip 192.168.9.30) from bgroup0 (bgroup0 in 0) to
	ethernet0/0
	  policy search from zone 2-> zone 100
	 policy_flow_search policy search nat_crt from zone 2-> zone 100
	  RPC Mapping Table search returned 0 matched service(s) for (vsys
	Root, ip 192.168.9.30, port 21, proto 6)
	  No SW RPC rule match, search HW rule
	  Permitted by policy 3
	  No src xlate choose interface ethernet0/0 as outgoing phy if
	  no loop on ifp ethernet0/0.
	  session application type 1, name FTP, nas_id 0, timeout 1800sec
	ALG vector is attached
	  service lookup identified service 1.
	  flow_first_final_check: in <bgroup0>, out <ethernet0/0>
	  existing vector list 183-2afb2e4.
	<..additional output truncated..>

Farther down in the debug, when a pinhole is opened on the ScreenOS gateway to permit the data connection back from the Phoenix server to the Orion host for this active FTP session, the debug displays the data as follows:

	****** 17827.0: <Transit/ethernet0/0> packet received [48]******
	  ipid = 60396(ebec), @0345dbb0
	  packet passed sanity check.
	  ethernet0/0:192.168.9.30/20->192.168.4.10/1230,6<Root>
	  no session found
	  flow_first_sanity_check: in <ethernet0/0>, out <N/A>
	 vsd (0) is active, make hole active active hole found
	  existing vector list 183-2afb2e4.
	  flow_first_install_session======>
	<..additional output truncated..>

Passive FTP

Similar to the earlier active FTP scenario, the data channel for a passive FTP opens a new firewall session. However, this session, like the control session, is also initiated from the FTP client to the FTP server. On the other hand, as shown earlier, an active FTP’s data channel opens a back connection from the FTP server to the FTP client. Hence, for a passive FTP, the control and data session is seen as follows:

	Internal_FW-> get session src-ip 192.168.4.10 dst-ip 192.168.9.30
	alloc 4/max 16064, alloc failed 0, mcast alloc 0, di alloc failed 0
	total reserved 0, free sessions in shared pool 16060
	Total 2 sessions according filtering criteria.
	id 16060/s**,vsys 0,flag 00001040/0800/0001,policy 3,time 180, dip 0
	 module 0,parent 16061
	 if 11(nspflag 801801):192.168.4.10/2083->192.168.9.30/1183,6,
	001125150ccd,sess token 4,vlan 0,tun 0,vsd 0,route 3
	 if 0(nspflag 801800):192.168.4.10/2083<-192.168.9.30/1183,6,
	0014f6e21c4b,sess token 26,vlan 0,tun 0,vsd 0,route 8
	id 16061/s**,vsys 0,flag 08000040/0400/0001,policy 3,time 179,
	dip 0 module 0
	 if 11(nspflag 801801):192.168.4.10/2082->192.168.9.30/21,6,
	001125150ccd,sess token 4,vlan 0,tun 0,vsd 0,route 3
	 if 0(nspflag 801800):192.168.4.10/2082<-192.168.9.30/21,6,
	0014f6e21c4b,sess token 26,vlan 0,tun 0,vsd 0,route 8
	Total 2 sessions shown
	Internal_FW->

Here are the session details, with session id 16060 representing the passive FTP data session and session id 16061, with application id set to 1, representing the FTP control session:

	Internal_FW-> get session id 16060
	id 16060(00003ebc), flag 00001040/0800/0001, vsys id 0(Root)
	policy id 3, application id 0, dip id 0, state 0
	current timeout 1800, max timeout 1800 (second)
	status normal, start time 305, duration 0
	session id mask 0, app value 0
	bgroup0(vsd 0): 192.168.4.10/2083->192.168.9.30/1183, protocol 6
	session token 4 route 3
	  gtwy 192.168.9.30, mac 001125150ccd, nsptn info 0, pmtu 1500
	  flag 801801, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	ethernet0/0(vsd 0): 192.168.4.10/2083<-192.168.9.30/1183, protocol 6
	session token 26 route 8
	  gtwy 192.168.7.2, mac 0014f6e21c4b, nsptn info 0, pmtu 1500
	mac 0014f6e21c4b, nsptn info 0
	  flag 801800, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	Internal_FW->
	Internal_FW->
	Internal_FW-> get session id 16061
	id 16061(00003ebd), flag 08000040/0400/0001, vsys id 0(Root)
	policy id 3, application id 1, dip id 0, state 0
	current timeout 1720, max timeout 1800 (second)
	status normal, start time 305, duration 0
	session id mask 0, app value 0
	bgroup0(vsd 0): 192.168.4.10/2082->192.168.9.30/21, protocol 6
	session token 4 route 3
	  gtwy 192.168.9.30, mac 001125150ccd, nsptn info 0, pmtu 1500
	  flag 801801, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	ethernet0/0(vsd 0): 192.168.4.10/2082<-192.168.9.30/21, protocol 6
	session token 26 route 8
	  gtwy 192.168.7.2, mac 0014f6e21c4b, nsptn info 0, pmtu 1500
	mac 0014f6e21c4b, nsptn info 0
	  flag 801800, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	Internal_FW->

The control session is running on the standard control TCP port of 21 while the data session uses dynamic ports on the FTP client and the FTP server, for which the ScreenOS gateway FTP ALG opens dynamic pinholes. Furthermore, unlike the active FTP session, the passive FTP session, seen above, is originated from the client, Orion(192.168.4.10) to the server, Phoenix (192.168.9.30).

The debug flow basic output shows the FTP ALG attach itself to the stream:

	Internal_FW-> get dbuf stream
	****** 00305.0: <Trust/bgroup0> packet received [48]******
	  ipid = 28781(706d), @0357a0d0
	  packet passed sanity check.
	  bgroup0:192.168.4.10/2082->192.168.9.30/21,6<Root>
	  no session found
	  flow_first_sanity_check: in <bgroup0>, out <N/A>
	  chose interface bgroup0 as incoming nat if.
	  flow_first_routing: in <bgroup0>, out <N/A>
	  search route to (bgroup0, 192.168.4.10->192.168.9.30) in vr trust-vr
	for vsd-0/flag-0/ifp-null
	  [ Dest] 8.route 192.168.9.30->192.168.7.2, to ethernet0/0
	  routed (x_dst_ip 192.168.9.30) from bgroup0 (bgroup0 in 0) to
	ethernet0/0
	  policy search from zone 2-> zone 100
	 policy_flow_search policy search nat_crt from zone 2-> zone 100
	  RPC Mapping Table search returned 0 matched service(s) for (vsys
	Root, ip 192.168.9.30, port 21, proto 6)
	  No SW RPC rule match, search HW rule
	  Permitted by policy 3
	  No src xlate choose interface ethernet0/0 as outgoing phy if
	  no loop on ifp ethernet0/0.
	  session application type 1, name FTP, nas_id 0, timeout 1800sec
	ALG vector is attached
	  service lookup identified service 1.
	  flow_first_final_check: in <bgroup0>, out <ethernet0/0>
	 <Additional output truncated>

Finally,the pinholes opening for the passive FTP data session are seen in the debug flow basic output:

	****** 00305.0: <Trust/bgroup0> packet received [48]******
	  ipid = 28788(7074), @0357d8d0
	  packet passed sanity check.
	  bgroup0:192.168.4.10/2083->192.168.9.30/1183,6<Root>
	  no session found
	  flow_first_sanity_check: in <bgroup0>, out <N/A>
	 vsd (0) is active, make hole active active hole found
	  existing vector list 183-2aff464.
	  flow_first_install_session======>
	  flow got session.
	  flow session id 16060
	  tcp seq check.
	  Got syn, 192.168.4.10(2083)->192.168.9.30(1183), nspflag 0x801801,
	 0x800800
	  post addr xlation: 192.168.4.10->192.168.9.30.
	 flow_send_vector_, vid = 0, is_layer2_if=0
	 <Additional output truncated>

11.5. Configure ALG Support When Running FTP on a Custom Port

Problem

You want to configure ALG support for FTP sessions running on a custom port.

Solution

The following configuration enables you to configure FTP ALG support for an FTP server that is listening for control connections on TCP port 2021:

	Internal_FW-> set service Custom_FTP protocol tcp dst-port 2021-2021
	Internal_FW-> set policy id 3 from trust to transit orion phoenix
	Custom_FTP permit log
	Internal_FW->set policy id 3 application ftp

Discussion

Most FTP servers allow the capability of listening on a nonstandard control port other than TCP 21. When the policy associated with this nonstandard port is configured with the application ftp qualifier, as configured in the solution to this recipe, ScreenOS gateways dynamically open the pinholes for the data channel for such FTP sessions. Using this recipe’s solution as an example, you can inspect other ALG-supported applications on nonstandard, custom ports in a similar manner by creating a new service that references the custom port and then specifying the application name as a qualifier on the associated policy.

As a further example of the preceding solution, the following session details show an FTP session through the Internal_FW gateway between Orion and Phoenix, where Phoenix is running the FTP server on TCP 2021 and an active FTP is in progress whereby the data channel is opened as a back connection to the Orion host. The ScreenOS gateway allows this back connection to Orion through the FTP ALG associated with the policy. The control channel firewall session is thus seen as follows:

	Internal_FW-> get session src-ip 192.168.4.10 dst-ip 192.168.9.30
	dst-port 2021
	alloc 4/max 16064, alloc failed 0, mcast alloc 0, di alloc failed 0
	total reserved 0, free sessions in shared pool 16060
	Total 1 sessions according filtering criteria.
	id 16062/s**,vsys 0,flag 08000040/0400/0001,policy 7,time 167, dip 0
	module 0
	 if 11(nspflag 801801):192.168.4.10/1343->192.168.9.30/2021,6,
	001125150ccd,sess token 4,vlan 0,tun 0,vsd 0,route 3
	 if 0(nspflag 801800):192.168.4.10/1343<-192.168.9.30/2021,6,
	0014f6e21c4b,sess token 26,vlan 0,tun 0,vsd 0,route 6
	Total 1 sessions shown

	Internal_FW-> get session id 16062
	id 16062(00003ebe), flag 08000040/0400/0001, vsys id 0(Root)
	policy id 7, application id 1, dip id 0, state 0
	current timeout 1660, max timeout 1800 (second)
	status normal, start time 5104, duration 0
	session id mask 0, app value 0
	bgroup0(vsd 0): 192.168.4.10/1343->192.168.9.30/2021, protocol 6
	session token 4 route 3
	  gtwy 192.168.9.30, mac 001125150ccd, nsptn info 0, pmtu 1500
	  flag 801801, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	ethernet0/0(vsd 0): 192.168.4.10/1343<-192.168.9.30/2021, protocol 6
	session token 26 route 6
	  gtwy 192.168.7.2, mac 0014f6e21c4b, nsptn info 0, pmtu 1500
	mac 0014f6e21c4b, nsptn info 0
	  flag 801800, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	Internal_FW->

This detailed session id 16062 output specifies an application id of 1,indicating a match with the FTP ALG.

You can see the data session for this active FTP by searching for a session with a source IP of 192.168.9.30 initiating a connection back to 192.168.4.10:

	Internal_FW-> get session src-ip 192.168.9.30 dst-ip 192.168.4.10
	alloc 4/max 16064, alloc failed 0, mcast alloc 0, di alloc failed 0
	total reserved 0, free sessions in shared pool 16060
	Total 1 sessions according filtering criteria.
	id 16061/s**,vsys 0,flag 00001040/0800/0001,policy 7,time 180,
	dip 0 module 0,parent 16062
	 if 0(nspflag 801801):192.168.9.30/2020->192.168.4.10/1344,6,
	0014f6e21c4b,sess token 26,vlan 0,tun 0,vsd 0,route 6
	 if 11(nspflag 801800):192.168.9.30/2020<-192.168.4.10/1344,6,
	001125150ccd,sess token 4,vlan 0,tun 0,vsd 0,route 3
	Total 1 sessions shown
	Internal_FW->
	Internal_FW-> get session id 16061
	id 16061(00003ebd), flag 00001040/0800/0001, vsys id 0(Root)
	policy id 7, application id 0, dip id 0, state 0
	current timeout 1800, max timeout 1800 (second)
	status normal, start time 5104, duration 0
	session id mask 0, app value 19
	ethernet0/0(vsd 0): 192.168.9.30/2020->192.168.4.10/1344, protocol 6
	session token 26 route 6
	  gtwy 192.168.7.2, mac 0014f6e21c4b, nsptn info 0, pmtu 1500
	  flag 801801, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	bgroup0(vsd 0): 192.168.9.30/2020<-192.168.4.10/1344, protocol 6
	session token 4 route 3
	  gtwy 192.168.9.30, mac 001125150ccd, nsptn info 0, pmtu 1500
	mac 001125150ccd, nsptn info 0
	  flag 801800, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	Internal_FW->

Finally,you can execute a debug flow basic with a flow filter to look for an ALG match:

	Internal_FW-> get dbuf stream
	****** 05104.0: <Trust/bgroup0> packet received [48]******
	  ipid = 21852(555c), @035078d0
	  packet passed sanity check.
	  bgroup0:192.168.4.10/1343->192.168.9.30/2021,6<Root>
	  no session found
	  flow_first_sanity_check: in <bgroup0>, out <N/A>
	  chose interface bgroup0 as incoming nat if.
	  flow_first_routing: in <bgroup0>, out <N/A>
	< Additional_output_truncated>
	  Permitted by policy 7
	  No src xlate choose interface ethernet0/0 as outgoing phy if
	  no loop on ifp ethernet0/0.
	  session application type 1, name FTP, nas_id 0, timeout 1800sec
	ALG vector is attached
	  service lookup identified service 1.
	  flow_first_final_check: in <bgroup0>, out <ethernet0/0>
	 <Additional output truncated>

The preceding debug output shows an ALG match with session application type1, name FTP, attaching the FTP ALG to this flow on a nonstandard FTP control port.

Finally, you can view the control and data sessions associated with a passive FTP file transfer for this same nonstandard TCP/2021 FTP scenario:

	Internal_FW-> get session src-ip 192.168.4.10 dst-ip 192.168.9.30
	alloc 4/max 16064, alloc failed 0, mcast alloc 0, di alloc failed 0
	total reserved 0, free sessions in shared pool 16060
	Total 2 sessions according filtering criteria.
	id 16062/s**,vsys 0,flag 00001040/0800/0001,policy 7,time 180,
	dip 0 module 0,parent 16063
	 if 11(nspflag 801801):192.168.4.10/1377->192.168.9.30/1178,6,
	001125150ccd,sess token 4,vlan 0,tun 0,vsd 0,route 3
	 if 0(nspflag 801800):192.168.4.10/1377<-192.168.9.30/1178,6,
	0014f6e21c4b,sess token 26,vlan 0,tun 0,vsd 0,route 6
	id 16063/s**,vsys 0,flag 08000040/0400/0001,policy 7,time 174,
	dip 0 module 0
	 if 11(nspflag 801801):192.168.4.10/1376->192.168.9.30/2021,6,
	001125150ccd,sess token 4,vlan 0,tun 0,vsd 0,route 3
	 if 0(nspflag 801800):192.168.4.10/1376<-192.168.9.30/2021,6,
	0014f6e21c4b,sess token 26,vlan 0,tun 0,vsd 0,route 6
	Total 2 sessions shown
	Internal_FW->

Similar to the scenario of running a passive FTP on the standard TCP/21 port, you can see from the preceding session output that the control and the data sessions originate from the client Orion host. The application id 1 is seen attached to the control session:

	Internal_FW-> get session id 16063
	id 16063(00003ebf), flag 08000040/0400/0001, vsys id 0(Root)
	policy id 7, application id 1, dip id 0, state 0
	current timeout 1730, max timeout 1800 (second)
	<Additional Output Truncated>
	Internal_FW->

Finally, you can see the dynamic pinhole being opened to permit an outbound connection for the passive data channel from Orion to Phoenix via the debug flow basic output:

	Internal_FW-> get dbuf stream
	****** 06357.0: <Trust/bgroup0> packet received [48]******
	  ipid = 7893(1ed5), @0351f0d0
	  packet passed sanity check.
	  bgroup0:192.168.4.10/1377->192.168.9.30/1178,6<Root>
	  no session found
	  flow_first_sanity_check: in <bgroup0>, out <N/A>
	 vsd (0) is active, make hole active active hole found
	  existing vector list 183-2aff494.
	  flow_first_install_session======>
	  flow got session.
	  flow session id 16062
	  tcp seq check.
	  Got syn, 192.168.4.10(1377)->192.168.9.30(1178), nspflag 0x801801,
	 0x800800
	  post addr xlation: 192.168.4.10->192.168.9.30.
	 flow_send_vector_, vid = 0, is_layer2_if=0
	 <Additional Output Truncated>
	Internal_FW->

11.6. Configure and View ALG Inspection of a SIP-Based IP Telephony Call Session

Problem

You want to enable an IP telephony call session through a ScreenOS gateway using SIP.

Solution

As discussed in Recipe 11.1, the SIP ALG, along with several other ALGs, is enabled by default in current shipping releases of ScreenOS. Hence, the first permit security policy that matches the SIP trigger port of TCP or UDP 5060 triggers the SIP ALG.

Figure 11-2 shows a desktop PC running a SIP-based IP softphone at a branch location connecting to an integrated SIP server and media gateway at the corporate site over a site-to-site IP Security (IPSec) virtual private network (VPN).

Figure 11-2. SIP-based IP telephony call session

The SIP ALG is triggered by the following policy, which permits any traffic from the 192.168.4.0/24 segment to the 192.168.3.0/24 segment, when the softphone sends its initial SIP REGISTER message:

	Branch_External_fw-> set policy from Trust to Untrust 192.168.4.0
	192.168.3.0 any tunnel vpn branch_to_corporate log

Although the preceding policy shows the SIP ALG being triggered in the context of a “permit any service” IPSec VPN, a simple non-IPSec firewall policy that matches any service or explicitly references a SIP service will also trigger the SIP ALG in a similar manner.

You can view the current list of active SIP control traffic sessions on a ScreenOS gateway using the get session service sip command:

	Branch_External_fw-> get session service sip

Discussion

SIP, defined in RFC 3261,is a control protocol used extensively by IP telephony systems, ranging from Asterisk to various commercial implementations such as Avaya, for setting up, modifying, and tearing down VoIP call sessions. Following session setup, the voice bearer traffic for SIP calls is typically communicated through an RTP over UDP stream.

Although the SIP ALG is enabled by default in current, shipping releases of ScreenOS, you can confirm the status of the SIP ALG on your system with the get alg command, as discussed in Recipe 11.1. Hence, with the SIP ALG enabled, you can successfully establish a SIP-based VoIP call through a ScreenOS gateway that has a policy that permits SIP traffic between the SIP call initiator and the SIP server. More generically, a policy that permits any traffic between the zone of the SIP call initiator and the SIP gateway will automatically trigger the SIP ALG when SIP traffic is detected by the ScreenOS gateway and matches the permit of any security policy. Additionally, if the call recipient is an IP phone instead of a PSTN phone, the SIP call initiator and the recipient IP phone should have IP connectivity with each other for the voice bearer traffic to be transmitted back and forth between the two callers.

When the SIP softphone on 192.168.4.36 is started, it sends a SIP REGISTER message to the SIP server. The ScreenOS SIP ALG is triggered, per the policy specified in this recipe’s solution, and the associated session can thus be viewed:

	Branch_External_fw-> get session src-ip 192.168.4.36
	alloc 19/max 16064, alloc failed 0, mcast alloc 0, di alloc failed 0
	total reserved 0, free sessions in shared pool 16045
	Total 1 sessions according filtering criteria.
	id 16046/s**,vsys 0,flag 00000040/0000/0001,policy 17,time 5, dip 0
	module 0
	 if 11(nspflag 800e01):192.168.4.36/10720->192.168.3.10/5060,17,
	001125150ccd,sess token 4,vlan 0,tun 0,vsd 0,route 3
	 if 0(nspflag 2002e00):192.168.4.36/10720<-192.168.3.10/5060,17,
	000000000000,sess token 7,vlan 0,tun 40000009,vsd 0,route 17
	Total 1 sessions shown
	Branch_External_fw->

To view the processing of the SIP REGISTER packet, you can run the following debug commands and view the debug buffers:

	Branch_External_fw-> clear dbuf
	Branch_External_fw-> set ffilter src-ip 192.168.4.36
	Branch_External_fw-> set ffilter dst-ip 192.168.4.36
	Branch_External_fw-> debug flow basic
	Branch_External_fw-> debug sip all
	<Now launch the IP Softphone, which initializes and sends a SIP
	REGISTER>
	<Wait 5 seconds>
	Branch_External_fw-> get dbuf stream
	<Unrelated output deleted>
	****** 00252.0: <Trust/bgroup0> packet received [568]******
	  ipid = 50(0032), @035a1b50
	  packet passed sanity check.
	  bgroup0:192.168.4.36/10720->192.168.3.10/5060,17<Root>
	  no session found
	>Additional_Output_Truncated>
	  search route to (bgroup0, 192.168.4.36->192.168.3.10) in vr trust-vr
	for vsd-0/flag-0/ifp-null
	<Additional_Output_Truncated>
	  RPC Mapping Table search returned 0 matched service(s) for (vsys Root
	, ip 192.168.3.10, port 5060, proto 17)
	  No SW RPC rule match, search HW rule
	  Permitted by policy 17
	<Additional_Output_Truncated>
	 session application type 63, name SIP, nas_id 0, timeout 60sec
	ALG vector is attached
	  service lookup identified service 63.
	  flow_first_final_check: in <bgroup0>, out <ethernet0/0>
	  existing vector list 85-4b649e4.
	  Session (id:16046) created for first pak 85
	  flow_first_install_session======>
	<Additional_Output_Truncated>
	  flow session id 16046
	## 2007-09-12 01:23:44 : sip_alg.... packet received (192.168.4.36 -> 192.168.3.10)
	len=568
	## 2007-09-12 01:23:44 :             udp packet received
	(10720 -> 5060) len=540, cksum=0x00008977
	## 2007-09-12 01:23:44 : >>>>>>>>> RECV PACKET begin 540 bytes >>>>>>>
	## 2007-09-12 01:23:44 :             REGISTER sip:testdomain.local
	SIP/2.0
	## 2007-09-12 01:23:44 :             Via: SIP/2.0/UDP
	192.168.4.36:10720;
	<Additional_Output_Truncated>
	## 2007-09-12 01:23:44 :             CSeq: 1 REGISTER
	## 2007-09-12 01:23:44 :             Expires: 3600
	## 2007-09-12 01:23:44 :             Allow: INVITE, ACK, CANCEL,
	OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
	## 2007-09-12 01:23:44 :             User-Agent: X-Lite release
	1002tx stamp 29712
	## 2007-09-12 01:23:44 :             Content-Length: 0
	<Additional Output Truncated>
	Branch_External_fw->

This debug flow basic output shows the ScreenOS gateway triggering the SIP ALG with the session application type 63, name SIP output. Farther down in the debug output, the debug sip all shows the SIP REGISTER message that triggered the ALG.

Following successful SIP registration, the SIP phone initiates a call to an external PSTN phone number. This triggers a SIP INVITE message to the SIP server, which is also acting as the SIP proxy in this topology. Here is debug output of a sample SIP INVITE stream:

	Branch_External_fw-> clear dbuf
	Branch_External_fw-> set ffilter src-ip 192.168.4.36
	Branch_External_fw-> set ffilter dst-ip 192.168.4.36
	Branch_External_fw-> debug flow basic
	Branch_External_fw-> debug sip all
	 <Now, dial the external phone number on the SIP Soft Phone>
	Branch_External_fw-> get dbuf stream
	****** 00439.0: <Trust/bgroup0> packet received [1063]******
	  ipid = 264(0108), @035d8b50
	  packet passed sanity check.
	  bgroup0:192.168.4.36/10720->192.168.3.10/5060,17<Root>
	Not IKE nor NAT-T nor ESP protocol.
	  existing session found. sess token 4
	  flow got session.
	  flow session id 16046
	## 2007-09-12 01:26:51 : sip_alg.... packet received (192.168.4.36 -> 192.168.3.10)
	len=1063
	## 2007-09-12 01:26:51 :             udp packet received
	(10720 -> 5060) len=1035, cksum=0x0000f84c
	## 2007-09-12 01:26:51 : >>>>>>>>> RECV PACKET begin 1035 bytes >>>>>
	## 2007-09-12 01:26:51 :             INVITE sip:
	[email protected] SIP/2.0
	## 2007-09-12 01:26:51 :             Via: SIP/2.0/UDP
	192.168.4.36:10720;
	 <Additional_Output_Truncated>
	## 2007-09-12 01:26:51 :             CSeq: 1 INVITE
	## 2007-09-12 01:26:51 :             Allow: INVITE, ACK, CANCEL,
	OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
	## 2007-09-12 01:26:51 :             Content-Type: application/sdp
	## 2007-09-12 01:26:51 :             User-Agent: X-Lite release
	1002tx stamp 29712
	## 2007-09-12 01:26:51 :             Content-Length: 482<
	Additional Output Truncated>
	Branch_External_fw->

Finally, when a ringback is generated and the call recipient answers, the SIP ALG permits the RTP stream connection back from the media gateway to the SIP softphone. The associated session is seen as follows:

	Branch_External_fw-> get session dst-ip 192.168.4.36
	alloc 21/max 16064, alloc failed 0, mcast alloc 0, di alloc failed 0
	total reserved 0, free sessions in shared pool 16043
	Total 1 sessions according filtering criteria.
	id 16034/s**,vsys 0,flag 00001040/0000/0001,policy 17,time 12, dip 0
	module 1, resource 7-30-158
	 if 0(nspflag 2801):192.168.3.11/20040->192.168.4.36/63054,17,
	000000000000,sess token 7,vlan 0,tun 40000009,vsd 0,route 17
	 if 11(nspflag 800800):192.168.3.11/20040<-192.168.4.36/63054,17,
	001125150ccd,sess token 4,vlan 0,tun 0,vsd 0,route 3
	Total 1 sessions shown
	Branch_External_fw->

Also, while the SIP call is in progress, the SIP session and the forward session for the RTP stream from the SIP phone to the PSTN external phone can be viewed:

	Branch_External_fw-> get session src-ip 192.168.4.36 
	alloc 21/max 16064, alloc failed 0, mcast alloc 0, di alloc failed 0
	total reserved 0, free sessions in shared pool 16043
	Total 2 sessions according filtering criteria.
	id 16036/s**,vsys 0,flag 00001040/0000/0001,policy 17,time 12, dip 0
	module 1, resource 7-30-155
	 if 11(nspflag 800801):192.168.4.36/63055->192.168.3.11/20041,17,
	001125150ccd,sess token 4,vlan 0,tun 0,vsd 0,route 3
	 if 0(nspflag 2800):192.168.4.36/63055<-192.168.3.11/20041,17,
	000000000000,sess token 7,vlan 0,tun 40000009,vsd 0,route 17
	id 16046/s**,vsys 0,flag 00000040/0000/0001,policy 17,time 5, dip 0
	module 0
	 if 11(nspflag 800e01):192.168.4.36/10720->192.168.3.10/5060,17,
	001125150ccd,sess token 4,vlan 0,tun 0,vsd 0,route 3
	 if 0(nspflag 2002e00):192.168.4.36/10720<-192.168.3.10/5060,17,
	000000000000,sess token 7,vlan 0,tun 40000009,vsd 0,route 17
	Total 2 sessions shown
	Branch_External_fw->

The debug output for the response to the SIP INVITE with SIP 100 (Trying) and SIP 183 (Session Progress) status messages, followed by the ringback and the opening of the pinholes to permit the RTP stream, is viewed as follows:

	Branch_External_fw-> get dbuf stream
	## 2007-09-12 01:26:52 : sip_alg.... packet received (192.168.3.10 -> 192.168.4.36)
	len=428
	## 2007-09-12 01:26:52 :             udp packet received
	(5060 -> 10720) len=400, cksum=0x00009db3
	## 2007-09-12 01:26:52 : >>>>>>>>> RECV PACKET begin 400 bytes >>>>>>
	## 2007-09-12 01:26:52 :             SIP/2.0 100 Trying
	## 2007-09-12 01:26:52 :             Via: SIP/2.0/UDP
	192.168.4.36:10720;
	 <Additional_Output_Truncated>
	## 2007-09-12 01:26:52 : <<<<<<<<< RECV PACKET end <<<<<<<<<
	## 2007-09-12 01:26:52 : sip_alg.... Dialog dlg4B120F0 received
	provisional 100 (Trying)
	## 2007-09-12 01:26:52 :             open gates for peer resources
	## 2007-09-12 01:26:52 :             open pinhole for peer contact
	rsc 157
	## 2007-09-12 01:26:52 :             open pinhole for peer sdp
	rsc 158:159
	 <Additional_Output_Truncated>
	## 2007-09-12 01:26:52 : sip_alg.... Dialog dlg4B11EE8 sending
	provisional 100 (Trying)
	 <Additional_Output_Truncated>
	## 2007-09-12 01:26:54 : >>>>>>>>> RECV PACKET begin 739 bytes >>>>>>>
	## 2007-09-12 01:26:54 :             SIP/2.0 183 Session Progress
	## 2007-09-12 01:26:54 :             Via: SIP/2.0/UDP
	192.168.4.36:10720;
	 <Additional_Output_Truncated>
	## 2007-09-12 01:26:54 :             CSeq: 1 INVITE
	## 2007-09-12 01:26:54 :             Content-Type: application/sdp
	## 2007-09-12 01:26:54 :             Content-Length: 220
	 <Additional_Output_Truncated>
	## 2007-09-12 01:26:54 :             c=IN IP4 192.168.3.11
	## 2007-09-12 01:26:54 :             t=0 0
	## 2007-09-12 01:26:54 :             m=audio 20040 RTP/AVP 0 101
	 <Additional_Output_Truncated>
	Branch_External_fw->

Finally, the first RTP packet and the session creation for it are seen in the debug output:

	Branch_External_fw-> get dbuf stream
	****** 00442.0: <Trust/bgroup0> packet received [160]******
	  ipid = 267(010b), @035da350
	  packet passed sanity check.
	  bgroup0:192.168.4.36/63055->192.168.3.11/20041,17<Root>
	  no session found
	  flow_first_sanity_check: in <bgroup0>, out <N/A>
	 vsd (0) is active, make hole active active hole found
	## 2007-09-12 01:26:54 : sip_alg/rm callback code RM_HOLE_FIRST_HIT,
	 group 30
	  search route to (bgroup0, 192.168.4.36->192.168.3.11) in vr trust-vr
	for vsd-0/flag-0/ifp-null
	  [ Dest] 17.route 192.168.3.11->192.168.1.1, to ethernet0/0
	## 2007-09-12 01:26:54 : sip: [rm] change resource dst tunnel from
	policy 17
	  search route to (bgroup0, 192.168.4.36->192.168.3.11) in vr trust-vr
	for vsd-0/flag-0/ifp-null
	  [ Dest] 17.route 192.168.3.11-192.168.1.1, to ethernet0/0
	## 2007-09-12 01:26:54 : sip_alg/rm  callback code 37, group 30
	  existing vector list 5-4b64b4c.
	## 2007-09-12 01:26:54 : sip_alg/rm  callback code RM_HOLE_REMOVAL,
	group 30
	  flow_first_install_session======>
	  **** pak processing end.
	## 2007-09-12 01:26:54 : sip_alg/rm   callback code RM_HOLE_FIRST_HIT,
	group 30
	## 2007-09-12 01:26:54 : sip: [rm] change resource dst tunnel frompolicy 17
	## 2007-09-12 01:26:54 : sip_alg/rm callback code 37, group 30
	## 2007-09-12 01:26:54 : sip_alg/rm callback code RM_HOLE_REMOVAL,group 30
	****** 00442.0: <Trust/bgroup0> packet received [200]******
	  ipid = 268(010c), @035dab50
	  packet passed sanity check.
	  bgroup0:192.168.4.36/63054->192.168.3.11/20040,17<Root>
	Branch_External_fw->

You can terminate SIP sessions with the SIP BYE message, which is seen in the debug output:

	Branch_External_fw-> get dbuf stream
	****** 00582.0: <Trust/bgroup0> packet received [550]******
	  ipid = 7581(1d9d), @035cf350
	  packet passed sanity check.
	  bgroup0:192.168.4.36/10720->192.168.3.10/5060,17<Root>
	Not IKE nor NAT-T nor ESP protocol.
	  existing session found. sess token 4
	  flow got session.
	  flow session id 16046
	## 2007-09-12 01:29:14 : sip_alg.... packet received (192.168.4.36 -> 192.168.3.10)
	len=550
	## 2007-09-12 01:29:14 :             udp packet received (10720 -> 5060)
	len=522, cksum=0x00008cfb
	## 2007-09-12 01:29:14 : >>>>>>>>> RECV PACKET begin 522 bytes >>>>>>>
	## 2007-09-12 01:29:14 :             BYE sip:PSTN_PhoneNum@ 192.168.3.10:5060 SIP/2.0
	## 2007-09-12 01:29:14 :             Via: SIP/2.0/UDP
	192.168.4.36:10720;
	<Additional_Output_Truncated>
	## 2007-09-12 01:29:14 :             CSeq: 2 BYE
	## 2007-09-12 01:29:14 :             User-Agent: X-Lite release
	1002tx stamp 29712
	## 2007-09-12 01:29:14 :             Reason: SIP;description=
	"User Hung Up"
	## 2007-09-12 01:29:14 :             Content-Length: 0
	Branch_External_fw->

11.7. View SIP Call and Session Counters

Problem

You want to view the SIP call and session counters.

Solution

You can view the list of active SIP calls through a ScreenOS gateway using the get alg sip calls command:

	Branch_External_fw-> get alg sip calls

You can see the SIP session counters, specifying the number of instances of various SIP messages processed by the ScreenOS gateway, via the get alg sip counters command:

	Branch_External_fw-> get alg sip counters

Discussion

The active call state information for the SIP call in Recipe 11.6 is seen as follows:

	Branch_External_fw-> get alg sip calls
	   Total number of calls = 1 (# of call legs 2)
	-----------------------------
	   Call leg1: zone 2
	      UAS callid:760b194a0b6e9305MTIzOGE5ZjExZjJhZjIxM2ViNDFmNzRhOTIzNDc4ODM
	(pending tsx 0)
	      Local tag=192-nvs--1035999945990_2015289525-990
	      Remote tag=000b0075
	      State: STATE_ESTABLISHED
	   Call leg2: zone 1
	      UAC callid:760b194a0b6e9305MTIzOGE5ZjExZjJhZjIxM2ViNDFmNzRhOTIzNDc4ODM
	(pending tsx 0)
	      Local tag=000b0075
	      Remote tag=192-nvs--1035999945990_2015289525-990
	      State: STATE_ESTABLISHED
	Branch_External_fw->

Similarly, you can view the SIP counters output for the ScreenOS gateway configuration from Recipe 11.6 with the get alg sip counters command:

	Branch_External_fw-> get alg sip counters

	SIP message counters: T=Transmit, RT=Retransmit
	-------------------------------------------------
	   Method    T      1xx    2xx    3xx    4xx    5xx    6xx
	             RT     RT     RT     RT     RT     RT     RT
	     --------------------------------------------------------------
	   INVITE    1      2      1      0      0      0      0
	             0      0      0      0      0      0      0
	   CANCEL    0      0      0      0      0      0      0
	             0      0      0      0      0      0      0
	      ACK    1      0      0      0      0      0      0
	             0      0      0      0      0      0      0
	      BYE    0      0      0      0      0      0      0
	             0      0      0      0      0      0      0
	 REGISTER    1      0      1      0      0      0      0
	             0      0      0      0      0      0      0
	  OPTIONS    0      0      0      0      0      0      0
	             0      0      0      0      0      0      0
	     INFO    0      0      0      0      0      0      0
	             0      0      0      0      0      0      0
	  MESSAGE    0      0      0      0      0      0      0
	             0      0      0      0      0      0      0
	   NOTIFY    1      0      1      0      0      0      0
	             0      0      0      0      0      0      0
	    PRACK    0      0      0      0      0      0      0
	             0      0      0      0      0      0      0
	  PUBLISH    0      0      0      0      0      0      0
	             0      0      0      0      0      0      0
	    REFER    0      0      0      0      0      0      0
	             0      0      0      0      0      0      0
	 UBSCRIBE    2      0      1      0      1      0      0
	             0      0      0      0      0      0      0
	   UPDATE    0      0      0      0      0      0      0
	             0      0      0      0      0      0      0
	 BENOTIFY    0      0      0      0      0      0      0
	             0      0      0      0      0      0      0
	  SERVICE    0      0      0      0      0      0      0
	             0      0      0      0      0      0      0
	    OTHER    0      0      0      0      0      0      0
	             0      0      0      0      0      0      0

	SIP Error Counters
	-----------------------------
	   Total Pkt-in                       :13
	   Total Pkt dropped on error         :0
	   transaction error                  :0
	   call error                         :0
	   IP resolve error                   :0
	   NAT error                          :0
	   resource manager error             :0
	   RR header exceeded max             :0
	   Contact header exceeded max        :0
	   Invite Dropped due to call limit   :0
	   sip msg not processed by stack     :0
	   sip msg not processed by alg       :0
	   sip unknown method dropped         :0
	   sip decoding error                 :0
	   sip request for disconnected call  :0
	   sip request out of state           :0
	Branch_External_fw->

Finally, you can view the SIP ALG settings on the ScreenOS gateway with the get alg sip command:

	Branch_External_fw-> get alg sip
	SIP ALG                                    : enabled
	SIP ALG                                    : enabled
	Maximum number of SIP Calls                : 16
	Maximum Call Duration                      : 43200 seconds
	Inactive Media timeout                     : 120 seconds
	T1 interval                                : 500 milli seconds
	T4 interval                                : 5 seconds
	C interval                                 : 3 minutes
	 SIP hold retain resource                  : Disabled
	SIP Application Screen Configuration
	-------------------------------------
	 Unidentified messages in nat mode         : dropped
	 Unidentified messages in route mode       : dropped
	 SIP denial of service protect timeout     : 5
	 SIP global denial of service protect      : Disabled
	 SIP denial of service protect server IP   :
	Branch_External_fw->

11.8. View and Modify SIP ALG Settings

Problem

You want to view and modify the various settings associated with the SIP ALG in a ScreenOS gateway’s configuration.

Solution

The SIP ALG settings are viewed here:

	Branch_External_fw-> get alg sip setting

You can modify the various SIP ALG settings individually, as specified in the following Discussion section.

Discussion

Here are the default SIP ALG settings on an SSG-5 gateway running ScreenOS 6.0r2:

	Branch_External_fw-> get alg sip setting
	SIP ALG                                   : enabled
	Maximum number of SIP Calls               : 16
	Maximum Call Duration                     : 43200 seconds
	Inactive Media timeout                    : 120 seconds
	T1 interval                               : 500 milli seconds
	T4 interval                               : 5 seconds
	C interval                                : 3 minutes
	 SIP hold retain resource                 : Disabled
	SIP Application Screen Configuration
	-------------------------------------
	Unidentified messages in nat mode         : dropped
	Unidentified messages in route mode       : dropped
	SIP denial of service protect timeout     : 5
	SIP global denial of service protect      : Disabled
	SIP denial of service protect server IP   :
	Branch_External_fw->

These settings are modified as follows:

As discussed in Recipe 11.1 and Recipe 11.2, the SIP ALG is enabled by default globally. You can disable it accordingly:

	Branch_External_fw-> unset alg sip enable

The maximum number of SIP calls that a ScreenOS gateway can handle is a platform-specific limit that is currently not a configurable parameter.

The maximum call duration represents the period of time, in seconds, for which a SIP call can stay up through a ScreenOS gateway while there is no SIP signaling activity. You can modify the default value of 43, 200 seconds (12 hours) shown in the earlier code snippet to 10,800 seconds (3 hours) as follows:

	Branch_External_fw-> set alg sip signaling-inactivity-timeout 10800

The inactive media timeout represents the period of time, in seconds, for which a SIP call can stay up through a ScreenOS gateway while there is no bearer media traffic. You can modify the default value of 120 seconds to 60 seconds:

	Branch_External_fw-> set alg sip media-inactivity-timeout 60

The SIP T1 interval is an estimate of the round-trip time for SIP transactions. It is relevant, for instance, in the SIP INVITE transaction, which requires a three-way hand-shake between a client transaction and a server transaction when it occurs over an unreliable transport such as UDP. In such a scenario, the T1 timer determines the duration between the first SIP INVITE and a retransmission. You can modify the default T1 interval of 500 msec on a ScreenOS gateway using the set alg sip T1-interval <sec> command. The following command modifies the SIP T1 interval to 900 msec:

	Branch_External_fw-> set alg sip T1-interval 900

The SIP T4 interval represents the maximum amount of time that a SIP message can remain in the network. If a timer that is set to trigger in T4 seconds fires, the associated SIP transaction goes into a “terminated” state. You can modify the default T4 interval value of five seconds on a ScreenOS gateway using the set alg sip T4-interval <sec> command. The following command modifies the SIP T4 interval to 10 seconds:

	Branch_External_fw-> set alg sip T4-interval 10

The SIP Timer C represents the maximum duration for a SIP-proxied INVITE request to receive a final response. You can modify the default SIP C-Timeout value of three minutes on a ScreenOS gateway using the set alg sip <minutes> command. The following command modifies the SIP C-Timeout value to five minutes:

	Branch_External_fw-> set alg sip C-timeout 5

You can modify the setting to retain the ScreenOS resource manager (RM) resource during a call hold from the default disabled value:

	Branch_External_fw-> set alg sip hold-retain-resource

ScreenOS offers a SIP-specific Denial of Service (DoS) attack protection screen that you can enable globally or for specific SIP servers. The following command globally enables the DoS attack protection screen for SIP servers:

	Branch_External_fw-> set alg sip app-screen protect deny

You also can protect specific SIP servers against DoS attacks:

	Branch_External_fw-> set alg sip app-screen protect deny dst-ip
	192.168.3.10/32

Finally, ScreenOS gateways provide a setting to forward or drop SIP messages not recognized by the gateway to the SIP server. By default, unknown messages are dropped. You can permit these messages globally or specifically in NAT or route mode. The following command globally permits unknown SIP messages to SIP servers:

	Branch_External_fw-> set alg sip app-screen unknown-message permit

You can permit unknown SIP messages to SIP servers in route mode:

	Branch_External_fw-> set alg sip app-screen unknown-message routepermit

You also can permit unknown SIP messages to SIP servers in Network Address Translation (NAT) mode:

	Branch_External_fw-> set alg sip app-screen unknown-message nat permit

11.9. View the Dynamic Port(s) Associated with a Microsoft RPC Session

Problem

You want to view the dynamic TCP/UDP port associated with a Microsoft RPC firewall session.

Solution

Figure 11-3 shows a topology whereby a host running the Microsoft Outlook client is situated on the Desktops zone and needs to connect to a Microsoft Exchange Server located on the internal Trust zone.

Figure 11-3. Viewing MS-RPC ALG sessions

The following policy, using the MS-Exchange MS-RPC ALG, permits this connection:

	Inside_FW-> set policy id 19 from Desktops to Trust Outlook_Client
	Exchange_Server MS-EXCHANGE permit log

You can view the TCP/UDP ports associated with the MS-RPC MS-Exchange session using either of the following methods:

	Inside_FW-> get session service MS-EXCHANGE
	Inside_FW->get session src-ip 172.16.30.100 dst-ip 10.1.30.10

Discussion

As discussed in Recipe 7.15, Windows applications/services running on separate machines use MS-RPC to communicate with each other. The client application connects to the server on the MS-RPC Endpoint Mapper port (typically TCP/135) and specifies a UUID and version number. The server returns a response with the TCP/UDP port on which that UUID has registered itself. The client can then open a direct TCP/UDP connection to that port. The ScreenOS MS-RPC ALG tracks this entire communication stream, thus enabling the opening of the communication channel on the returned TCP/UDP port.

A sample set of MS-RPC sessions associated with this Microsoft Outlook to Microsoft Exchange communication for this recipe’s solution is as follows:

	Inside_FW-> get session src-ip 172.16.30.100 dst-ip 10.1.30.10
	alloc 16/max 4064, alloc failed 0, mcast alloc 0, di alloc failed 0
	total reserved 0, free sessions in shared pool 4048
	Total 3 sessions according filtering criteria.
	id 4006/s**,vsys 0,flag 08000040/0000/0001,policy 19,time 5, dip 0
	module 0, cid 125
	 if 7(nspflag 801801):172.16.30.100/2683->10.1.30.10/135,6,
	001125150ccd,sess token 14,vlan 0,tun 0,vsd 0,route 10
	 if 2(nspflag 801800):172.16.30.100/2683>-10.1.30.10/135,6,
	00132017f442,sess token 4,vlan 0,tun 0,vsd 0,route 3
	id 4021/s**,vsys 0,flag 08000040/0000/0001,policy 19,time 180,
	dip 0 module 0
	 if 7(nspflag 801801):172.16.30.100/2684->10.1.30.10/42124,6,
	001125150ccd,sess token 14,vlan 0,tun 0,vsd 0,route 10
	 if 2(nspflag 801800):172.16.30.100/2684>-10.1.30.10/42124,6,
	00132017f442,sess token 4,vlan 0,tun 0,vsd 0,route 3
	id 4030/s**,vsys 0,flag 08000040/0000/0001,policy 19,time 180, dip 0
	module 0
	 if 7(nspflag 801801):172.16.30.100/2686->10.1.30.10/42272,6,
	001125150ccd,sess token 14,vlan 0,tun 0,vsd 0,route 10
	 if 2(nspflag 801800):172.16.30.100/2686>-10.1.30.10/42272,6,
	00132017f442,sess token 4,vlan 0,tun 0,vsd 0,route 3
	Total 3 sessions shown
	Inside_FW->

All of the preceding three sessions match policy 19, the MS-Exchange MS-RPC policy defined in this recipe’s solution. The first session is an MS-RPC Endpoint Mapper session on TCP/135. The next two sessions connect to the dynamic TCP ports on which the MS-Exchange UUIDs have registered themselves.

A detailed view of session id 4006, the MS-RPC session, shows a match with application id 68, which is the application ID for the MS-RPC Endpoint Mapper:

	Inside_FW-> get session id 4006
	id 4006(00000fa6), flag 08000040/0000/0001, vsys id 0(Root)
	policy id 19, application id 68, dip id 0, state 0
	        cookie id 125
	current timeout 40, max timeout 60 (second)
	status normal, start time 4565, duration 0
	session id mask 0, app value 0
	ethernet2(vsd 0): 172.16.30.100/2683->10.1.30.10/135, protocol 6
	session token 14 route 10
	  gtwy 10.1.30.10, mac 001125150ccd, nsptn info 0, pmtu 1500
	  flag 801801, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	ethernet1(vsd 0): 172.16.30.100/2683->10.1.30.10/135, protocol 6
	session token 4 route 3
	  gtwy 172.16.30.100, mac 00132017f442, nsptn info 0, pmtu 1500
	mac 00132017f442, nsptn info 0
	  flag 801800, diff 0/0
	  port seq 0, subif 0, cookie 0, fin seq 0, fin state 0
	Inside_FW->

Finally,you can start a set of debug commands just before launching the Microsoft Outlook client to view the processing of the MS-RPC requests by the ScreenOS gateway:

	Inside_FW-> set ffilter src-ip 172.16.30.100
	Inside_FW-> set ffilter dst-ip 172.16.30.100
	Inside_FW-> debug flow basic
	Inside_FW-> debug rpc msrpc
	<Launch_MS_Outlook_client_and_wait_for_5_seconds>
	Inside_FW-> undebug all
	Inside_FW-> get dbuf stream
	****** 04557.0: <Desktops/ethernet2> packet received [48]******
	  ipid = 64215(fad7), @02633594
	  packet passed sanity check.
	  ethernet2:172.16.30.100/2680->10.1.30.10/135,6<Root>
	  no session found
	<Additional_Output_Truncated>
	  Permitted by policy 19
	<Additional_Output_Truncated>
	  session application type 68, name MSRPC_EPM, nas_id 0, timeout 60sec
	ALG vector is attached
	  service lookup identified service 68.
	<Additional_output_truncated>
	## 2007-09-12 13:30:21 : msrpc_co_parse_bind: EPM 3.0 interface UUID
	matched
	## 2007-09-12 13:30:21 : msrpc_co_parse_bind: version 3.0
	## 2007-09-12 13:30:21 : MSRPC_GET_UUID_STR: uuid
	8a885d04-1ceb-11c9-9fe8-08002b104860
	<Additional_output_truncated>
	## 2007-09-12 13:30:21 : msrpc_parse_tower: MSRPC_EPM_MAP_RQST
	## 2007-09-12 13:30:21 : msrpc_epm_parse_map_rqst: get ctx_hnd
	## 2007-09-12 13:30:21 : MSRPC_GET_UUID_STR: uuid
	00000000-0000-0000-0000-000000000000	
	## 2007-09-12 13:30:21 : msrpc_epm_parse_map_rqst: max_towers 4
	<Additional_Output_Truncated>

As the preceding output shows, the Outlook client initially triggers a request to the MS-RPC Endpoint Mapper on the server on TCP/135. This request triggers the MS-RPC ALG on the ScreenOS gateway that maps this request as application type 68 (MS-RPC Endpoint Mapper).

Farther down in the debug stream, the Outlook client makes several more requests to the MS-RPC Endpoint Mapper and the Exchange server responds back with the TCP port on which the specific UUID has registered itself. This is followed by a connection from the Outlook client to the Exchange server on that TCP port, dynamically permitted by the ScreenOS gateway and viewable in the session table:

	Inside_FW-> get dbuf stream
	## 2007-09-12 13:30:29 : MSRPC_GET_UUID_STR:
	uuid f5cc5a18-4264-101a-8c59-08002b2f8426
	<Additional_Output_Truncated>
	## 2007-09-12 13:30:29 : MSRPC_GET_UUID_STR: uuid
	8a885d04-1ceb-11c9-9fe8-08002b104860
	<Additional_Output_Truncated>
	## 2007-09-12 13:30:29 : msrpc_parse_tower: TCP port 135
	<Additional_Output_Truncated>
	## 2007-09-12 13:30:29 : msrpc_parse_tower: MSRPC_EPM_MAP_RQST
	## 2007-09-12 13:30:29 : msrpc_epm_parse_map_rqst: get ctx_hnd
	## 2007-09-12 13:30:29 : MSRPC_GET_UUID_STR:
	uuid 00000000-0000-0000-0000-000000000000
	## 2007-09-12 13:30:29 : msrpc_epm_parse_map_rqst: max_towers 4
	<Additional_Output_Truncated>
	****** 04565.0: <Trust/ethernet1> packet received [192]******
	  ipid = 22678(5896), @0264bd94
	  packet passed sanity check.
	  ethernet1:10.1.30.10/135->172.16.30.100/2683,6<Root>
	  existing session found. sess token 4
	  flow got session.
	  flow session id 4006
	## 2007-09-12 13:30:29 : msrpc_alg_handler: existing cookie
	(id 125) found
	<Additional_Output_Truncated>
	## 2007-09-12 13:30:29 : msrpc_epm_parse_map_resp: ctx_hnd
	## 2007-09-12 13:30:29 : MSRPC_GET_UUID_STR: uuid
	00000000-0000-0000-0000-000000000000
	## 2007-09-12 13:30:29 : msrpc_epm_parse_map_resp: n_towers 1
	<Additional_Output_Truncated>
	## 2007-09-12 13:30:29 : msrpc_parse_tower: ip 10.1.30.10 xlated to
	10.1.30.10
	<Additional_Output_Truncated>
	## 2007-09-12 13:30:29 : MSRPC_GET_UUID_STR: uuid
	f5cc5a18-4264-101a-8c59-08002b2f8426
	<Additional_Output_Truncated>
	## 2007-09-12 13:30:29 : MSRPC_GET_UUID_STR: uuid
	8a885d04-1ceb-11c9-9fe8-08002b104860
	<Additional_Output_Truncated>
	## 2007-09-12 13:30:29 : msrpc_parse_tower: TCP port 42124
	<Additional_Output_Truncated>
	## 2007-09-12 13:30:29 : msrpc_parse_tower: MSRPC_EPM_MAP_RESP
	## 2007-09-12 13:30:29 : msrpc_epm_parse_map_resp: rcode 0
	<Additional_Output_Truncated>
	****** 04565.0: <Desktops/ethernet2> packet received [48]******
	  ipid = 64239(faef), @0264c594
	  packet passed sanity check.
	  ethernet2:172.16.30.100/2684->10.1.30.10/42124,6<Root>
	  no session found
	<Additional_Output_Truncated>
	  RPC Mapping Table search returned 1 matched service(s) for (vsys
	Root, ip 10.1.30.10, port 42124, proto 6)
	  first RPC service matched: uid -2147483641(0x-2147483641)
	  SW RPC Rule Table match: uid -2147483641(0x80000007), polid id 19,
	index 10
	  Permitted by policy 19
	<Additional_output_truncated>
	Inside_FW->

11.10. View the Dynamic Port(s) Associated with a Sun-RPC Session

Problem

You want to view the dynamic TCP/UDP port associated with a Sun-RPC firewall session.

Solution

Figure 11-4 shows a topology whereby a host on the Trust zone of the Inside_FW firewall mounts an exported filesystem from an NFS server running on the Unix Server located on the DMZ zone.

Figure 11-4. Viewing Sun-RPC ALG sessions

The following policies, using the Sun-RPC-Mounted and Sun-RPC-NFS services that rely on the Sun-RPC ALG, permit this connection:

	Inside_FW-> set policy id 86 from Trust to DMZ NFS_Client Unix_Server
	SUN-RPC-MOUNTD permit log
	Inside_FW->set policy id 87 from Trust to DMZ NFS_Client Unix_Server
	SUN-RPC-NFS permit log

The TCP/UDP ports associated with the NFS Mount session are seen here:

	Inside_FW-> get session src-ip 192.168.99.212 dst-ip 172.30.0.46

Discussion

As discussed in Recipe 7.16, services on Unix hosts that rely on Sun-RPC use a well-known but unique program number as an identifier and register the dynamic TCP/UDP port they are listening on with the portmapper service on that host. The portmapper service runs on TCP/UDP 111.

Hence, a client application that needs to connect to a Sun-RPC service, such as the NFS daemon, first contacts the portmapper service on the server with the particular program number. The portmapper service returns the TCP/UDP port associated with the program number. Then, the client application connects to the service on the specific TCP/UDP port number. The ScreenOS Sun-RPC services have the pre-defined, well-known program numbers for several applications, such as NFS. The ScreenOS Sun-RPC ALG dynamically opens pinholes to permit connections to the TCP or UDP ports on which the service has registered itself.

A sample set of the Sun-RPC sessions associated with the NFS_Client mounting an exported volume on the NFS server on the Unix server via Sun-RPC calls for this recipe’s solution is as follows:

	Inside_FW-> get session src-ip 192.168.99.212
	alloc 14/max 16064, alloc failed 0, mcast alloc 0, di alloc failed 0
	total reserved 0, free sessions in shared pool 16050
	Total 5 sessions according filtering criteria.
	id 16040/s**,vsys 0,flag 00000000/0000/0001,policy 86,time 179, dip 2
	module 0
	 if 11(nspflag 800801):192.168.99.212/879->172.30.0.46/32850,17,
	000c29af1410,sess token 4,vlan 0,tun 0,vsd 0,route 5
	 if 5(nspflag 800800):172.30.0.1/1128<-172.30.0.46/32850,17,
	00c09f2575ec,sess token 20,vlan 0,tun 0,vsd 0,route 1
	id 16044/s**,vsys 0,flag 00000000/0000/0001,policy 86,time 179, dip 2
	module 0, cid 128
	 if 11(nspflag 800801):192.168.99.212/32771->172.30.0.46/111,17,
	000c29af1410,sess token 4,vlan 0,tun 0,vsd 0,route 5
	 if 5(nspflag 800800):172.30.0.1/1125<-172.30.0.46/111,17,
	00c09f2575ec,sess token 20,vlan 0,tun 0,vsd 0,route 1
	id 16047/s**,vsys 0,flag 00000000/0000/0001,policy 87,time 239, dip 2
	module 0
	 if 11(nspflag 800801):192.168.99.212/32771->172.30.0.46/2049,17,
	000c29af1410,sess token 4,vlan 0,tun 0,vsd 0,route 5
	if 5(nspflag 800800):172.30.0.1/1126<-172.30.0.46/2049,17,
	00c09f2575ec,sess token 20,vlan 0,tun 0,vsd 0,route 1
	id 16050/s**,vsys 0,flag 00000000/0000/0001,policy 87,time 239, dip 2
	module 0
	 if 11(nspflag 800801):192.168.99.212/681->172.30.0.46/2049,17,
	000c29af1410,sess token 4,vlan 0,tun 0,vsd 0,route 5
	if 5(nspflag 800800):172.30.0.1/1129>-172.30.0.46/2049,17,
	00c09f2575ec,sess token 20,vlan 0,tun 0,vsd 0,route 1
	id 16051/s**,vsys 0,flag 00000000/0000/0001,policy 86,time 179, dip 2
	 module 0
	if 11(nspflag 800801):192.168.99.212/32771-<172.30.0.46/32850,17,
	000c29af1410,sess token 4,vlan 0,tun 0,vsd 0,route 5
	if 5(nspflag 800800):172.30.0.1/1127>-172.30.0.46/32850,17,
	00c09f2575ec,sess token 20,vlan 0,tun 0,vsd 0,route 1
	Total 5 sessions shown
	Inside_FW->

All five of the sessions shown here match policies 86 and 87, which rely on the Sun-RPC ALG to open ports.

In the following debug output, the NFS_Client system makes a portmapper call to the Unix_Server system on UDP/111, and supplies a program number of 100003 (NFS) and gets a port response of UDP/2049, to which it initiates a connection:

	Inside_FW-> set ffilter src-ip 192.168.99.212 dst-ip 172.30.0.46
	Inside_FW-> set ffilter src-ip 172.30.0.46 dst-ip 192.168.99.212
	Inside_FW-> debug flow basic
	Inside_FW-> debug rpc all
	Inside_FW-> get dbuf stream
	****** 01179.0: <Trust/bgroup0> packet received [84]******
	<Additional_Output_Truncated>
	  bgroup0:192.168.99.212/32771->172.30.0.46/111,17<Root>
	  no session found
	<Additional_Output_Truncated>
	## 2007-09-17 15:30:26 : rpc_map_search: search for (0, 172.30.0.46,
	 111, 17)
	  RPC Mapping Table search returned 0 matched service(s) for (vsys
	Root, ip 172.30.0.46, port 111, proto 17)
	<Additional_Output_Truncated>
	  Permitted by policy 86
	<Additional_Output_Truncated>
	  session application type 5, name PORTMAPPER, nas_id 0, timeout
	1800sec
	ALG vector is attached
	  service lookup identified service 5.
	<Additional_Output_Truncated>
	  flow session id 16044
	## 2007-09-17 15:30:26 : sunrpc_alg_handler: new cookie (id 128)
	created<Additional_Output_Truncated>
	## 2007-09-17 15:30:26 : sunrpc_alg_msg_handler: rpcbind ver 2,
	rpcbind proc 3
	<Additional_Output_Truncated>
	## 2007-09-17 15:30:26 : sunrpc_alg_rpcbind_v2_call_handler: GETPORT
	call, prog 100003, ver 3, proto 17, port 0
	## 2007-09-17 15:30:26 : sunrpc_alg_udp_handler: created hole for udp
	client
	  post addr xlation: 172.30.0.1->172.30.0.46.
	<Additional_Output_Truncated>
	## 2007-09-17 15:30:26 : sunrpc_alg_rpcbind_v2_reply_handler: GETPORT
	reply, port 2049
	## 2007-09-17 15:30:26 : rpc_map_insert: insert the following map:
	## 2007-09-17 15:30:26 : rpc_map_print_map: 0, 172.30.0.46, 2049, UDP,
	Program: 100003
	<Additional_Output_Truncated>
	****** 01179.0: <Trust/bgroup0> packet received [68]******
	<Additional_Output_Truncated>
	  bgroup0:192.168.99.212/32771->172.30.0.46/2049,17<Root>
	<Additional_Output_Truncated>
	## 2007-09-17 15:30:26 : rpc_map_search: search for (0, 172.30.0.46,
	2049, 17)
	## 2007-09-17 15:30:26 : rpc_map_search: found Sun RPC program: 100003
	(0x186a3)
	<Additional_Output_Truncated>
	  RPC Mapping Table search returned 1 matched service(s) for (vsys
	Root, ip 172.30.0.46, port 2049, proto 17)
	  first RPC service matched: uid 100003(0x100003)
	  SW RPC Rule Table match: uid 100003(0x186a3), polid id 87, index 25
	  Permitted by policy 87
	<Additional_Output_Truncated>
	  Session (id:16047) created for first pak 1
	<Additional_Output_Truncated>
	Inside_FW->

Next, the NFS_Client system makes a portmapper call to the Unix_Server system on UDP/111, and supplies a program number of 100005 (mountd daemon) and gets a port response of UDP/32850, to which it initiates a connection:

	Inside_FW->
	****** 01179.0: <Trust/bgroup0> packet received [84]******
	<Additional_Output_Truncated>
	  bgroup0:192.168.99.212/32771->172.30.0.46/111,17<Root>
	<Additional_Output_Truncated>
	  flow got session.
	  flow session id 16044
	<Additional_Output_Truncated>
	## 2007-09-17 15:30:26 : sunrpc_alg_rpcbind_v2_call_handler: GETPORT
	call, prog 100005, ver 3, proto 17, port 0
	<Additional_Output_Truncated>
	## 2007-09-17 15:30:26 : sunrpc_alg_rpcbind_v2_reply_handler: GETPORT
	reply, port 32850
	## 2007-09-17 15:30:26 : rpc_map_insert: insert the following map:
	## 2007-09-17 15:30:26 : rpc_map_print_map: 0, 172.30.0.46, 32850,
	UDP, Program: 100005
	<Additional_Output_Truncated>
	****** 01179.0: <Trust/bgroup0> packet received [68]******
	<Additional_Output_Truncated>
	  bgroup0:192.168.99.212/32771->172.30.0.46/32850,17<Root>
	<Additional_Output_Truncated>
	## 2007-09-17 15:30:26 : rpc_map_search: search for (0, 172.30.0.46,
	32850, 17)
	## 2007-09-17 15:30:26 : rpc_map_search: found Sun RPC program:
	100005(0x186a5)
	<Additional_Output_Truncated>
	  RPC Mapping Table search returned 1 matched service(s) for (vsys
	Root, ip 172.30.0.46, port 32850, proto 17)
	  first RPC service matched: uid 100005(0x100005)
	  SW RPC Rule Table match: uid 100005(0x186a5), polid id 86, index 24
	  Permitted by policy 86
	<Additional_Output_Truncated>
	Inside_FW->

Hence,these outputs illustrate the Sun-RPC ALG enabling the opening of dynamic connections for Sun-RPC services such as NFS.

Table of Contents for 11. Application Layer Gateways

Create new playlist

Sign In

Sign Up

Chapter 11. Application Layer Gateways

11.0. Introduction

Differences Between ALGs and Deep Inspection

11.1. View the List of Available ALGs

Problem

Solution

Discussion

See Also

11.2. Globally Enable or Disable an ALG

Problem

Solution

Discussion

See Also

11.3. Disable an ALG in a Specific Policy

Problem

Solution

Discussion

See Also

11.4. View the Control and Data Sessions for an FTP Transfer

Problem

Solution

Discussion

Active FTP

Passive FTP

See Also

11.5. Configure ALG Support When Running FTP on a Custom Port

Problem

Solution

Discussion

See Also

11.6. Configure and View ALG Inspection of a SIP-Based IP Telephony Call Session

Problem

Solution

Discussion

See Also

11.7. View SIP Call and Session Counters

Problem

Solution

Discussion

See Also

11.8. View and Modify SIP ALG Settings

Problem

Solution

Discussion

See Also

11.9. View the Dynamic Port(s) Associated with a Microsoft RPC Session

Problem

Solution

Discussion

See Also

11.10. View the Dynamic Port(s) Associated with a Sun-RPC Session

Problem

Solution

Discussion

See Also

Table of Contents for
11. Application Layer Gateways