FWSM behaving badly in single context mode ACL/NAT

[lordbigsack]

Hi, can someone point out where I am going wrong.  We have the following topology and want to be able to connect ServerA to serverB on port 80.  Pretty standard stuff.  We have the following config

int-asa-context

access-list nat0_list extended permit ip any any

nat (dmz12) 0 access-list nat0_list

access-list dmz12_access_in extended permit tcp 10.10.12.0 255.255.255.0 10.10.10.0 255.255.255.0 eq www

route transit11 10.10.10.0 255.255.255.0 10.10.11.1

int-fwsm

access-list nat0_list extended permit ip any any

nat (transit11) 0 access-list nat0_list

access-list transit11_access_in extended permit tcp any 10.10.10.0 255.255.255.0 eq www

route transit20 10.10.10.0 255.255.255.0 10.20.20.3

route transit11 10.10.12.0 255.255.255.0 10.10.11.251

vrf-router

ip route vrf transit 10.10.0.0 255.255.0.0 10.20.20.1

int vlan20

ip vrf forwarding transit

ip address 10.20.20.3 255.255.255.248

int vlan10

ip vrf transit

ip address 10.10.10.254 255.255.255.0

The issue we have is we get the following error on the int-fwsm firewall

Mar 04 2013 12:13:26 INT-FWSM : %FWSM-3-106010: Deny inbound tcp src transit11:10.10.12.20/46624 dst Transit20:10.10.10.20/80

packet-tracer on the asa shows allow and nat-exempt.

capture on the int-fwsm shows the initial syn packet arriving at the interface.

the hit-count on the acl line does NOT increment and we get teh deny log above.

I have checked NAT, ROUTE, ACL and all seem to say it should be permitted but yet I get the deny.

Any suggestions welcomed.

Thanks in advance

[Jouni Forss]

Hi,

The Log message doesnt reference any ACL.

Usually this is because ACL is not attached to any interface with the "access-group" command

Otherwise it some other configuration that restricts traffic between the 2 interfaces. One could be "security-level" values. (As in the traffic is allowed by ACL but both of the interfaces have equal "security-level" value which requires the "same-security-traffic permit inter-interface" command)

- Jouni

[lordbigsack]

@jouniforss thanks for the reply, the access-list is assigned with

access-group transit11_access_in in interface transit11

same-security-traffic permit inter-interface

transit is security-level 0

access_transit is security-level 100

Just to mention other traffic is flowing through the firewall through the transit11 interface

[lordbigsack]

To quick on the reply button, forgot to mention cheers for pointing out the access-list isnt specified in the logs - hadnt noticed that in isolation

[Jouni Forss]

Hi,

Maybe its something related to NAT then (even though you have NAT0 configurations)

Personally when configuring NAT rules I try to be as specific as I can. For example in your case I would mention the source and destination networks in each case.

When you say that other traffic is working just fine. Does this traffic include other traffic between the same 2 networks 10.10.10.0/24 and 10.10.12.0/24 ?

- Jouni

[Jouni Forss]

I guess in this case NAT0 configuration on the FWSM could be

access-list permit ip 10.10.10.0 255.255.255.0 10.10.12.0 255.255.255.0

or you could configure a different type of NAT for the 10.10.10.0/24 network towards Transit11

static (transit20,transit11) 10.10.10.0 10.10.10.0 netmask 255.255.255.0

Though in the case of the "static" command this would apply for all traffic of network 10.10.10.0/24 towards "transit11" interface and its networks and the other way around.

- Jouni

[lordbigsack]

it looks as though we need to apply a nat0 to transit20 interface, looks similar to the asymettric nat error that gets chucked up on the ASA.  We have raised a change for this to be released in the next couple of days to resolve.

[jocamare]

I'm curious to see what the packet-tracer from the FWSM and outgoing interface captures show.

[lordbigsack]

the captures show syn packets inbound with no reply.  AFAIK there is no packet-tracer on FWSM, thats an ASA command

[jocamare]

Do you see those same SYN packets leaving the FWSM?