Problem on acl filter trafic

Didier DRIEUX · ‎08-10-2010

Hi,

I have a problem with rule of FWSM.

Message log :

Aug 3 16:38:57 PIX-Part Aug 03 2010 16:38:57: %FWSM-3-106010: Deny

> inbound tcp src filiales:10.113.248.17/4144 dst

> dmzpub-part:146.249.250.133/21

> Aug 3 16:39:00 PIX-Part Aug 03 2010 16:39:00: %FWSM-3-106010: Deny

> inbound tcp src filiales:10.113.248.17/4144 dst

> dmzpub-part:146.249.250.133/21

> Aug 3 16:39:06 PIX-Part Aug 03 2010 16:39:06: %FWSM-3-106010: Deny

> inbound tcp src filiales:10.113.248.17/4144 dst

> dmzpub-part:146.249.250.133/21

The rule is :

access-list filiales_access_in extended permit tcp 10.113.248.16

> 255.255.255.240 host 146.249.250.133 object-group S_FTP

Yet the access-list capture match well the traffic:

fw-tiers# sh access-list cap_MDA

> access-list cap_MDA; 2 elements

> access-list cap_MDA line 1 extended permit ip 10.113.248.16

> 255.255.255.240 host 146.249.250.133 (hitcnt=12) 0x2fe4c3b1

> access-list cap_MDA line 2 extended permit ip host 146.249.250.133

> 10.113.248.16 255.255.255.240 (hitcnt=0) 0x67ee5327

But not those that used to filter the traffic :

sh access-list filiales_access_in | inc 10.113.248.16 access-list

> filiales_access_in line 2 extended permit tcp

> 10.113.248.16 255.255.255.240 host 146.249.250.133 object-group S_FTP

> 0x7188a1ec access-list filiales_access_in line 2 extended permit tcp

> 10.113.248.16 255.255.255.240 host 146.249.250.133 eq ftp (hitcnt=0)

> 0xdc2693b4

> access-list filiales_access_in line 2 extended permit tcp

> 10.113.248.16 255.255.255.240 host 146.249.250.133 eq ftp-data

> (hitcnt=0) 0x33118715

We have tried to disable FTP inspection without succès.

The version of FWSM is

FWSM Firewall Version 4.0(5)
Device Manager Version 6.1(3)F

Thanks for your help

Regards

mirober2 · ‎08-10-2010

Hello,

Can you check the output of 'show run access-group' to ensure that the ACL is applied to the correct interface?

-Mike

Didier DRIEUX · ‎08-12-2010

Hello Mike,

See on attachement the result of the command.

Thanks

Regards

Didier DRIEUX · ‎09-01-2010

Hello Mike,

The problem has been resolved. It' was a NAT Configuration problem.

Thanks

Regards

Didier

Andrew Ossipov · ‎08-10-2010

Hello Didier,

This looks like a NAT issue rather than an ACL deny. Please ensure that the NAT configuration is properly mapping 146.249.250.133 from'dmzpub-part' to 'filiales' and/or NAT Control is turned off.

Andrew

Didier DRIEUX · ‎08-12-2010

Hi Andrew,

The "nat-control" command is not present on the configuration. It has been disabled a few weeks ago to allow traffic to pass without NAT.

Is it necessary to recreate a rule of NAT ?

Thanks

Regards

Andrew Ossipov · ‎08-12-2010

Hello Didier,

It appears that some existing NAT configuration is preventing the xlate from being created (likely by a NAT reverse path check). You should go through the NAT configuration ('show run nat', 'show run global', and 'show run static') between the interfaces in question to make sure bi-directional connectivity is allowed. I would also suggest checking the relative security levels with 'show nameif' command.

Andrew