Access-List Not Working

[bforan]

Hello,

I am running Pix IOS v6.3(3).

I want to block snmptraps originating from a certain source. Just adding an entry to an existing ACL.

My access-list entry is:

access-list Inbound line 1 deny udp host 172.x.x.27 any eq snmptrap

This entry is at line 1 of the ACL. This ACL has gotten 0 hits.

The traps continue to come in.

When I run a debug on the interface where the traps are entering the firewall, I can see the traps hitting the interface of the Pix.

For some reason, the ACL element is not stopping this traffic.

We've also seen some other strange behaivor on ACLs with this version of the Pix software. Is there a bug that pertains to ACLs?

Thanks.

[Patrick Iseli]

I imagine this trap hits the PIX ?

Access-list are just working if a packet travels two interfaces.

Anyway if it is not set in the ' snmp-server host inside IPAddress' then the SNMP Traffic should not be able to talk to the PIX.

On which interface is the 172.x.x.27 and what is his destination. Also on which interface is that hitting ?

sincerely

Patrick

[bforan]

Here is how the traffic is flowing:

172.x.x.27->OutsidePix->InsidePix->SNMP Collector(192.x.x.11)

The snmp traps aren't originating from the Pix itself, just passing through from the client to a server. 172.x.x.27 is the client and 10.x.x.15 is the server. The Pix doesn't have an interface on the 172.x.x.27 network. It's remote.

The traps from 172.x.x.27 are getting through to the collector just fine. I want to stop them by adding an element to the ACL.

access-list Inbound line 1 deny host 172.x.x.27 any eq snmptrap

This should stop any traps originating at 172.x.x.27 from getting through the firewall. But it doesn't.

Thanks.

[Patrick Iseli]

Looks good ?

Have you added:

access-group Inbound in interface outside

sincerely

Patrick

[bforan]

Yes, the rest of the access-list is working fine. There are a bunch of other elements in it.

I put this statement at the top so I knew it would get hits.

[Patrick Iseli]

Sometimes you have to do a:

clear xlate

but I don't think it will be necessary in your case.

hmm.

Anyway if you want to try that but be aware that this will reset all connections.

Have you checked with the CAPTURE command to see what traffic is really passing the PIX.

sincerely

Patrick

[bforan]

Now something strange has happened. At some point last night, that ACL statement started working and now has over 4000 hits. This is the expected behaivor.

New question now....Why would it take several hours for an ACL to start working? Will turbo ACL cause this? I think I'll start a new thread with this question.

Brian

[Patrick Iseli]

No idea it recomiles automaticly after a changement in the access-list.

the doc says:

TurboACL

On the PIX Firewall, TurboACL is turned on globally with the command access-list compiled (and turned off globally by the command no access-list compiled).

The PIX Firewall default mode is TurboACL off (no access-list compiled), and TurboACL is active only on access lists with 19 or more entries.

The minimum amount of Flash memory required to run TurboACL is 2.1 MB. If memory allocation fails, the TurboACL lookup tables will not be generated.

Note Use TurboACL only on PIX Firewall platforms that have 16 MB or more of Flash memory. Consequently, TurboACL is not supported on the PIX 501 because it has 8 MB of Flash memory.

If TurboACL is configured, some access control list or access control list group modifications can trigger regeneration of the TurboACL internal configuration. Depending on the extent of TurboACL configuration(s), this could noticeably consume CPU resources. Consequently, we recommend modifying turbo-complied access lists during non-peak system usage hours.

For more information on how to use TurboACL, refer to the Cisco PIX Firewall and VPN Configuration Guide, Version 6.2 or higher.

sincerely

Patrick