Troubleshooting Tip: Routing Issue

[Muhammad_Haiqal]

Description
This article describes how to verify routing path and configuration.
Basically, routing is related to the segment and gateway.
In some scenario, certain segment required specific gateway.

Example.

0.0.0.0/0(everything) Gateway ISP Router
10.10.10.0/24 Gateway MPLS. Means, 10.10.10.0/24 is on MPLS
20.20.20.0/24 Gateway VPN1. Means, 20.20.20.0/24 is on VPN1
30.30.30.0/24 Gateway VPN2. Means 30.30.30.0/24 is on VPN2

Solution
To mitigate this issue, verify that the FortiGate configuration is working as per as expected.

Go to Network -> Static Route.
Make sure all the routing information is correct.
Add / remove necessary entry.

Verify traffic flow as follow:
- Source: 172.168.0.100.
- Destination: 10.10.10.16.

Verify routing table.

# get router info routing-table all | grep 10.10.10.0/24

Or

# get router info routing-table all

Make sure there is a routing for 10.10.10.0/24 segment.

Verify traffic flow.

# diag sniffer packet any ‘host 10.10.10.16 and icmp’ 4 0

From source 172.168.0.100, ping to 10.10.10.16.
Sniffer will show the interface as follow:

interfaces=[any]
filters=[host 172.168.0.100 and host 10.10.10.16 and icmp]
11.097441 lan in 172.168.0.100 -> 10.10.10.16: icmp: echo request
11.097557 MPLS out 192.168.244.136 -> 10.10.10.16: icmp: echo request
11.129438 MPLS in 10.10.10.16 -> 192.168.244.136: icmp: echo reply
11.129477 lan out 10.10.10.16 -> 172.168.0.100: icmp: echo reply

12.102049 lan in 172.168.0.100 -> 10.10.10.16: icmp: echo request
12.102085 MPLS out 192.168.244.136 -> 10.10.10.16: icmp: echo request
12.133505 MPLS in 10.10.10.16 -> 192.168.244.136: icmp: echo reply
12.133531 lan out 10.10.10.16 -> 172.168.0.100: icmp: echo reply

13.109669 lan in 172.168.0.100 -> 10.10.10.16: icmp: echo request
13.109708 MPLS out 192.168.244.136 -> 10.10.10.16: icmp: echo request
13.147746 MPLS in 10.10.10.16 -> 192.168.244.136: icmp: echo reply
13.147773 lan out 10.10.10.16 -> 172.168.0.100: icmp: echo reply

14.114213 lan in 172.168.0.100 -> 10.10.10.16: icmp: echo request
14.114249 MPLS out 192.168.244.136 -> 10.10.10.16: icmp: echo request
14.138062 MPLS in 10.10.10.16 -> 192.168.244.136: icmp: echo reply
14.138096 lan out 10.10.10.16 -> 172.168.0.100: icmp: echo reply

Check the gateway / interface use to reach the 10.10.10.16.

In above output, there is 4 line for each complete flow. Notice the numbering.

11.xxxxxx – for 1 complete ping
12.xxxxxx – for 1 complete ping
13.xxxxxx – for 1 complete ping
14.xxxxxx – for 1 complete ping

Traffic from LAN(in) to MPLS(out)
Respond from MPLS(in) to LAN(out)

So in this scenario, the traffic flow is correct.
Go out using MPLS, respond from MPLS.

If  something  not right is noticed, change the routing, distance or priority accordingly.
Certain case, FortiGate already sent out the traffic to the correct gateway, however, the peer did not respond to FortiGate or respond using another gateway.

Example:
Traffic from LAN(in) to MPLS(out) <----- Correct.
Respond from VPN1(in) to LAN(out)  <----- Not correct.
Traffic should respond back on MPLS.

For this scenario, it is not the FortiGate issue anymore.
Check routing on the peer.

Troubleshooting idea:
1) Make sure the segment and subnet is correct
2) Make sure the FortiGate interface can ping to the peer gateway.

# Exe ping-options source <interfaceIP>

3) Make sure the other unit also route to the FortiGate.

Related Articles

Technical Note: Routing behavior depending on distance and priority for static routes, and Policy Ba...