[c-nsp] Problems with FWSM

Hammer bhmccie at gmail.com
Tue Apr 26 16:52:08 EDT 2011


John is 100% correct. The way to work with this is to make sure you have all
the necessary identity NATs in place or you are gonna really be struggling.
FYI, if you want to confirm what traffic the classifier is having trouble
passing to the correct context, check the logging on the Admin context.
You'll see the connection entries get defaulted to the Admin context and you
can chase them down in the logs.


 -Hammer-

"I was a normal American nerd."
-Jack Herer





On Tue, Apr 26, 2011 at 7:33 AM, <cisconsp at secureobscure.com> wrote:

> 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<http://www.cisco.com/en/US/docs/security/fwsm/fwsm41/configuration/guide/contxt_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/
>
> _______________________________________________
> 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/
>


More information about the cisco-nsp mailing list