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
Solved! Go to 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?
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.
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.
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?
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.
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.
A source packet can come from the 172.16.50.0 Network going to either the 172.23.16/17 Networks