08-23-2006 05:25 AM - edited 03-10-2019 03:10 AM
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?
08-23-2006 12:34 PM
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.
08-25-2006 05:53 AM
Thank you. I have tried to switch off all of the signatures, but it does not help, the latency still exists.
08-25-2006 06:28 AM
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.
08-27-2006 08:09 AM
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...
08-28-2006 01:56 AM
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 !!!
08-28-2006 01:48 AM
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.
08-29-2006 06:37 AM
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
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: