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.
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.
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
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.
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.
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
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.
You want to disable an ALG in a specific ScreenOS policy.
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
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.
Figure 11-1 shows the Orion host and the Phoenix FTP server communicating through the Internal_fw
and External_fw
gateways.
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
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 0if 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 0bgroup0(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 0ethernet0/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->
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 16061if 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 0ethernet0/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 0bgroup0(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..>
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 16061if 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 0if 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 0bgroup0(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 0ethernet0/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 0bgroup0(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 0ethernet0/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>
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
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 0if 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 0bgroup0(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 0ethernet0/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 16062if 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 19ethernet0/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 0bgroup0(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 16063if 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 0if 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->
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).
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
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 0if 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-158if 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-155if 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 0if 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 dlg4B11EE8sending 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->
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
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->
You want to view and modify the various settings associated with the SIP ALG in a ScreenOS gateway’s configuration.
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.
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
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.
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
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 125if 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 0if 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 0if 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> sessionapplication type 68, name MSRPC_EPM,
nas_id 0, timeout 60secALG 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->
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.
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
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 0if 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 128if 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 0if 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 0if 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 0if 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 25Permitted 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 24Permitted 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.