BGP Established but can't ping

[HS08]

My fortigate hub have BGP connection to the spoke, the spoke ip is 10.10.112.11 and BGP was established.

But why i can't ping to that spoke bgp peer ip? So traffic from the hub can't reach the spoke using this tunnel interface

If i ping 10.10.112.1 from spoke to the hub the result is reply.

[jdelafuente_FTNT]

share output for:
exe ping-options source 10.10.112.1

exe ping 10.10.112.11
get route info routing details 10.10.112.11

get route info routing all 

[HS08]

Here the result

and here result if ping from the spoke

[Toshi_Esumi]

Since the other direction of pining works, it's not a routing issue over the tunnel. I would suspect something on the remote side is not taking the ping packets, or not returning the ping reply packets.

So, I would start with basic troubleshooting on the remote FGT, like checking allowaccess, sniffing the tunnel interface with the source IP after disabling NPU offloading at the policies and/or the IPsec config to see if they're arriving and if it's returning them, and then run flow debugging why not returning if arriving, and so on.

Toshi

[HS08]

This not only can't ping but traffic from the hub can't reach the spoke if passing this tunnel interface.

[Toshi_Esumi]

yes, I would imagine so. But even if not it wouldn't change the troubleshooting method I would use.

[HS08]

If the traffic can't passing thru this tunnel, why the BGP still have path using this tunnel?

[Toshi_Esumi]

You need to understand the difference of protocols (like ICMP, TCP, UDP) and ports (TCP 179, 443, 22). BGP is using TCP179. But others use different protocols and/or ports. That's why you need to sniff & flow debug to see why those show different behavior.

Toshi

[funkylicious]

if you start a diag sniffer packet on the spoke, what do you see ? is the traffic coming/reaching on X interface and is it a reply going back X intf or Y intf?

also, is ping enabled/activated on the interface/fw ?

[dingjerry_FTNT]

Hi @HS08 ,

My first step would be running "diag sniffer packet" for Ping traffic (using icmp as the filter) on the spoke side first.

This is to confirm whether the Ping initiated on the Hub side arrives at the Spoke or not.