Traffic going to odd address instead of tunnel?

[rhardiman]

We expanded a subnet at a remote site and traffic from our main site to addresses in the new part of the remote subnet does not work. I have the correct subnet mask on the routes and on the IPSec VPN tunnel. I see the traffic in Forward Traffic being accepted and destined for the VPN interface, but if I do a traceroute the next hop after our firewall is 10.10.10.1 which is not on any network, route, or interface that we have at any site.

Traceroutes from a workstation show the firewall as the first hop and 10.10.10.1 as the second. Traceroutes from the firewall show that address as the first hop.

I'm sure more info is needed, please let me know what I can provide.

[AEK]

You can start by checking if the right route is installed on FG.

get router info routing-table all

[rhardiman]

I have confirmed the 10.10.10.1 address is not in there and the route looks correct.

[Toshi_Esumi]

That's probably a "Tunnel ID" started from 7.0. Run "get router info routing-t all" in CLI. You would see 10.10.10.1 like .....(recursive via <tunnel_name> tunnel 10.10.10.1).
And if that's the case the packets are going over the tunnel but the other end is not replying back.

Toshi

[rhardiman]

I have confirmed that the address is not in the routing table.

[Toshi_Esumi]

What then did you see the next hop for the expanded subnet in the routing-table?

Toshi

[rhardiman]

S x.x.x.x/23 [10/0] via [TunnelName] tunnel x.x.x.x, [1/0]

As I think it should be? The IP addresses are correct.

[Toshi_Esumi]

try sniff the ping traffic while you're pining from a device behind the FGT.

        diag sniffer packet any 'icmp and host <device_IP_or_destination_IP>' 4 0

You might need to disable ASIC offloading on the outgoing policy toward the tunnel

        set auto-asic-offload disable

Toshi

[rhardiman]

When I tried sniffing the ping traffic, some of my pings actually went through- about one in eight of them. The trace only showed anything on the pings that actually went through and came back and what it showed was correct. Then I did another traceroute and got a really weird response.

Tracing route to 192.168.X.X over a maximum of 30 hops

1 <1 ms <1 ms <1 ms MY.FIREWALL.local [192.168.firewall.ip]
2 38 ms 37 ms 37 ms 10.10.10.1
3 39 ms * * 192.168.X.X
4 * * * Request timed out.
5 * * * Request timed out.
6 39 ms * * 192.168.X.X
7 * * * Request timed out.
8 * * * Request timed out.
9 * 39 ms * 192.168.X.X
10 39 ms * * ^C

 I also did a debug flow trace and that appeared to show what it should show as well.

[Toshi_Esumi]

Then the 10.10.10.1 is definitely on the other side of the tunnel. You need to do the same trouble shooting (routing-table check, sniffing, and flow debug) on the other end.

Toshi