Magnus:

I did a capture and I am only getting:

icmp: echo request.

No reply coming back.

Thanks,

Hey,

I am assuming that you have taken capture on the internal interface that faces the core switch?

If you could run the packet-tracer command as follows, we would be able to roughly determine as to why the packet response is not coming back. Please follow this command:

packet-tracer input icmp 8 0 detailed

Regards,

Narayanan.

Ok. Thanks. I will run the packet-tracer shortly. In meantim

e, here is the capture from the inside int:

31: 19:45:00.575943 802.1Q vlan#201 P0 192.168.1.1.137 > 192.168.1.2.137:  udp 50
    32: 19:45:03.864258 192.168.1.3> 192.168.1.1: icmp: time exceeded in-transit

192.168.1.1 is my pc

192.168.1.2 is the core switch

192.168.1.3 is the inside int of the firewall

Here is the packet-trace result:

Phase: 1
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in  id=0x6fb43078, priority=12, domain=capture, deny=false
        hits=636533, user_data=0x6f2e4548, cs_id=0x0, l3_type=0x0
        src mac=0000.0000.0000, mask=0000.0000.0000
        dst mac=0000.0000.0000, mask=0000.0000.0000

Phase: 2
Type: ACCESS-LIST
Subtype:
Result: ALLOW
Config:
Implicit Rule
Additional Information:
Forward Flow based lookup yields rule:
in  id=0x6f202788, priority=1, domain=permit, deny=false
        hits=55028024, user_data=0x0, cs_id=0x0, l3_type=0x8
        src mac=0000.0000.0000, mask=0000.0000.0000
        dst mac=0000.0000.0000, mask=0000.0000.0000

Phase: 3
Type: FLOW-LOOKUP
Subtype:
Result: ALLOW
Config:
Additional Information:
Found no matching flow, creating a new flow

Phase: 4
Type: ROUTE-LOOKUP
Subtype: input
Result: ALLOW
Config:
Additional Information:
in   10192.168.1.1   255.255.255.240 management [The inside int ip is 192.168.1.2 not 192.168.1.1]

Phase: 5
Type: ACCESS-LIST
Subtype: log
Result: ALLOW
Config:
access-group acsnet_ACCESS_IN in interface acsnet
access-list acsnet_ACCESS_IN extended permit icmp any any
access-list acsnet_ACCESS_IN remark ***Developer access
Additional Information:
Forward Flow based lookup yields rule:
in  id=0x6f2922b8, priority=12, domain=permit, deny=false
        hits=302, user_data=0x6f125910, cs_id=0x0, flags=0x0, protocol=1
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 6
Type: CONN-SETTINGS
Subtype:
Result: ALLOW
Config:
class-map class-default
match any
policy-map global_policy
class class-default
  set connection decrement-ttl
service-policy global_policy global
Additional Information:
Forward Flow based lookup yields rule:
in  id=0x6f3484b8, priority=7, domain=conn-set, deny=false
        hits=156948, user_data=0x6ece3600, cs_id=0x0, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 7
Type: IP-OPTIONS
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in  id=0x6f204a48, priority=0, domain=permit-ip-option, deny=true
        hits=744719, user_data=0x0, cs_id=0x0, reverse, flags=0x0, protocol=0
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 8
Type: INSPECT
Subtype: np-inspect
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in  id=0x6f203ee0, priority=66, domain=inspect-icmp-error, deny=false
        hits=57183, user_data=0x6f203e10, cs_id=0x0, use_real_addr, flags=0x0, protocol=1
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 9
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
in  id=0x6fb3f5b8, priority=12, domain=capture, deny=false
        hits=1163, user_data=0x6f2e4548, cs_id=0x6f1ba980, reverse, flags=0x0, protocol=1
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=192.168.1.3, mask=255.255.255.255, port=0, dscp=0x0

Phase: 10
Type: CAPTURE
Subtype:
Result: ALLOW
Config:
Additional Information:
Forward Flow based lookup yields rule:
out id=0x6f2189a0, priority=12, domain=capture, deny=false
        hits=941, user_data=0x6f2a25d8, cs_id=0x6fbf7a40, reverse, flags=0x0, protocol=1
        src ip=0.0.0.0, mask=0.0.0.0, port=0
        dst ip=0.0.0.0, mask=0.0.0.0, port=0, dscp=0x0

Phase: 11
Type: FLOW-CREATION
Subtype:
Result: ALLOW
Config:
Additional Information:
New flow created with id 840571, packet dispatched to next module
Module information for forward flow ...
snp_fp_inspect_ip_options
snp_fp_adjacency
snp_fp_fragment
snp_fp_tracer_drop
snp_ifc_stat

Module information for reverse flow ...

Phase: 12
Type: ROUTE-LOOKUP
Subtype: output and adjacency
Result: ALLOW
Config:
Additional Information:
found next-hop 192.168.1.3 using egress ifc management
adjacency Active
next-hop mac address 5475.d0ef.d37f hits 13506

