Buy or Renew
Buy or Renew
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 
cancel
Start a conversation
341
Views
0
Helpful
4
Replies

CBS350 - routing issue e.g. ping from host on CBS to host on FPR1010

christian85
Level 1
Level 1

‎03-02-2025 10:18 AM - edited ‎03-02-2025 10:24 AM

Hi experts,

I have the a quite simple setup but there is an annoying issue which keeps me busy since days. Basically the setup is working. PC1 can access the Internet and can ping other hosts on CBS350. So this is fine.

But the issue is that PC 1 can not access PC 2. Oddly PC 2 can access PC 1.
I hope you can help with this issue. I'm running out of ideas...

For your orientation please find the following map:

christian85_4-1740935939128.png

What I've tested:

Direction: Firewall to Switch

  • Ping: PC 2 -> CBS350: OK
  • Ping: PC 2 -> PC 1: OK
  • Ping: PC 2 -> to other host on CBS350: OK

Direction: Switch to Firewall

  • Ping: PC 1 -> to other host on CBS 350: OK
  • Ping: PC 1 -> CBS350 (192.168.0.8): OK
  • Ping: PC 1 -> CBS350 (192.168.95.2): OK
  • Ping: PC 1 -> FPR1010 (192.168.95.1): OK
  • Ping: PC 1 -> PC 2: failed with timeout NOK
  • Ping: CBS350 (192.168.95.2) -> PC 2: OK
  • Ping: CBS350 (192.168.0.8) -> PC 2: failed with timeout NOK

So I investigated the issue by using SPAN on the CBS350. I did a wireshark on P23 when PC1 was pinging PC2.

christian85_3-1740935862085.png

As the firewall is routing back the ping-reply to P23 there seems no issue on FPR-side.

In a next step I did the same on P13 when PC 1 was pinging PC 2.

christian85_5-1740936063713.png

The ping request is sent but the reply is not routed back to PC1.

I think the ping-reply is lost on the CBS350 during routing from P23 to P13. - But what could be the reason and how can I fix it?

 

  • IPv4 routing is enabled:
    christian85_6-1740937611100.png
  • the firmware is up to date:
    christian85_7-1740937649890.png
  • P23 is a routed port:
    christian85_8-1740938856134.png
  • P13 is untagged
    christian85_9-1740939099724.png
  • No matiching ACL configured on CBS350
  • Static route is configured:
    christian85_11-1740939282507.png

Thank you in advance.

 

 

Labels:
0 Helpful
4 Replies 4

balaji.bandi
Hall of Fame
Hall of Fame

‎03-02-2025 12:20 PM - edited ‎03-02-2025 12:22 PM

High level, when you mentioned not being able to communicate (ping, or any other application)

First, I check Windows Firewall (disable and test it)

other side check inter-vlan routing :

https://www.youtube.com/watch?v=g1NMbrnJfvg

Also make sure you have FTD routing enabled, how to reach each other's subnets

What zone PC2? Inside or same zone? (check on FTD logs)

 

 

BB

***** Rate All Helpful Responses *****

How to Ask The Cisco Community for Help

0 Helpful

christian85
Level 1
Level 1
In response to balaji.bandi

‎03-02-2025 01:51 PM - edited ‎03-02-2025 01:52 PM

Some more clarifications:

  • PC 1, 2: Windows Firewall is disabled
  • From PC 1 to PC 2: Neither ping nor http(s) work; http(s) tested with another device than PC 2
  • From PC 2 to PC1: ping works fine

FTD configuration:

  • PC 2 belongs to VLAN 1 on FTD (192.168.95.0/24)
  • VLAN 1 (on FTD) is part of the inside zone.
  • No VLAN configured for "Switch-VLAN 1" - 192.168.0.0/24
    I expect it to be routed through the untagged Port 23 (*.95.2)

Routing on FTD is enabled:

christian85_1-1740951658532.png

Static route is set:

christian85_0-1740951580183.png

ACL on FTD (not sure if necessary)

christian85_2-1740951751535.png

 

 

0 Helpful

M02@rt37
VIP
VIP
In response to christian85

‎03-03-2025 02:34 AM - edited ‎03-03-2025 02:36 AM

Hello @christian85 

You say: 

  • From PC 1 to PC 2: Neither ping nor http(s) work; http(s) tested with another device than PC 2

So, possible to wireshark on PC-2 when you attempt http(s) or ping from PC-1 to PC-2 ?

Also, on FTD possible to "tcpdump" on port 4 and port 6 during your attempt also ?

Best regards
.ı|ı.ı|ı. If This Helps, Please Rate .ı|ı.ı|ı.
0 Helpful

