Cisco Intrusion Prevention System

Inline TCP Session Tracking Mode on IPS

Document ID: 116077

Updated: Apr 25, 2013

Contributed by Todd Pula, Cisco TAC Engineer.



This document describes the Inline TCP Session Tracking feature of the Intrusion Prevention System (IPS) appliance.



Cisco recommends that you have knowledge of these topics:

  • IPS 4200 series appliances configured with inline interfaces.
  • Knowledge of TCP protocol and traffic flows.

Components Used

The information in this document is based on:

  • IPS 4270 with software Release 7.1(7)

The information in this document was created from the devices in a specific lab environment. All of the devices used in this document started with a cleared (default) configuration.  If your network is live, make sure that you understand the potential impact of any command.


Refer to Cisco Technical Tips Conventions for information on document conventions.

Background Information

In certain inline IPS deployment scenarios, packets from a TCP stream can be seen twice by the Normalizer engine, which results in drops because of improper stream tracking. This situation is typically seen when traffic is routed through multiple virtual local area networks (VLANs) or interface pairs that are monitored by a single virtual sensor. This issue is further complicated by the necessity to allow asymmetric traffic to merge for proper stream tracking when the traffic for either direction is received from different VLANs or interfaces.

Network Diagram



In this network topology, a client on the inside network initiates an HTTP connection to the server on the outside network. Both network segments are separated by an Adaptive Security Appliance (ASA) firewall. In this design, a single IPS appliance is configured to tap into both the inside and outside VLANs with two sets of inline interface pairs. When the client initiates the session to the server, the TCP SYN (synchronize) packet takes this path (outbound stream) through the IPS and ASA:

Client > IPS G3/0 > vs0 > IPS G3/1 > ASA G0/0 > ASA G0/1 > IPS G3/2 > vs0 > IPS G3/3 > Server

After the outbound stream, the TCP SYN sent by the client is seen by the vs0 virtual sensor as the packet traverses the inside interface pair towards the ASA's inside interface and again when the packet traverses the outside interface pair towards the web server.  In a symmetric scenario, the same situation occurs in the return path with the SYN ACK (a positive acknowledgement) and subsequent packets from the web server.  When the IPS attempts to combine the streams into a single TCP connection, duplicates of every packet in the connection are observed, which results in a confused Normalizer and dropped packets.  In order to confirm whether an IPS encounters this situation, the output of the show stat virt command shows a large number of 1330 TCP Normalizer signatures that fire, as well as a large number of modified and denied packets and connections.


The Inline TCP Session Tracking Mode option can be used to overcome situations such as this.  There are three possible modes that can be configured:

  1. Virtual Sensor (Default Setting) - Monitors in an asymmetric deployment situation where client packets are seen on one inline pair, while server packets are seen on a second interface pair.  The two interface pairs must be monitored together to see both sides of the connection.
  2. Interface and VLAN - This is a workaround to the example topology shown in this document, in which two or more inline interface pairs are assigned to the same virtual sensor.  With this option enabled, a TCP connection may traverse more than one pair, which allows the Normalizer to track TCP sessions independently for each inline pair.
  3. VLAN Only - This is a very rare combination of the first two options and is used you monitor a combination of multiple asymmetric networks.  VLAN 1 on the left interface pair has client packets and must be combined with VLAN 1 on the right interface pair, which has the server packets.  In this case, traffic is aggregated across all interface pairs, but is segregated by VLAN.  For example, VLAN 1 packets across all interfaces are placed together; VLAN 2 packets from all interfaces are placed together, but VLAN 1 and VLAN 2 packets are never placed together for TCP session tracking. 

For the above example topology, there are two ways that the problem can be resolved:

Solution 1

Move each inline interface pair into its own virtual sensor. For example, one pair on vs0 and one pair on vs1.  This method is generally recommended when there are less than four inline pairs (because of the platform limit of four virtual sensors).  The Normalizer treats the duplicate streams as two separate connections.

Solution 2

Configure the inline TCP Session Tracking Mode to Interface and VLAN. This method is recommended when there are more than four inline pairs, in which case, you are forced to place multiple inline pairs into a single virtual sensor.  The Normalizer treats packets on different inline pairs as completely different connections within the same virtual sensor.


Here is the configuration to separate virtual sensor per inline interface pair:

IPS4510-01# conf t

IPS4510-01(config)# service analysis-engine

IPS4510-01(config-ana)# virtual-sensor vs0

IPS4510-01(config-ana-vir)# logical-interface To-ASA-Inside subinterface-number 0

IPS4510-01(config-ana-vir)# exit

IPS4510-01(config-ana)# virtual-sensor vs1

IPS4510-01(config-ana-vir)# logical-interface To-ASA-Outside subinterface-number 0

IPS4510-01(config-ana-vir)# exit

IPS4510-01(config-ana)# exit

IPS4510-01(config)# exit

Here is the configuration for the interface and VLAN:

IPS4510-01# config t

IPS4510-01(config)# service analysis-engine

IPS4510-01(config-ana)# virtual-sensor vs0

IPS4510-01(config-ana-vir)# inline-tcp-session interface-and-vlan

IPS4510-01(config-ana-vir)# exit

IPS4510-01(config-ana)# exit

Apply Changes?[yes]: yes

Warning: Change of TCP session tracking mode will not take effect until restart.

IPS4510-01(config)# exit

IPS4510-01# reset


  • Use the show stat virt | b TCP Normalizer stage statistics command and review for Dropped, Duplicate, Denied, or SendAck Packets Sent non-zero statistics in the TCP Normalizer.
  • Use the show stat virt | b Per-Signature SigEvent count command and review for 1330 signatures that have fired in conjunction with the TCP Normalier statistics from the previous command.

Related Information

Updated: Apr 25, 2013
Document ID: 116077