IPS 5.0 4215 traffic traversing multiple inline pairs - problem.

[JOSH GANT]

All,

I have a customer with a PIX515 with a DMZ interface, and I set up the 4215 IPS 5.0(5) to be inline between the PIX and the DMZ switch and between the PIX and the internal switch.

In this configuration, traffic that traverses only one of the two inline pairs (inside <-> outside, outside <-> dmz) works fine. Traffic that traverses both (inside <-> dmz) does not go through very well. Getting to the webserver in the DMZ from the inside is very slow and doesn't always load.

If I remove one of the inline pairs from the vitual sensor, everything works fine. I have disabled all sigs, so this does not seem to be a sig issue.

[marcabal]

The Pix will ususally do TCP sequence number randomization.

So the packet will be modified by the Pix as it passes through.

The sensor is seeing both the original and the modified packet. So the sensor thinks something weird is happening on the network and will generally not pass through the modified packet. If you do a "show stat virtualSensor" at the bottom you would likely see a lot of 1330 alarms firing.

Another possibility is the limited performance of the IDS-4215. Depending on your network load you may be overloading the IDS-4215 when trying to monitor both segments.

Execute "show interfaces" and see if the Drop Percentage is above 1. A drop percentage of 1 or higher indicates that the sensor is over subscribed.

[JOSH GANT]

I was getting many 1308's (TTL Evasion) and the default action included manipulating the packet. That was part of the problem. I did not have any 1330's.

I am having another problem now that I think has to do with a lack of license being on the box. I will put a 30 day license on it tomorrow and check the interfaces for drops.

It sounds like with inline mode the box can only eat packets in one direction: packet enters the pair on the first interface, and the packet is blocked from leaving the second interface. Not bidirectionaly. I noticed that if both pairs passed the traffic in the same direction (1st interface in, 2nd interface out) that is when I had the problems. If I turned one pair around the traffic flowed fine.

[marcabal]

Go ahead and disable 1308. It is detecting the changes in the TTL of the packets. In your situation this is normal because the firewall is reducing the TTL by one. So this signature should just be disabled.

The license only affects whether or not a signature update can be installed.

The sensor itself should run fine with a license.

If the interface is dropping packets then the sensor is over subscribed. This has nothing to do with the license. It woudl mean you are sending too much traffic to the sensor for analysis.

(Note: When a packet is dropped because of a signature then we term this a deny. The interface counters won't show number of denied packets. The number of denied packets will be show in "show stat virtualsensor". The drop percentage in "show interface" is for packets that were dropped because the sensor was to busy and not able to analyze them.)

Not sure what you mean by "can only eat packets in one direction". The order of the interfaces and direction of the packets should make no difference to the sensor.

Assume you have 2 pairs of inline interfaces. Fe1/0 paired with Fe1/1, and Fe1/2 paired with Fe1/3. Any packets entering Fe1/0 will be analyzed and either denied by a signature or sent out Fe1/1. Any packets entering Fe1/1 will be analyzed and either denied by a signature or sent out Fe1/0.

Similar things happen for Fe1/2 and Fe1/3.

Swapping the wires for Fe1/0 and Fe1/1, or swapping the wires of Fe1/2 and Fe1/3 won't make any difference to the sensor software.

Swapping the pair of wires on Fe1/0 and Fe1/1 with the wires on the pair Fe1/2 and Fe1/3 won't make any difference the sensor software either.

The only way that swapping wires would make a difference is if you swap Fe1/0 or Fe1/1 wire with a wire on Fe1/2 or Fe1/3. Because then your wire pairs would not be correct.

OR you have a hardware problem. One of the ports on the card itself is bad, or one of the wires you are using is bad.

[JOSH GANT]

Thanks for the help. 1308 is disabled.

"In inline mode, a packet comes in through the first interface of the pair on the sensor and out the second interface of the pair. The packet is sent to the second interface of the pair unless that packet is being denied or modified by a signature."

http://www.cisco.com/univercd/cc/td/doc/product/iaabu/csids/csids11/idmguide/dminter.htm#wp1032013

I took that to mean that the interfaces are unique within the pair. That the first interface in the pair must be the first interface traffic enters in order for it to be denied.

[marcabal]

I see where the confusion came from.

It should have said something like.. a packet comes in through ONE OF THE interfaces of the pair on the sensor, and is sent out the OTHER interface of the pair. The packet is sent to the OTHER interface of the pair unless that packet is being denied or modified by a signature.

Packets will flow bi-directionally across the interface pair, and can be denied in either direction.

The sensor doesn't really care which interface is first in the pair and which is second.

The packets entering the first interface will go out the second interface (unless denied).

AND packets entering the second interface will go out the first interface (unless denied).

The sensor won't differentiate between the 2 interfaces. It treats them both equally.

[JOSH GANT]

Thanks again. That is good to know going forward.

It looks like there is a hardware problem with this 4215. TAC noticed an odd XML error in the output of a show ver that indicates a bad harddrive(?).

Hopefully this issue will be resolved with a new box.