Result:
input-interface: acsnet
input-status: up
input-line-status: up
output-interface: management
output-status: up
output-line-status: up
Action: allow

Hi,

Can you attach a topology diagram or draw out the topology for clarity purposes?

Regards,

Narayanan.

I attached the diagram.

Here the scenario:

From my desk:

- I can ping the firewall fine

-I can ping all layer_2 switches

but I cannot ping the core switch.

From the layer 2 switches:

I can ping the core

I can ping my pc

From the core switch:

I can ping the firewall

I can ping all layer 2 switches

But I can not ping outside the firewall (my pc)

Thanks alot.

so if i understand you right when you ping your PC from the layer 3 switch behind the core you can ping the PC, but when you try to ping the PC from the core itself it does not work

if i understand you right please check the ip default gateway on your swicth and see if it point to the right device or ip

The default gateway is setup fine. the core switch i

s set as the default gateway for the layer 2 switches and they are able

to get outside.

can you span the switch port connected to asa and confirm if the packets are actually sent out by core, bcoz from the earlier discussion it looks like when we collect captures on the asa interfac we do not see anything,

can you also post the access-list for captures and the sh run int for the interface connected to core

here are the config of the interfaces on the core:

Vlan201 is up, line protocol is up
  Hardware is Ethernet SVI, address is 5475.d0ef.d37f (bia 5475.d0ef.d37f)
  Description: management ip
  Internet address is 192.168.1.3
  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive not supported
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input 00:00:00, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/75/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 0 bits/sec, 0 packets/sec
  L3 in Switched: ucast: 35486 pkt, 1975044 bytes - mcast: 0 pkt, 0 bytes
  L3 out Switched: ucast: 0 pkt, 0 bytes - mcast: 0 pkt, 0 bytes
     35510 packets input, 1976754 bytes, 0 no buffer
     Received 24 broadcasts (0 IP multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     4280 packets output, 524513 bytes, 0 underruns
     0 output errors, 0 interface resets
     0 output buffer failures, 0 output buffers swapped out

GigabitEthernet1/1 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet Port, address is c84c.751d.48b0 (bia c84c.751d.48b0)
  Description: To Firewall

  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000-TX
  input flow-control is off, output flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 2027000 bits/sec, 320 packets/sec
  5 minute output rate 297000 bits/sec, 293 packets/sec
     56976467 packets input, 39831664720 bytes, 0 no buffer
     Received 30027 broadcasts (0 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     61034896 packets output, 9453365738 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out
GigabitEthernet2/1 is up, line protocol is up (connected)
  Hardware is Gigabit Ethernet Port, address is c84c.7549.7870 (bia c84c.7549.7870)
  Description: To firewall fo

  MTU 1500 bytes, BW 1000000 Kbit, DLY 10 usec,
     reliability 255/255, txload 1/255, rxload 1/255
  Encapsulation ARPA, loopback not set
  Keepalive set (10 sec)
  Full-duplex, 1000Mb/s, link type is auto, media type is 10/100/1000-TX
  input flow-control is off, output flow-control is off
  ARP type: ARPA, ARP Timeout 04:00:00
  Last input never, output never, output hang never
  Last clearing of "show interface" counters never
  Input queue: 0/2000/0/0 (size/max/drops/flushes); Total output drops: 0
  Queueing strategy: fifo
  Output queue: 0/40 (size/max)
  5 minute input rate 0 bits/sec, 0 packets/sec
  5 minute output rate 2000 bits/sec, 4 packets/sec
     10771 packets input, 735644 bytes, 0 no buffer
     Received 7371 broadcasts (0 multicasts)
     0 runts, 0 giants, 0 throttles
     0 input errors, 0 CRC, 0 frame, 0 overrun, 0 ignored
     0 input packets with dribble condition detected
     4482092 packets output, 343325250 bytes, 0 underruns
     0 output errors, 0 collisions, 0 interface resets
     0 babbles, 0 late collision, 0 deferred
     0 lost carrier, 0 no carrier
     0 output buffer failures, 0 output buffers swapped out

Hi,

What i would like to know is, are you able to ping the firewall's next hop on the outside? Also, is there some kind of network running private IP's on the outside of the firewall?

Secondly, is there a NAT rule or access-list statemtn permitting the pings to the core switch on the outside interface of the firewall?

Regards,

Narayanan.

Based on the attached topology, here is my understanding:

PC(192.168.1.1)-----(NETWORK CLOUD)-----(acsnet)ASA(management)--------------(192.168.1.3)Core

                                                                        192.168.1.2

The captures you have attacehd is form the Management interface of the ASA. Please correct me if any of my above assumtions are wrong.

If my assumptions are right, I see tha the IP address of the PC is 192.168.1.1 which is the same as the Management interface network on the ASA and Core witch. The reason why we are seeing the TTL expired message could be due to this conflictng IP address.

According to the ASA the 192.168.1.0 netowrk is on the management interface while the PC is coming in on the acsnet interface.

Let me know if what i have mentioned above is correct!

Regards,

Prapanch

I got it. THe ip route command were missing.

Thanks everybody.