FWSM Incoming Traffic on inside Interface

[Ian Beck]

Hi,

I have a FWSM ruuning on a 6509 with MFSC in context mode.

If I configure up a full SVI routed environment on the MFSC to send packets to the FWSM it all works fine.

Howvever if I just have a VLAN to which my incoming traffic comes via a port on the switch and is routed from an attached router device connected to the switch port in the same VLAN directing traffic to the FWSM however I see no traffic crossing the Interface. I can ping from the router on the port to the FWSM ip address and the other way.

I have the Admin context works fine of the same VLAN !

Any ideas what I have missed

[Ian Beck]

So that works, which is great thanks.

So if I have to but NAT in place,  could I put it on the Admin side on the same VLAN ?

Or do I need to have a seperate VLAn for Admin ?

Thanks

[Kureli Sankar · Accepted solution]

YES !! My very first posting asked if you are sharing vlan.

Anyway, yes, with interfaces that you share you need to provide translation.

Can you use another vlan for management and allocate that to the admin context?

or

Do this.

1. allocate another vlan to the admin context.  This doesn't even have to exist in the siwtch's vlan database.

2. now configure this as another interface in the admin context.

3. configure nat in the admin context as well between these two interface from high to low.

So, classifier can work properly and not get confused as to which context to send the packets that it receives.

You can read about classifier here: http://www.cisco.com/en/US/docs/security/fwsm/fwsm40/configuration/guide/contxt_f.html#wp1124172

Rate the posts that were useful to you and that solved the issue. Pls. make sure to mark the issue resolved if you think it is.

-KS

[Ian Beck]

Ok, just missing reading the comments but thanks for all the help itis appreciated.

[Ian Beck]

Hi,

Have have reconfigured with the recommendations but still am not getting traffic through.

I have stayed with a shared VLAN and added relevant Static Nat's and can get to admin but not my servers.

Also creting the vlan on the admin side needed to be in the VLAN DB as it would not come active !

[Kureli Sankar]

FWSM(config)# context admin
FWSM(config-ctx)# allocate-interface vlan97
FWSM(config-ctx)# sh vlan
36, 300-301 , 458, 500, 2646
FWSM(config-ctx)# ch con admin
FWSM/admin(config)# int vlan97
FWSMadmin(config-if)# nameif test
WARNING: VLAN *97* is not configured.
INFO: Security level for "test" set to 0 by default.
FWSM/admin(config-if)# seAccess Rules Download Complete: Memory Utilization: 1%
c 100
FWSM/admin(config-if)#

As you can see I don't even have this vlan when I issue sh vlan on the FWSM, yet I allocated it and configured it under the admin context.

-KS

[Ian Beck]

HI,

Yes thats fine and understand but how do then use it to controll traffic.

As in Failover mode, if I add and address to the interface it does no t come active.

or is this just allowing for the creation of a Static NAT to the admin IP address ?

Thanks

[Ian Beck]

Hi,

i am still having a nd issue with the traffic flow

I have define the vlan as suggested but when I give it and ip address which I assume I am meant to attch to the link will no coem up

UKTC3-N01-FFW01/admin(config)# sh failover
Failover On
Last Failover at: 20:23:06 GMT-dst Sep 10 2010
        This context: Active
                Active time: 1044563 (sec)
                Interface TC3admin (172.23.31.12): Normal (Not-Monitored)
                Interface TC3Control (10.1.1.11): No Link (Not-Monitored)
        Peer context: Standby Ready
                Active time: 0 (sec)
                Interface TC3admin (172.23.31.11): Unknown (Not-Monitored)
                Interface TC3Control (0.0.0.0): Unknown (Not-Monitored)

so how is this meant to to work ?

Thanks

[Kureli Sankar]

So, the vlan is active in the switch's database and you did push the vlan down from the switch to the FWSM?

when you do "sh vlan" on the FWSM system space the vlan assigned to TC3Control does exist?

You did not configure a standby IP address to the TC3Control interface.

For the traffic that failed yesterday, all you need is NAT configured on this admin context.

For the vlan 300 that you are sharing, if this is the outside vlan (like it is in most cases), you just need to provide translation from high to low.

Sorry got too busy with work today.  Did you attach both the contexts config? I will take a look.

Also, yesterday when traffic broke, you should have seen 106025 syslog message:

http://www.ciscosystems.com/en/US/docs/security/fwsm/fwsm22/system/message/fsmemsgs.html#wp1038731

Error Message    %FWSM-6-106025: Failed to determine the security context for the 
packet:sourceVlan:sourceIP destIP sourcePort destPort protocol

Error Message    %FWSM-6-106026: Failed to determine the security context for the 
packet:sourceVlan:sourceIP destIP sourcePort destPort protocol

Explanation   These messages are generated when the security context of the packet in multiple context  mode cannot be determined. Both messages can be generated for IP packets being dropped in either  router and transparent mode.

-KS

[Ian Beck]

Hi,

No problem quiet understand, job has to come first.

It maybe what I am trying to do with our FW which is causing the problems, so Have attached a basic diagram of what I trying to do.

This is a Application network which have networks which intercommuncicate but we wont the seperate. We currently use the same configuration (ASA and other FW's, we have moved to 6500's for capacity) so I am trying to build it.

If it is best to go to seperate Vlan's for Amdin and the first app FW then such if the way but trying to get it to work if I can.

But if I can make it work, would be great

[Kureli Sankar]

Your diagram is a little misleading. You have a line connecting inside and outside context.  That means you are sharing a vlan between the two context or cascading the contexts.  I don't believe so.

There are no shared vlans between the inside and outside contexts.

Just vlan 300 between inside and admin context.

It would make your job much easier if you can come up with another vlan for management. That is what I would do.

Better yet, I would make the inside context as the admin context that already has vlan 300 assigned to it.  admin context doesn't have to have the name admin or be the admin context.

If you want to make this work then, forget about what "sh fail" output says in admin context and configure some dummy static NAT lines on the admin context and get the traffic to work.  There is no reason to fix what sh fail says. So long as both units are equally healthy or equally un-healthy, failover will function fine.

If you have further questions I suggest you open a TAC case so, we can spend the time needed on the TAC case.  When it gets too involved and when we feel that we need to get an engineer on the device I usually suggest to open a case with us.  So, pls. open a case and one our engineers will pick this up and assist you. Make sure to add the link to this posting in the case.

-KS

[Ian Beck]

Hi

Many thanks for all your help and suggestions.

Following some thought I have gone the 2 vlan route and all is working well.

Regards