PIX 525 internet degradation after upgrade

Unanswered Question
Sep 1st, 2008

Hello

we have upgraded the version 6.3.5 to 7.2 (3) on a PIX 525 .

Our client has got a 1000 user network and report problem of internet download latency that increase about 200 % .

example: a 100 Mbyte file take 5 minutes before the upgrade . Now takes 15 or 20 minute

The carrier ( STM-1 lines ) do not report any changes over the line.

We have just fix up the issue over the ftp connection using the class-map method and allow MSS with higher range

But this problem could not fix yet with this method

http://www.cisco.com/en/US/products/hw/vpndevc/ps2030/products_tech_note09186a00804c8b9f.shtml

Any other suggestion ?

Regards

Alberto Belleli

PS Coordinator Network Security

Cisco CCNP/CCDP

Uniautomation SpA

Via dell'Artigianato 2/B

20061 Carugate - Italy

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Loading.
jdive Mon, 09/01/2008 - 04:23

Big difference between pix 6.x and 7.X is the tcp statefull engine that got quite of a lift up. It is much more aggressive in dropping suspicious TCP segments or sanitizing the various headers. It would be ideal to find a reproducable scenario: downloading this file on this site via HTTP / FTP. Once this is done, check the asp drops counters or enable asp drop capture (capture bla type asp_drop) , check the logs as well during the transfert to see if any segments have been dropped and why. If this does not give anything, getting a smaller file and enabling capture on inside/outside at the same time would help in seeing what in the packet changes, the delay in crossing the PIX and the packet drops / retransmits and so forth.

abelleli71 Mon, 09/01/2008 - 04:40

Hello

thanks for the reply . This procedure is similare for the MSS reduction that we try already to fix with this ( without success ) :

pixfirewall(config)#access-list http-list4 permit ip any any

pixfirewall(config)#

pixfirewall#configure terminal

pixfirewall(config)#

pixfirewall(config)#class-map http-map4

pixfirewall(config-cmap)#match access-list http-list4

pixfirewall(config-cmap)#exit

pixfirewall(config)#tcp-map mss-map

pixfirewall(config-tcp-map)#exceed-mss allow

pixfirewall(config-tcp-map)#exit

pixfirewall(config)#policy-map http-map4

pixfirewall(config-pmap)#class http-map4

pixfirewall(config-pmap-c)#set connection advanced-options mss-map

pixfirewall(config-pmap-c)#exit

pixfirewall(config-pmap)#exit

pixfirewall(config)#service-policy http-map4 interface inside

pixfirewall#

abelleli71 Mon, 09/01/2008 - 05:32

Here it the output of a transaction

DNS reply from outside:192.228.79.201/53 to dmz:193.205.23.1/36259; packet length 530 bytes exceeds configured limit of 512 bytes messages:Sep 1 15:21:20 pix-primary.uni-bocconi.it Sep 01 2008 15:23:01: %PIX-4-410001: Dropped UDP DNS reply from outside:192.228.79.201/53 to dmz:193.205.23.1/17440; packet length 530 bytes exceeds configured limit of 512 bytes messages:Sep 1 15:21:20 pix-primary.uni-bocconi.it Sep 01 2008 15:23:01: %PIX-4-410001: Dropped UDP DNS reply from outside:192.228.79.201/53 to dmz:193.205.23.1/1686; packet length 529 bytes exceeds configured limit of 512 bytes

grant.maynard Tue, 09/02/2008 - 14:14

DNS response being dropped because they're too long? Try this:

policy-map type inspect dns MY_DNS_INSPECT_MAP

parameters

message-length maximum 600

policy-map global_policy

class inspection_default

inspect dns MY_DNS_INSPECT_MAP

grant.maynard Wed, 09/03/2008 - 01:25

or just edit the default policy, if it's there:

policy-map type inspect dns preset_dns_map

parameters

message-length maximum 600

abelleli71 Wed, 09/03/2008 - 01:29

Hello

I just cut of the parameter doing :

parameters

no message-length maximum 512

But nothing seems to change . I have checked also the show asp drops with the following resuslts:

Frame drop:

Invalid encapsulation 526

Invalid IP length 40830

Invalid TCP Length 1326

Invalid UDP Length 71

No route to host 4

Flow is denied by configured rule 116709

First TCP packet not SYN 59875

Bad TCP flags 282

Bad option length in TCP 212

TCP Dual open denied 32

TCP failed 3 way handshake 1253

TCP RST/FIN out of order 1018

TCP SEQ in SYN/SYNACK invalid 398

TCP SYNACK on established conn 19

TCP packet SEQ past window 1292

TCP invalid ACK 234

TCP ACK in 3 way handshake invalid 3

TCP Out-of-0rder packet buffer full 17816

TCP Out-of-Order packet buffer timeout 5799

TCP RST/SYN in window 345

TCP DUP and has been ACKed 237343

TCP packet failed PAWS test 2189

Slowpath security checks failed 251

ICMP Error Inspect no existing conn 20

ICMP Error Inspect different embedded conn 102

DNS Inspect invalid packet 35

DNS Inspect invalid domain label 226

DNS Inspect packet too long 4002

DNS Inspect id not matched 294

FP L2 rule drop 5703

Flow drop:

Flow is denied by access rule 30

NAT failed 636

Inspection failure 3590

pix-primary#

grant.maynard Wed, 09/03/2008 - 03:02

I meant increase the limit. I'm not sure that removing it would have the same effect.

policy-map type inspect dns preset_dns_map

parameters

message-length maximum 600

mcvhintex Thu, 09/04/2008 - 13:45

This sounds very familiar to an issue we had with DNS Fixup in PIX 6.35. The DNS maximum was set to 512 and we had to increase its default size. Perhaps the fixup value was not default before the upgrade and the value was reset.

The suggested method to change it in 7.x is:

hostname(config)# policy-map type inspect dns dns-inspect

hostname(config-pmap)# parameters

hostname(config-pmap-p)# message-length maximum 1024

abelleli71 Thu, 09/04/2008 - 22:58

Hello

thanks for the answer . We have already cut of the parameters and try also the 1024 size ...but nothing seems to change .

The problem was that we have an internet speed degradation . Before upgrade was 200 Kb/s now is around 90 Kb/s . No change on the provider.

Question :

The only log that we see during a download is that one that I stamp in the previuos message .

Is the DNS the only responsable for a download session ?

Actions

This Discussion