[c-nsp] Problems with FWSM

[cisconsp at SecureObscure.com]

The issue is due to the packet classifier in the FWSM being confused.
If it can't assign an ingress packet to the correct context via unique vlan
id, it attempts to use the xlate table. FWSMs tend to ignore the routing
table for packet classification.

You can accomplish exactly what you desire, but you must manually enter
xlate rules in each specific context. Assuming your outside interface is
shared, and inside vlans are unique per context the syntax would be like
this:
static (inside,outside) 192.168.100.0 192.168.100.0 netmask 255.255.255.0
This will need to be flipped around if you have a shared inside interface
with unique outsides.

Once static commands are configured, from the system context you can
validate the xlate table: show np 3 static

You will want to add a line similar to the one below to the admin context,
and enable terminal monitor for troubleshooting:
logging message 106025 level warnings

It will show you errors like this one when packet classifier context
assignment fails:
%FWSM-6-106025: Failed to determine the security context for the
packet:sourceVlan:source_address dest_address source_port dest_port protocol


For a Cisco document outlining all the things I have forgotten about doing
this kind of setup, please see the following:
http://www.cisco.com/en/US/docs/security/fwsm/fwsm41/configuration/guide/con
txt_f.html

If I bumbled it up too bad I'm sure others on the list will help correct me.

Hope this helps,

John

-----Original Message-----
From: cisco-nsp-bounces at puck.nether.net
[mailto:cisco-nsp-bounces at puck.nether.net] On Behalf Of ALMEIDA Antonio Jose
Sent: Tuesday, April 26, 2011 4:08 AM
To: cisco-nsp at puck.nether.net
Subject: [c-nsp] Problems with FWSM

Before last  week we only had one context active in our FSWM but we tried to
activate another sharing the outside interface. After some hours trying to
identify the problems we were having (like having drops in access-list that
made no sense) we decided to remove this new context and almost everything
started working again except one flow in the first context. I'm still trying
to identify the problem but my knowledge in FWSM is not very good. I've done
captures in the FWSM and I can see the SYN in the outside but nothing else,
I'm guessing it's flowing to the admin context. Is there a way to
confirm/resolve this?

Antonio

_______________________________________________
cisco-nsp mailing list  cisco-nsp at puck.nether.net
https://puck.nether.net/mailman/listinfo/cisco-nsp
archive at http://puck.nether.net/pipermail/cisco-nsp/