I am in the process of installing a 4215 using 2 different inline pairs.
I have a reverse-proxy server on one tier of a firewall protected by 1 inline pair which then redirects traffic back through the IPS and the firewall to the web servers on a web tier (seperate interface on the firewall) and through the IPS again on a different inline interface pair.
For some reason, when I set the IPS to inspect (on or auto) the setup doesn't work. The IPS isn't reporting any blocked traffic or denies or events. I can go directly to the web servers and that works. As soon as I set the IPS to BYPASS all traffic the setup works.
I havent' installed a license on the IPS because I am still waiting for it from Cisco but I believe that the setup should work without it, unless I am mistaken???
Does anyone know what the problem could be? Could it be related to the reverse-rpoxy receiving traffic and the forwarding the traffic back through the IPS?
I have done more testing and determined that this only stops working if I assign both interface pairs to the same virtual sensor. However the 4215 can only have 1 virtual sensor. Has anyone else experienced this type of problem?
Okay i guess this is the solution. To just check if this is what we are hitting on. Don't Bypass your traffic just disable your normaliser engine, and check if all your intended traffic is working fine.
If this solves then we are hitting on a known issue.
If you are running 5.1, then the Normalizer may be denying packets if the TACACS packets have to go through both interface pairs.
The Normalizer gets confused when the same packet is being seen twice, especially when a firewall may be modifying the packet. The Normalizer can get confused trying to track the tcp sequence numbers. It is not recommend monitoring 2 interface pairs in 5.1 if some of the same traffic has to flow through both pairs.
If the 6.0 sensor does not support virtualization (like the IDS-4215), then there is a new option in 6.0 "inline-TCP-session-tracking-mode". Set this option to "interface-and-vlan". This way the sensor will track traffic on each interface pair independantly in order to prevent most normalizer issues.
You might even try setting up an event action override for the produce-alert event action for risk rating range 1-100 and trying the "show events" again. There are a few signatures that don't create alerts by default (intentionally), but will create alerts with the event-action override. You can see if maybe one of these is being triggered.
(Remember to turn off the produce-alert event action override when you are done diagnosing. Many of the signatures that don't produce an alert by default can be very noisy as they monitor for normal traffic, and are juts peices/components of a Meta Signature that is looking for the actual attack itself)
This post credit should go to Marcbal. I am sure it would solve your problem. I expierenced this a few days ago.
Table of ContentsIntroductionVersion HistoryPossible Future
UpdatesDocuments PurposeNAT Operation in ASA 8.3+ SectionsRule Types
Network Object NATTwice NAT / Manual NATRule Types used per SectionNAT
Types used with Twice NAT / Manual NAT and Network Obje...
Table of Contents Introduction:This document describes details on how
NAT-T works. Background: ESP encrypts all critical information,
encapsulating the entire inner TCP/UDP datagram within an ESP header.
ESP is an IP protocol in the same sense that TCP an...