PIX TCP slowness when routing & doing NAT

Hi,

I have a 506E with 6.3(4) which is serving the dual purposes of firewalling & routing packets. It's on a /30 with its upstream router, and in turn does NAT for our /26.

I can push the outside interface to around 4Mbit/s (it's on a 10Mb segment) by doing 'ping -f -l 100000 ...', from a host inside to outside, and similar from outside to inside.

However, TCP connections vary from 5KBytes/s to 120KBytes/s. Doing several TCP connections to disparate hosts & FTP mirrors makes no difference.

I have a PIX at another location which does fine, the only real difference being that it is on the same CIDR subnet as it does NAT for.

I've read the archives of this group, which suggests checking that the auto-negotiate is off and that the duplex/speed are forced correctly. I've tried 100full & 10full, with the cooperation of my ISP, and I'm really at a total loss. We don't see any problems at all with our PIX.

If all else fails I will try replacing the PIX with a spare, but if anyone has any other suggestions, I would like to try them first.

Aaron

(running-config attached)

PIX Version 6.3(4) interface ethernet0 10full interface ethernet1 10full nameif ethernet0 outside security0 nameif ethernet1 inside security100 hostname pix domain-name insom.me.uk fixup protocol dns maximum-length 512 fixup protocol ftp 21 fixup protocol h323 h225 1720 fixup protocol h323 ras 1718-1719 no fixup protocol http 80 fixup protocol rsh 514 fixup protocol rtsp 554 no fixup protocol sip 5060 fixup protocol sip udp 5060 no fixup protocol skinny 2000 fixup protocol smtp 25 no fixup protocol sqlnet 1521 fixup protocol tftp 69 names name 192.168.82.4 d name 192.168.82.5 e name 192.168.82.3 c name 192.168.82.2 b name 192.168.82.1 pix-inside access-list f permit tcp any any access-list f permit icmp any any access-list f permit udp any any pager lines 24 logging on logging standby logging console debugging logging trap debugging logging host inside e mtu outside 1500 mtu inside 1500 ip address outside 85.113.81.2 255.255.255.252 ip address inside pix-inside 255.255.255.0 ip audit info action alarm ip audit attack action alarm pdm location 192.168.1.0 255.255.255.0 inside pdm location b 255.255.255.255 inside pdm location c 255.255.255.255 inside pdm location d 255.255.255.255 inside pdm location e 255.255.255.255 inside pdm location 85.113.81.0 255.255.255.0 outside pdm logging informational 100 pdm history enable arp timeout 14400 nat (inside) 1 0.0.0.0 0.0.0.0 0 0 static (inside,outside) 85.113.82.4 d netmask 255.255.255.255 0 0 static (inside,outside) 85.113.82.3 c netmask 255.255.255.255 0 0 static (inside,outside) 85.113.82.2 b netmask 255.255.255.255 0 0 static (inside,outside) 85.113.82.5 e netmask 255.255.255.255 0 0 access-group f in interface outside route outside 0.0.0.0 0.0.0.0 85.113.81.1 1 timeout xlate 0:05:00 timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h225

1:00:00 timeout h323 0:05:00 mgcp 0:05:00 sip 0:30:00 sip_media 0:02:00 timeout uauth 0:05:00 absolute aaa-server TACACS+ protocol tacacs+ aaa-server TACACS+ max-failed-attempts 3 aaa-server TACACS+ deadtime 10 aaa-server RADIUS protocol radius aaa-server RADIUS max-failed-attempts 3 aaa-server RADIUS deadtime 10 aaa-server LOCAL protocol local ntp server 17.254.0.27 source outside floodguard enable
Reply to
bradya
Loading thread data ...

:However, TCP connections vary from 5KBytes/s to 120KBytes/s. Doing :several TCP connections to disparate hosts & FTP mirrors makes no :difference.

As an experiment, try lowering your MTU a little -- first to 1492 and then to 1480 and then to 1424 (or lower in each case.)

I see from your configuration that you -are- permitting icmp back in, so if your hosts are doing Path MTU Discovery they -should- have adapted to a lower MTU... but it's still worth testing.

Reply to
Walter Roberson

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.