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?.
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.
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).
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.
We have configured the outside and inside Interface with official ipv6 adresses, set a default route on outside Interface to our router, we also have definied a rule , which also gets hits, to permit tcp from inside Interface to any6.
In Syslog I also se...