cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
721
Views
5
Helpful
8
Replies

FWSM - Not forwarding to "inside"

Roble Mumin
Level 3
Level 3

Hi all,

i currently have no idea what i might have missed when configuring a new context on the FWSM.

L3 Setup:

< MSFC > --- < VLAN 1113 > --- < FWSM A > --- < VLAN 1217 >

|

| 1113,1217 both forwarding on the trunk

|

< MSFC > --- < VLAN 1113 > --- < FWSM S > --- < VLAN 1217 >

FWSM ~ 3.2(8)

MSFC ~ 12.2(33)SXH2a

FWSM is running in multi mode and the vlans are allocated from the MSFC via the firewall-group. The context which is supposed to be administrative for the two vlans has the vlans correctly configured via "allocate-interface".

The transfer(outside) network is vlan 1113 and is also reachable. So i can log into my new context and start configuring.

Now the (not so) funny part. Within the context i am using nat-control and i created an ACL with an ACS permitting my vlan 1217 network to any.

Then i nat 0 (interface-vlan1217) that network. So the NAT part is okay from my point of view.

I created an ACL for the traffic originating from vlan 1217 (security 50) with permit ip any. So vlan1217 is more or less my inside interface.

I also created an ACL for the Outside Interface (vlan 1113) and yes, all ACL's are assigned via "access-group <acl> in interface <interface>". I allowed icmp via permit icmp on both interfaces. I can ping both interfaces from the FWSM itself. But i can't reach the vlan 1217 interface ip from the MSFC. The vlan 1113 interface ip replies my icmp packets just fine from the MSFC.

I already triple checked the L2 connections, the firewall group and the interface allocations for the context. The ACL's are there, the ICMP statement is there. The ACL is bound to the interface the NAT statement is in place.

So before i start pulling my hair maybe anyone as an idea what i might have missed.

Thanks for reading!

Roble

1 Accepted Solution

Accepted Solutions

I overlooked you diagram.

It looks as if you are sharing the inside VLAN. Well its not a good idea and not recommended at all.

With multiple context mode the only valid option is to share outside vlans. All of the FWSM contexts uses the same MAC addresses (Unlike ASA where you can have different MACs used for different contexts). As a result the only criteria to handover a packet to a particular packet to a particular context is "destination ip".

For this reason you need static NAT entries to classify packet. With Inside shared interface/Vlan its impossible to have all the destination ip addresses defined.

more details at

http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/configuration/guide/contxt_f.html#wp1124172

Syed

View solution in original post

8 Replies 8

What you are trying to achieve (to ping the inside interface for an FWSM

context from the outside) is not possible by design.

You can use the managment-access command and ping the inside interface from the outside only if you are coming across an IPSEC tunnel.

Instead of hitting FWSM inside interface, try to hit a host connected to vlan1113.

Syed Iftekhar Ahmed

Hi Syed,

thanks for the fast reply.

I moved a client (my laptop) to that vlan on an access switch and tried to ping it. I also tried to reach the MSFC standby ip from the client. That doesn't work either.

From the client i also haven't been able to ping the "inside" IP (gateway) which should reply when checked from the same vlan. The interface is "up" on the FWSM...

And i also checked the trunk from the aggregation switch(MSFC)to the access switch connecting my laptop, to make sure that vlan 1217 is forwarded correctly.

I get the point that you can't ping from outside to the inside ip but from the an inside client to the outside MSFC standby address should work.

This is my first multi context FWSM so i thought i might have missed something which is fundamentally different to a single context FWSM.

I will have another look tomorrow morning maybe i find what i overlooked so far.

Roble

I overlooked you diagram.

It looks as if you are sharing the inside VLAN. Well its not a good idea and not recommended at all.

With multiple context mode the only valid option is to share outside vlans. All of the FWSM contexts uses the same MAC addresses (Unlike ASA where you can have different MACs used for different contexts). As a result the only criteria to handover a packet to a particular packet to a particular context is "destination ip".

For this reason you need static NAT entries to classify packet. With Inside shared interface/Vlan its impossible to have all the destination ip addresses defined.

more details at

http://www.cisco.com/en/US/docs/security/fwsm/fwsm32/configuration/guide/contxt_f.html#wp1124172

Syed

Hi Syed,

that makes perfectly sense. The fact that i usually use nat exempt (nat 0) which is marked as "Invalid Classifier Criteria" in your doc leads to the point that the FWSM has no idea where to put that packet.

I am actually sharing the outside vlan over different contexts at least we planned to do that for our new aggregation block.

So right now i configured a static for the network and i am pretty sure that as soon as i have a client in that vlan it will work.

Working with the ACE and it's different MAC-sets i have to admit that i took that feature for granted. Checking the ARP table on the MSFC you can clearly see that both contexts i have created so far all use the same MAC.

So my options right now are either do static nat over my contexts or head for a multiple SVI approach between each context and the MSFC.

Anyhow thanks for that hint it would have probably taken a long time to stumble over that limitation.

As soon as finished testing it i will let you know the results.

Roble

Syed

"I overlooked you diagram. It looks as if you are sharing the inside VLAN."

Good catch, i missed that as well. Rated.

Jon

Hi Syed,

just managed to test the connection with static nat and finally it works as expected.

Thanks for that hint regarding shared vlans and the FWSM.

Roble

Jon Marshall
Hall of Fame
Hall of Fame

Roble

A quick check but have you taken care of the routing either with dynamic routing protocol between FWSM and MSFC or static routes on MSFC so that MSFC knows how to get to the vlan 1217 subnet.

Jon

Hi Jon,

yes i have a static route on each MSFC.

I will have a look at the link from Syed tomorrow. I am already @ home so i can check that out tomorrow.

Roble

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Review Cisco Networking products for a $25 gift card