FWSM and unknown packet status

[ktokashhh]

Hey all, I'm a little new to the FWSMs and ran into a problem. We have multiple subnets set up on the FWSM, and the FWSM is defaulting correctly (it is not in a redundant config yet, still building the environment).

So one of these subnets has a box that needs to do a remote copy sync with one in another data center, but the two can't reach each other. I have:

- Set up and confirmed default routing from FWSM to other DC

- Confirmed OSPF in other DC has a route back

- Opened the firewall source/dest/ports

This box is already routing (I'm going through it right now), but I'm not getting any logs as to where the packet is dying in the order of operations.

My config looks thusly (opened it wide for testing):

access-list acl_production extended permit ip host 10.x.x.2 object-group [GROUP] log

I then ping into that acl and fail, but no logs are generated. It sounds like the packets are not making it to the acl, but this is just a simple addition to an existing acl that is already working. Is there some way to see if the packets are making it to this box?

[JORGE RODRIGUEZ]

Hi,

can you discribe the physical connectivity in relation to the DC residing in one of the subnets behind the fwsm and the other DC at the data center, how is the DC in the data center reachable through a DMZ , or through outside interface etc..?

first make sure the DC in data center don't have some kind of Windows FW turned on that is blocking connections.

second , you could check if indeed fwsm does have a route to reach the subnet where the DC in data center resides.

e.g in fwsm

assuming DC system in data center is in 192.168.13.0/24 subnet and fwsm does have a route to get there you should see a route entry as bellow when doing show route if learned by ospf, or s for static.

e.g

show route | inc 192.168.13.0

O IA 192.168.13.0 255.255.255.0

if fwsm does have a route either learned by ospf or by static means then you can rule out routing and start checking access list or NAT if applicable.

also you could issue a low level packet debug on fwsm and see it you are actually hiting the destination IP.

debug packet interface src IP dst ip

assume you are pinging from 10.10.10.10 to

DC in data center 192.168.13.4

e.g

debug packet inside src 10.10.10.10 dst 192.168.13.4

as you send a ping request to DC from a machine 10.10.10.10 issue:

show debug | inc x.x.x.x for source ip or dest ip , you should be able to see icmp packets for each of the icmp requests.

you may also turn on loggin

logging on

logging monitor warnings

logging buffered debugging

logging trap debugging

Rgds

Jorge

[ktokashhh]

Sorry, I should have defined the acronym "DC" to mean data center, not domain controller. The FWSM (located in corporate environment) has a default upstream and can even ping the router interface of the server in the production network.

FWSM# ping 10.40.7.2

Sending 5, 100-byte ICMP Echos to 10.40.7.2, timeout is 2 seconds:

!!!!!

Leads me to think that the problem is the firewall not forwarding the packet when inbound sessions are initiated, but I can't see it one way or the other. I'm going to increase logging levels and try again.