IDSM-2 Inline Vlan Pair - Duplicate Packets

[Farrukh Haroon]

Dear All

We have a setup where two IDSM-2 modules are ether-channeled together in a single 6513 Chassis.

There is an FWSM module also, which acts as the default gateway for all internal VLANs.

Problem: IDSM show stat virtual-sensor command is showing tons of 'Duplicate Packets'

show statistics virtual-sensor | inc Duplic

Duplicate Packets = 2950967

Inline TCP Tracking Mode: Interface and VLAN

Topology:

Assume Client VLAN = 10 and Server VLAN = 60

IPS Inline VLAN Pairs:

------------------------

10 >> 110 (Client VLAN)

60 >> 160 (Server VLAN)

Client >> Server Flow: (Layer 2):

--------------------------------

[ClientPC] >>>> Access Switch (VLAN 10) >>>> Core SW >>>> IDSM-2 (VLAN 10--110 Pair) >>>> Core Sw >>>> FWSM VLAN 110 >>>>

FWSM VLAN 160 >>>> Core Sw >>>> IDSM-2 (VLAN 160--60 Pair) >>>> Server Switch (VLAN 60) >>>> [Server]

Core Switch IPS Etherchannel Setup:

-----------------------------------

Group 5: IDSM(A) and IDSM(B) Port x/7

Group 6: IDSM(A) and IDSM(B) Port x/8

Some VLAN Pair(s) are on interface x/7 and others are on x/8

Because of the above issue, we see a lot of TCP normalization signatures being fired (as the IPS gets confused with duplicate packets seen for the same flow). Specially signatures 1330:12 :17 and :18.

It is also causing some applications to break (e.g. Veritas Netbackup 6.5). When I removed the DENY action from these signatures, our IPS started having stability issues (This could also be due to E3 upgrade)

Should we change the Tracking mode to 'VLAN' only, OR any other possible solution?. Should not the 'interface and vlan' setting be sufficient?.

Regards

Farrukh

[marcabal]

Do you have just the 2 vlan pairs?

If so I would recommend creating 2 virtual sensors and placing a pair in each virtual sensor.

If you have 4 vlan pairs, then you can still separate a vlan pair per virtual sensor.

If you have more than 4 vlan pairs, then using "interface and vlan" as the tracking mode should work.

If problems are still happening, then you may need to look more closely at your network. Ensure that asymetric traffic is not being seen.

See if you can create a TCP connetion that will trigger the problem signatures, and then on the sensor capture the packets for the connection to see what packets get sent to the sensor to determine if the sensor is receiving what you would expect.

[Farrukh Haroon]

Hello Marcoa

Thanks a lot for your reply.

We have 18+ VLAN Pairs. I just took one client/server pair as an example. But as I mentioned before, these VLAN pairs are divided into two separate sub-interfaces. I was thinking of having one ether-channel group instead of two, as per your recommendation in another thread. This way the two interfaces of both IDSM(s) (four in total) will be part of the same etherchannel.

I doubt there is any asymmetric traffic, as core switches + fwsm(s) + second layer firewalls etc. all running in active/standby mode.

Wireshark captures show a lot of 'Out of Order' packets/segements or Duplicate packets, I forgot the exact word (they are highlighted in black).

Any other ideas?

Regards

Farrukh

[Farrukh Haroon]

Hello Marco

Can you please comment on the above.

Actually we never knew we had a duplicate packets problem, everything seemed to work fine (since about 2 years). Recently we installed (or upgraded) the Veritas Netbackup 6.5 software, and the TCP normalization signatures started firing (specially for large transfers). The backups started failing and we noticed the problem.

The signatures that are going off are 1330 (sub-sig 12,17,18) and 1300:0.

Regards

Farrukh

[marcabal]

This will take some traffic analysis to determine what is going wrong.

You might need to place a sniffer to watch the traffic on the client where the backup software is running at the same time that you capture the traffic on the sensor.

Look to see if there are any differences in the traffic.

Look for any anomalies in the traffic.

Look to see if maybe the backup software is not using a standard TCP connection (is it jumping the tcp sequence numbers in any abnormal way?)

You might also try some things on the sensor to determine if the sensor itself might have an issue.

Determine if the connction passes through 2 connections (inline vlan pairs) monitored by the sensor.

If you can, you might try removing both of the pairs from the virtual sensor. (don't delete the pairs, just remove them from the virtual sensor so they won't be analyzed)

And see if the backup works.

If it does then just add in one pair, and see if it keeps working.

If it has errors with just the one pair, then the problem is likely not because of the connection being monitored twice.

Something else must be weird about the connection.

If the problems are only seen when having both pairs in the same virtual sensor, then try placing the pairs in different virtual sensors and see if the problem goes away.

If the problem goes away when in different virtual sensors, then there may be an error in the inline tcp session tracking code that should track connections separately for each interface/vlan.