topic Re: TCP flow get slower with IPS 4255 5.1(3) in inline mode in Network Security

TCP flow get slower with IPS 4255 5.1(3) in inline mode

csiszerakos2 — Sun, 10 Mar 2019 10:10:59 GMT

I have an IPS 4255 with 5.1(3).

The logical setup is the following:

Internet

ServerA --- IPS --- PIX --- IPS --- ServerB

The physical setup is the following:

ServerA --- SwitchA --- IPS --- SwitchB --- PIX --- Internet

ServerB ---/

(ServerA and ServerB are in different DMZs -> in different VLAN-s)

My goal is to protect many segments by one inline IPS, therefore the connection

between SwitchA and SwitchB is an ethernet trunk (for performance reasons this is

an etherchannel trunk (load sharing is src-dst-ip)).

The problem is that ServerA and ServerB have to communicate, and this is done via the PIX.

The communication is very slow and there are many fired TCP Drop and TCP normalization related

signatures. When the IPS is in bypass on mode or one of ther server segment is not watched by the

IPS the communcation speed is ok. I think the speed degradation is because every packet between ServerA and

ServerB travels through the IPS twice. It seems to me that altough they are in seperate VLANs the IPS can not handle

them.

Has someone idea how to solve this issue?

Re: TCP flow get slower with IPS 4255 5.1(3) in inline mode

jwalker — Wed, 23 Aug 2006 19:34:04 GMT

I had this problem on a few sensors before. I recommend creating filters for these signatures or disabling them. We eventually disabled most of them because they were generating massive false positives and were causing too much latency.

Re: TCP flow get slower with IPS 4255 5.1(3) in inline mode

csiszerakos2 — Fri, 25 Aug 2006 12:53:08 GMT

Thank you. I have tried to switch off all of the signatures, but it does not help, the latency still exists.

Re: TCP flow get slower with IPS 4255 5.1(3) in inline mode

jwalker — Fri, 25 Aug 2006 13:28:04 GMT

One thing you can do to verify that for sure the sensor's analysis engine is giving you headaches is put the sensor in Bypass Mode. This essentially turns the sensor into a wire and bypasses all inspection. If the latency goes away, then you know the problem is the sensor.

Re: TCP flow get slower with IPS 4255 5.1(3) in inline mode

csiszerakos2 — Sun, 27 Aug 2006 15:09:21 GMT

I put he sensor into bypass mode on, and the latency disappeared. But the IPS worth nothing in bypass mode on. 😞

I have contacted the TAC too, it might be a bug or something else...

Re: TCP flow get slower with IPS 4255 5.1(3) in inline mode

ovt — Mon, 28 Aug 2006 08:48:08 GMT

This is expected.

Disable TCP sequence randomization on the PIX ("norandomseq") for traffic between the vlans. If it doesn't help then add "produce alert" action to the signatures in the Normalizer engine and see which signatures are firing. Then post your results here.

Re: TCP flow get slower with IPS 4255 5.1(3) in inline mode

Fernando_Meza — Mon, 28 Aug 2006 08:56:11 GMT

Hi .. be aware that the IPS can inspect at 600 Mbps however, its monitoring interfaces support 1Gbps and hence the sensor could be receiving traffic at faster speed tha it can inspect. this will affect performance on you network. To double check this check the statistics of your interfaces and see whether the ammount of missed packets is dramatically increasing. If that is the case then you need to limit the traffic to be inspected by using filters.

I hope it helps ... please rate if it does !!!

Re: TCP flow get slower with IPS 4255 5.1(3) in inline mode

csiszerakos2 — Tue, 29 Aug 2006 13:37:38 GMT

Hello,

The traffic is about 1-2 megabit/sec through the IPS, so this does not count.

I tried to use the norandomseq but it does not help.(Is it ok that the norandomseq does not appear in the configuration? - I used in this form: nat (APPL) 0 access-list ACL_NONAT_APPL norandomseq).

I switched off all of the signatures except the normalizers. I switched them just to produce alert and verbose alert no to drop or modify packet.

The two relevant server are Takson (172.31.5.1) and Keve (172.31.6.1)

The alarms are attached. I see that there is alarm between them :TCP session tracking stopped due to timeout

It seems to me very strange.

Akos