FWSM Incoming Traffic on inside Interface

Answered Question
Sep 21st, 2010
User Badges:

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

Correct Answer by Kureli Sankar about 6 years 6 months ago

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

Correct Answer by Jon Marshall about 6 years 6 months ago

I haven't worked with 4.x code so Kusankar can perhaps confirm but if you have a shared interface you used to have to use NAT rules otherwise the classifier does not know which context to send the traffic to ?


Jon

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Kureli Sankar Tue, 09/21/2010 - 06:31
User Badges:
  • Cisco Employee,

Ian,

I am not sure if I follow you. Would you be able to add a simple text based topology?

You are sharing a vlan between two contexts?


-KS

Kevin Redmon Tue, 09/21/2010 - 07:17
User Badges:
  • Cisco Employee,

Ian,


As KS had said, a text-based topology would be great.  My guess based strictly on your problem description is that you are likely hitting an asymmetric route situation.


In a routed network, the next Layer-3 device will make the next route decision.  If you have a complete SVI network configured on your switch, and you use these SVIs as the Default Gateway for the upstream routers/hosts, the Switch will make the next route decision. You can ping the local (ie same subnet) IP addresses as local subnet traffic is managed via ARP Requests/Responses.


However, if traffic resides outside of the local subnet, the traffic is sent to the Default Gateway - the Default Gateway will make the next routing decision.  Since it is a fully-meshed SVI network on the Switch, it will likely have an entry in its routing table for the destination IP address that does NOT involve going through the FWSM.


If you want traffic to go through the FWSM, the key takeaway would be to use the FWSM's IP address as the next hop gateway for all of your upstream Layer-3 devices.  The other approach - leveraging a number of different SVIs on the Switch - often requires a significant effort to "work around" the FWSM.  This can be done, but it would require either route-maps and/or VRFs.


If this addresses your questions, please mark this question as answered for the benefit of others.


Best Regards,

Kevin

Magnus Mortensen Tue, 09/21/2010 - 07:14
User Badges:
  • Cisco Employee,

Ian,

     There are two ways to firewall traffic with an FWSM:


1) FWSM in routed mode:

You must route the traffic to the IP addresses of the FWSM as tho it was any other layer-3 hop in your network. This involves static routes or some routing protocol and results in traffic being routed to one interface of the FWSM and then the FWSM routes the traffic out another interface on the path to the destination.


2) FWSM in transparent mode:

     For this to work you must break-up a layer-3 segment into two VLANs and assign one to either side of the FWSM. This does not invlove 'routing' the traffic to the FWSM with static routes or routing protocol. The trafic passes through the FWSM as tho the FWSM was a 'bump in the wire'.


What method are you intending for this to work, and how is it currently configured. Is the FWSM (context) transparent or routed?


- Magnus

Kevin Redmon Tue, 09/21/2010 - 09:24
User Badges:
  • Cisco Employee,

Ian,


Can you please provide us the flow that is/isn't working in the two scenarios below?  In particular, what is the source/destination IP address and VLAN.  Also, what is the difference in the routing tables between the non-working and the working scenario?  Make sure that the hop-by-hop routing makes sense for the flow and is what you would expect - both the forward and reverse flows must pass through the FWSM.  As in my previous post, if the next-hop is the 6500, you will need to check the 6500 route tables for the next routing decision.


If you have any syslogs at the time of the issue from the FWSM, that is also greatly appreciated.


Best Regards,

Kevin

Ian Beck Tue, 09/21/2010 - 09:47
User Badges:

Hi,


The only difference betwen the to options is, the working one uses a SVI on the 6500 betwen two vlans and has all the correct routing, but is an over engineer solution, but it works.


The none working solution, is purley a layer 2 VLAN no routing on the MFSC, all the routing is correct and all relevant traffic is routed correctly to the inside context IP Address and I have gone over it several times to check it all.


Basically, the Gateway at the top points a route to the Firewall Interface and a relevant route on the firewall points at the Gateway.


As I stated earlier, I can ping between the Gateway and FW no issue "permited ICMP", however when I send a simple ssh connection (the rule base is unchanged to the working version) to one of the Servers I do not get connected. I have tried denying very thing to get information in the Real Time Log of packets being denied or getting a No route statement. But I see nothing. On the Server side, as we are going to be using SSO I see all the traffic from the Server tying to talk to the AD Servers, but I am not sure they get answered (I have not investigated it)


I even tried a traffic capture but all I saw was the SYN packet and nothing else come in.

Jon Marshall Tue, 09/21/2010 - 09:53
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Ian


You may need to post config of the context if you can.


Have you tried using wireshark on the server to see if it receives the packet and what it does it with it ?


If you do post the config can you also provide us with the src IP and the dst IP.


Jon

Ian Beck Tue, 09/21/2010 - 10:05
User Badges:

Context configuration, very simple at the moment as until I can solve this issue I cann not move forward.


The Gateway is 172.23.31.2/28 TC3Office nameif

Jon Marshall Tue, 09/21/2010 - 10:16
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

Thanks -


src IP and dst IP ??


is the src IP the gateway ?


Edit - are there are shared interfaces int this context ?


Jon

Ian Beck Tue, 09/21/2010 - 10:17
User Badges:

I have just been able to confirm that packets coming from the Servers reach the destination Server, on the inside, correctly which is then sending a reply back.

Ian Beck Tue, 09/21/2010 - 10:22
User Badges:

A source packet can come from the 172.16.50.0 Network going to either the 172.23.16/17 Networks


admin-context admin
context admin
  allocate-interface Vlan300
  config-url disk:/admin.cfg
!


context TC3inside
  allocate-interface Vlan300
  allocate-interface Vlan316
  allocate-interface Vlan317
  allocate-interface Vlan393
  allocate-interface Vlan394
  config-url disk:/TC3inside.cfg
!


context TC3outside
  allocate-interface Vlan301
  allocate-interface Vlan302
  allocate-interface Vlan303
  allocate-interface Vlan392
  config-url disk:/TC3outside.cfg

Kureli Sankar Tue, 09/21/2010 - 10:26
User Badges:
  • Cisco Employee,

A real quick test.


Make the admin-context TC3inside


Remove vlan 300 from the admin context.


See if it works


conf t


admin-context TC3inside
context admin
  no allocate-interface Vlan300
 

-KS

Correct Answer
Jon Marshall Tue, 09/21/2010 - 10:31
User Badges:
  • Super Blue, 32500 points or more
  • Hall of Fame,

    Founding Member

  • Cisco Designated VIP,

    2017 LAN, WAN

I haven't worked with 4.x code so Kusankar can perhaps confirm but if you have a shared interface you used to have to use NAT rules otherwise the classifier does not know which context to send the traffic to ?


Jon

Ian Beck Tue, 09/21/2010 - 10:35
User Badges:

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

Correct Answer
Kureli Sankar Tue, 09/21/2010 - 10:44
User Badges:
  • Cisco Employee,

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 Tue, 09/21/2010 - 10:48
User Badges:

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

Ian Beck Wed, 09/22/2010 - 05:21
User Badges:

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 Wed, 09/22/2010 - 05:37
User Badges:
  • Cisco Employee,

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 Wed, 09/22/2010 - 05:57
User Badges:

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 Wed, 09/22/2010 - 14:34
User Badges:

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 Wed, 09/22/2010 - 14:59
User Badges:
  • Cisco Employee,

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 Wed, 09/22/2010 - 15:24
User Badges:

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 Wed, 09/22/2010 - 21:07
User Badges:
  • Cisco Employee,

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 Thu, 09/23/2010 - 09:28
User Badges:

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

Actions

This Discussion