Another FWSM issue

icmp permit commands ?

In article , dexx wrote: :I have an FWSM routing between 3 networks - inside, accounts, and :outside. I dont want to use NAT and am unconcerned about using multiple :security levels. 'inside' is configured as 192.168.1.1 servicing :192.168.1.0/24. Similarly accounts is 192.168.2.1 and outside is :192.168.3.1. Ive created an icmptest acl to allow pings everywhere and :ive issued "fixup protocol icmp" to make it stateful.

:The problem is, whilst i get replies using 'ping 192.168.2.22' on the :firewall, typing 'ping inside 192.168.2.22' returns error 110001 - no :route to 192.168.2.22 from 192.168.1.1.

Let me get this straight: you are specifically telling the FWSM to send the pings out of the inside interface, but you are expecting that the FWSM will look at the routing table, see that the destination is on a different interface, and override your specific choice of interfaces?

Or are you expecting that the FWSM will in some manner send the ping packets to the inside interface (as if it were a seperate subunit) because of your specification of the interface, and that the inside interface would then do a routing table lookup and determine the correct interface and send it on to that interface? If that's what you are expecting, then are you expecting that this process would bypass the firewalling services or would go back through the firewalling services?

Ive created an icmptest acl and applied it so that ping is permitted everywhere. The FWSM routes between two subnets, and reaches the 'outside' world via the MSFC. The problem i have is that the FWSM complains of "no route to host" when a machine on subnet A tries to ping a machine on subnet B (or any other protocol for that matter).

I am considering the FWSM to be a router with acls filtering traffic. Is this an incorrect model?

No. I'm wanting a host on subnet A (including the FWSM's subnet A interface) to be able to ping a host on subnet B (including the FWSM subnet B interface).

In article , dexx wrote: :I am considering the FWSM to be a router with acls filtering traffic. :Is this an incorrect model?

Yes, that -is- an incorrect mental model.

In Finesse (the operating system used by PIX and FWSM), interfaces have no independant existance such that you might originate a ping "at" an interface. Interfaces in Finesse are just security boundaries and all the action takes place "inside" the PIX or FWSM.

Thus, as far as PIX and FWSM are concerned, you cannot use the Finesse facilities to ping from one interface to a different interface. Packets originating at the PIX/FWSM itself can only go "out" of an interface; you can't do the equivilent of poking a packet "outside" of an interface to pass back through into the PIX/FWSM, get processed, and go to a different interface.

Furthermore, in PIX/FWSM, if [generally speaking] you try to have a packet pushed out an interface, looped back around -unchanged- by something on the other side of the interface, and have it re-enter the PIX/FWSM for processing and delivery on that same interface, then the PIX/FWSM will drop the packet: it keeps track of what is going out, and will not allow the same packets to re-enter the same interface.

There is a further restriction in PIX/FWSM such for a packet originating outside the PIX/FWSM, only the "closest" interface will be willing to answer [with one exception on the PIX involving a special VPN tunnel; this does not apply for the FWSM.]

So... for the PIX/FWSM, you will get a different result if you have a real host on subnet A originate a ping (from beyond interface #1 inward via interface #1) destined for a real host on subnet B (outward via interface #2). Hosts in A will be able to ping interface #1, and hosts in B will be able to ping interface #2, but hosts in A will not be able to ping interface #2 and hosts in B will not be able to ping interface #1 and interface #1 and #2 will not be able to ping each other.

Or to summarize a different way: traffic can pass -through- a PIX/FWSM and be subject to ACLs and NAT and security levels; or traffic can go between an interface and the outside of that interface and be subject to 'icmp' and 'http' and 'telnet' and 'ssh' rules; but those are the only two modes. In-device traffic is not permitted, and you can only go between a host and its closest interface.