christian85
Level 1
Level 1
In response to M02@rt37

‎03-03-2025 10:11 AM

Hi M02@rt37,

I did a packet capture on my FTD.

Ping PC 1 to PC 2 (Port 6):

 

> capture CAPI interface INSIDE match icmp host 192.168.0.23 host 192.168.95.7
> capture CAPO interface INSIDE match icmp host 192.168.95.7 host 192.168.0.23
> show capture CAPI

4 packets captured

   1: 17:46:10.632245       802.1Q vlan#1 P0 192.168.95.7 > 192.168.0.23 icmp: echo reply
   2: 17:46:15.309828       802.1Q vlan#1 P0 192.168.95.7 > 192.168.0.23 icmp: echo reply
   3: 17:46:20.311522       802.1Q vlan#1 P0 192.168.95.7 > 192.168.0.23 icmp: echo reply
   4: 17:46:25.317244       802.1Q vlan#1 P0 192.168.95.7 > 192.168.0.23 icmp: echo reply
4 packets shown
> show capture CAPO

4 packets captured

   1: 17:46:10.632245       802.1Q vlan#1 P0 192.168.95.7 > 192.168.0.23 icmp: echo reply
   2: 17:46:15.309828       802.1Q vlan#1 P0 192.168.95.7 > 192.168.0.23 icmp: echo reply
   3: 17:46:20.311522       802.1Q vlan#1 P0 192.168.95.7 > 192.168.0.23 icmp: echo reply
   4: 17:46:25.317244       802.1Q vlan#1 P0 192.168.95.7 > 192.168.0.23 icmp: echo reply
4 packets shown

 

 This is identical to what I recorded with wireshark:

christian85_0-1741024326665.png

During the http request from PC 1 to PC 2 I captured the following traffic:

christian85_1-1741024465495.png

Ping PC 1 to FTD (Port 4)

 

> capture CAPI interface INSIDE match icmp host 192.168.0.23 host 192.168.95.1
> capture CAPO interface INSIDE match icmp host 192.168.95.1 host 192.168.0.23
> show capture CAPI

8 packets captured

   1: 17:48:11.838839       802.1Q vlan#1 P0 192.168.0.23 > 192.168.95.1 icmp: echo request
   2: 17:48:11.839174       802.1Q vlan#1 P0 192.168.95.1 > 192.168.0.23 icmp: echo reply
   3: 17:48:12.865571       802.1Q vlan#1 P0 192.168.0.23 > 192.168.95.1 icmp: echo request
   4: 17:48:12.865876       802.1Q vlan#1 P0 192.168.95.1 > 192.168.0.23 icmp: echo reply
   5: 17:48:13.892226       802.1Q vlan#1 P0 192.168.0.23 > 192.168.95.1 icmp: echo request
   6: 17:48:13.892593       802.1Q vlan#1 P0 192.168.95.1 > 192.168.0.23 icmp: echo reply
   7: 17:48:14.934140       802.1Q vlan#1 P0 192.168.0.23 > 192.168.95.1 icmp: echo request
   8: 17:48:14.934506       802.1Q vlan#1 P0 192.168.95.1 > 192.168.0.23 icmp: echo reply
8 packets shown
> show capture CAPO

8 packets captured

   1: 17:48:11.838839       802.1Q vlan#1 P0 192.168.0.23 > 192.168.95.1 icmp: echo request
   2: 17:48:11.839174       802.1Q vlan#1 P0 192.168.95.1 > 192.168.0.23 icmp: echo reply
   3: 17:48:12.865571       802.1Q vlan#1 P0 192.168.0.23 > 192.168.95.1 icmp: echo request
   4: 17:48:12.865876       802.1Q vlan#1 P0 192.168.95.1 > 192.168.0.23 icmp: echo reply
   5: 17:48:13.892226       802.1Q vlan#1 P0 192.168.0.23 > 192.168.95.1 icmp: echo request
   6: 17:48:13.892593       802.1Q vlan#1 P0 192.168.95.1 > 192.168.0.23 icmp: echo reply
   7: 17:48:14.934140       802.1Q vlan#1 P0 192.168.0.23 > 192.168.95.1 icmp: echo request
   8: 17:48:14.934506       802.1Q vlan#1 P0 192.168.95.1 > 192.168.0.23 icmp: echo reply
8 packets shown

 

What I find interesting is that the ping from PC 1 to FTD (Port 4) captured both - response and request.
In contrast to the ping from PC 1 to PC 2 where the request is missing and just the reply was captured. But is this something to worry about?

BR

0 Helpful
Customers Also Viewed These Support Documents