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

[Kureli Sankar]

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]

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]

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

[Ian Beck]

Hi,

The FWSM is running in Routed mode.

I have attached a diagram set which hopefully explians the issue.

[Kevin Redmon]

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]

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]

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]

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]

Thanks -

src IP and dst IP ??

is the src IP the gateway ?

Edit - are there are shared interfaces int this context ?

Jon

[Ian Beck]

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]

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]

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

[Ian Beck]

Breaking my admin

[Jon Marshall · Accepted solution]

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