Internal network losing external DNS access

This is one lengthy access list :shock: Poor pix.

I'm beginning to be more convinced that this is a performance/overload issue. Specially since you said it used to work fine. Sorry, my tiny little brain can't comprehend all that code. Never the less, Here are a few points that I'd try.

1. TurboACL: Pix supports a feature for lengthy ACLs. It can compile ACLs to make them run faster. You use TurboACL by simply typing the command:

[code:1]pix(config)# access-list compiled[/code:1]

2. I'd try my best to minimize the number of statements in access lists as possible. Get rid of any thing you don't need. For example, By default, all traffic is permitted from lower security interfaces to higher security interfaces, (i.e inside to outside is allowed). So there is no need to have the access list inside_acl, UNLESS you really need to permit only specific traffic and deny the rest.

In other words, in the following:

[code:1]access-list inside_acl permit tcp host 10.40.0.132 any
access-list inside_acl permit tcp host 10.40.0.133 any
access-list inside_acl permit tcp host 10.40.0.134 any
access-list inside_acl permit tcp host 10.40.0.135 any
access-list inside_acl permit tcp host 10.40.0.136 any
access-list inside_acl permit tcp host 10.40.0.137 any
access-list inside_acl permit tcp host 10.40.0.138 any
access-list inside_acl permit tcp host 10.40.0.139 any
access-list inside_acl permit tcp host 10.40.0.140 any
access-list inside_acl permit tcp host 10.40.0.141 any [/code:1]

All these traffic is allowed by default without an ACL.

Try removing this statement temporarily and see if the problem persists:
[code:1]access-group inside_acl in interface inside [/code:1]

3. The static translations list is also long, it might place more overhead on the Pix. Try removing any thing unnecessary. For example:

[code:1]static (inside,dmz1) 10.40.0.0 10.40.0.0 netmask 255.255.0.0 0 0
static (inside,dmz1) 10.30.0.0 10.30.0.0 netmask 255.255.0.0 0 0
static (inside,dmz1) 10.50.0.0 10.50.0.0 netmask 255.255.0.0 0 0
static (inside,dmz1) 10.60.0.0 10.60.0.0 netmask 255.255.0.0 0 0
static (inside,dmz1) 10.70.0.0 10.70.0.0 netmask 255.255.0.0 0 0 [/code:1]

I believe those 10.X.0.0 are connected to your inside after a router or something. Since you already have proper routes for them, If I recall right, I think it will work without the need for those static statements. (Provided the ACLs allow the traffic off course)

Thats as far as I know.

Thank you for your comments and suggestions. I will go through the lists and see what I can take out. I am not sure at this point that I can remove the inside_acl. So, I will try out the TurboACL. I did notice that TurboACL has some memory requirements. Do you see any problem with me enabling it given the following info:

inside_acl has 206 elements
outside_acl has 36 elements
dmz_acl has 64 elements

Hardware: PIX-515E, 32 MB RAM, CPU Pentium II 433 MHz
Flash E28F128J3 @ 0x300, 16MB
BIOS Flash AM29F400B @ 0xfffd8000, 32KB

SFW(config)# show memory
Free memory: 15489904 bytes
Used memory: 18064528 bytes

---

---

Total memory: 33554432 bytes


Thank you for your help.
tklarr

Never mind the previous question. I see that we need to have at least 16mb of flash and we do. So it should be find.

Thanks for all your help.
tklarr

Never mind the previous question. I see that we need to have at least 16mb of flash and we do. So it should be find.

Thanks for all your help.
tklarr

Hope it helps, tell us what happens when you have the time.

Hi, I really do see it as a capacity issue in the PIX Firewall. If it would have been then the issue will not be specific to DNS traffic.

I like to see the utilization of the CPU, Memory, Interface, and the packet drops on the Interfaces.

I would suggest you to check on the DNS server rather than wasting your time in PIX Firewall and that to if it is a DNS server running on Windows 2003 server, high possibility's are there in terms of configuration mistakes and not in terms of bug.

I would suggest you to check on the DNS server rather than wasting your time in PIX Firewall and that to if it is a DNS server running on Windows 2003 server, high possibility's are there in terms of configuration mistakes and not in terms of bug.

I think this is possible too, But with low probability since tklarr said that it works fine the moment he reloads the Pix.