Verifying the Output of ALG Sessions
This section contains examples of successful output from ALG sessions and information on system log configuration. You can compare the results of your sessions to check whether the configurations are functioning correctly.
FTP Example
This example analyzes the output during an active FTP session. It consists of four different flows; two are control flows and two are data flows. The example consists of the following parts:
Sample Output
The following is a complete sample output from the show services stateful-firewall conversations application-protocol ftp operational mode command:
user@host>show services stateful-firewall conversations
application-protocol ftpInterface: ms-1/3/0, Service set: CLBJI1-AAF001
Conversation: ALG protocol: ftp
Number of initiators: 2, Number of responders: 2
Flow State Dir Frm count
TCP 1.1.79.2:14083 -> 2.2.2.2:21 Watch I 13
NAT source 1.1.79.2:14083 -> 194.250.1.237:50118
TCP 1.1.79.2:14104 -> 2.2.2.2:20 Forward I 3
NAT source 1.1.79.2:14104 -> 194.250.1.237:50119
TCP 2.2.2.2:21 -> 194.250.1.237:50118 Watch O 12
NAT dest 194.250.1.237:50118 -> 1.1.79.2:14083
TCP 2.2.2.2:20 -> 194.250.1.237:50119 Forward O 5
NAT dest 194.250.1.237:50119 -> 1.1.79.2:14104
For each flow, the first line shows flow information, including protocol (TCP), source address, source port, destination address, destination port, flow state, direction, and frame count.
- The state of a flow can be Watch, Forward, or Drop:
- A Watch flow state indicates that the control flow is monitored by the ALG for information in the payload. NAT processing is performed on the header and payload as needed.
- A Forward flow forwards the packets without monitoring the payload. NAT is performed on the header as needed.
- A Drop flow drops any packet that matches the 5 tuple.
- The frame count (Frm count) shows the number of packets that were processed on that flow.
The second line shows the NAT information.
- source indicates source NAT.
- dest indicates destination NAT.
- The first address and port in the NAT line are the original address and port being translated for that flow.
- The second address and port in the NAT line are the translated address and port for that flow.
FTP System Log Messages
System log messages are generated during an FTP session. For more information about system logs, see System Log Messages.
The following system log messages are generated during creation of the FTP control flow:
- Rule Accept system log:Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_RULE_ACCEPT: proto 6 (TCP) application: ftp, fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, Match SFW accept rule-set:, rule: ftp, term: 1
- Create Accept Flow system log:Oct 27 11:42:54 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_CREATE_ACCEPT_FLOW: proto 6 (TCP) application: ftp, fe-3/3/3.0:1.1.1.2:4450 -> 2.2.2.2:21, creating forward or watch flow
- System log for data flow creation:Oct 27 11:43:30 (FPC Slot 1, PIC Slot 1) {ss_ftp}[FWNAT]: ASP_SFW_FTP_ACTIVE_ACCEPT: proto 6 (TCP) application: ftp, so-2/1/2.0:2.2.2.2:20 -> 1.1.1.2:50726, Creating FTP active mode forward flow
Analysis
Control Flows
The control flows are established after the three-way handshake is complete.
- Control flow from FTP client to FTP server. TCP destination
port is 21.
TCP 1.1.79.2:14083 -> 2.2.2.2:21 Watch I 13 NAT source 1.1.79.2:14083 -> 194.250.1.237:50118 - Control flow from FTP server to FTP client. TCP source
port is 21.
TCP 2.2.2.2:21 -> 194.250.1.237:50118 Watch O 12 NAT dest 194.250.1.237:50118 -> 1.1.79.2:14083
Data Flows
A data port of 20 is negotiated for data transfer during the course of the FTP control protocol. These two flows are data flows between the FTP client and the FTP server:
TCP 1.1.79.2:14104 -> 2.2.2.2:20 Forward I 3
NAT source 1.1.79.2:14104 -> 194.250.1.237:50119
TCP 2.2.2.2:20 -> 194.250.1.237:50119 Forward O 5
NAT dest 194.250.1.237:50119 -> 1.1.79.2:14104
Troubleshooting Questions
- How do I know if the FTP ALG is active?
- The ALG protocol field in the conversation should display ftp.
- There should be a valid frame count (Frm count) in the control flows.
- A valid frame count in the data flows indicates that data transfer has taken place.
- What do I need to check if the FTP connection is established
but data transfer does not take place?
- Most probably, the control connection is up, but the data connection is down.
- Check the conversations output to determine whether both the control and data flows are present.
- How do I interpret each flow? What does each flow mean?
- FTP control flow initiator flow—Flow with destination port 21
- FTP control flow responder flow—Flow with source port ;21
- FTP data flow initiator flow—Flow with destination port 20
- FTP data flow responder flow—Flow with source port 20
RTSP ALG Example
The following is an example of an RTSP conversation. The application uses the RTSP protocol for control connection. Once the connection is set up, the media is sent using UDP protocol (RTP).
This example consists of the following:
Sample Output
Here is the output from the show services stateful-firewall conversations operational mode command:
user@host# show services stateful-firewall conversationsInterface: ms-3/2/0, Service set: svc_set Conversation: ALG protocol: rtsp Number of initiators: 5, Number of responders: 5 Flow State Dir Frm count TCP 1.1.1.3:58795 -> 2.2.2.2:554 Watch I 7 UDP 1.1.1.3:1028 -> 2.2.2.2:1028 Forward I 0 UDP 1.1.1.3:1029 -> 2.2.2.2:1029 Forward I 0 UDP 1.1.1.3:1030 -> 2.2.2.2:1030 Forward I 0 UDP 1.1.1.3:1031 -> 2.2.2.2:1031 Forward I 0 TCP 2.2.2.2:554 -> 1.1.1.3:58795 Watch O 5 UDP 2.2.2.2:1028 -> 1.1.1.3:1028 Forward O 6 UDP 2.2.2.2:1029 -> 1.1.1.3:1029 Forward O 0 UDP 2.2.2.2:1030 -> 1.1.1.3:1030 Forward O 3 UDP 2.2.2.2:1031 -> 1.1.1.3:1031 Forward O 0
Analysis
An RTSP conversation should consist of TCP flows corresponding to the RTSP control connection. There should be two flows, one in each direction, from client to server and from server to client:
TCP 1.1.1.3:58795 -> 2.2.2.2:554 Watch I 7 TCP 2.2.2.2:554 -> 1.1.1.3:58795 Watch O 5
- The RTSP control connection for the initiator flow is sent from destination port 554.
- The RTSP control connection for the responder flow is sent from source port 554.
The UDP flows correspond to RTP media sent over the RTSP connection.
Troubleshooting Questions
- Media does not work when the RTSP ALG is configured. What
do I do?
- Check RTSP conversations to see whether both TCP and UDP flows exist.
- The ALG protocol should be displayed as rtsp.
Note: The state of the flow is displayed as Watch, because the ALG processing is taking place and the client is essentially “watching” or processing payload corresponding to the application. For FTP and RTSP ALG flows, the control connections are always Watch flows.
- How do I check for ALG errors?
- You can check for errors by issuing the following command.
Each ALG has a separate field for ALG packet errors.
user@host# show services stateful-firewall statistics extensiveInterface: ms-3/2/0 Service set: svc_set New flows: Accepts: 1347, Discards: 0, Rejects: 0 Existing flows: Accepts: 144187, Discards: 0, Rejects: 0 Drops: IP option: 0, TCP SYN defense: 0 NAT ports exhausted: 0 Errors: IP: 0, TCP: 276 UDP: 0, ICMP: 0 Non-IP packets: 0, ALG: 0 IP errors: IP packet length inconsistencies: 0 Minimum IP header length check failures: 0 Reassembled packet exceeds maximum IP length: 0 Illegal source address: 0 Illegal destination address: 0 TTL zero errors: 0, Illegal IP protocol number (0 or 255): 0 Land attack: 0 Non-IPv4 packets: 0, Bad checksum: 0 Illegal IP fragment length: 0 IP fragment overlap: 0 IP fragment reassembly timeout: 0 Unknown: 0 TCP errors: TCP header length inconsistencies: 0 Source or destination port number is zero: 0 Illegal sequence number and flags combinations: 0 SYN attack (multiple SYN messages seen for the same flow): 276 First packet not a SYN message: 0 TCP port scan (TCP handshake, RST seen from server for SYN): 0 Bad SYN cookie response: 0 UDP errors: IP data length less than minimum UDP header length (8 bytes): 0 Source or destination port number is zero: 0 UDP port scan (ICMP error seen for UDP flow): 0 ICMP errors: IP data length less than minimum ICMP header length (8 bytes): 0 ICMP error length inconsistencies: 0 Duplicate ping sequence number: 0 Mismatched ping sequence number: 0 ALG errors: BOOTP: 0, DCE-RPC: 0, DCE-RPC portmap: 0 DNS: 0, Exec: 0, FTP: 0 ICMP: 0 Login: 0, NetBIOS: 0, NetShow: 0 RPC: 0, RPC portmap: 0 RTSP: 0, Shell: 0 SNMP: 0, SQLNet: 0, TFTP: 0 Traceroute: 0
- You can check for errors by issuing the following command.
Each ALG has a separate field for ALG packet errors.
System Log Messages
Enabling system log generation and checking the system log are also helpful for ALG flow analysis. This section contains the following:
System Log Configuration
You can configure the enabling of system log messages at a number of different levels in the Junos OS CLI. As shown in the following sample configurations, the choice of level depends on how specific you want the event logging to be and what options you want to include. For details on the configuration options, see the Junos OS System Basics Configuration Guide (system level) or the Junos Services Interfaces Configuration Release 12.3 (all other levels).
- At the topmost global level:user@host# show system syslogfile messages {any any;}
- At the service set level:user@host# show services service-set svc_setsyslog {host local {services any;}}stateful-firewall-rules allow_rtsp;interface-service {service-interface ms-3/2/0;}
- At the service rule level:user@host# show services stateful-firewall rule allow_rtspmatch-direction input-output;term 0 {from {applications junos-rtsp;}then {accept;syslog;}}
System Log Output
System log messages are generated during flow creation, as shown in the following examples:
The following system log message indicates that the ASP matched an accept rule:
For a complete listing of system log messages, see the Junos OS System Log Messages Reference.
