| Description | This article describes how to troubleshoot routing issues caused by a bad source IP address. Using an IP address which is considered reserved, such as a 'network address' (e.g. 192.168.1.0 on a /24 network), or a 'broadcast address' (e.g. 192.168.1.255 on a /24 network) can result in routing issues. FortiOS will mark these IPs as bad sources and subsequently drop the packet. |
| Scope | FortiOS. |
| Solution |
The scenario:
This issue can occur in a Hub and spoke topology, where an IP address assignment to the VPN client (spokes) is done dynamically by the HUB. It can also happen with manual assignment, if the IP address assigned to the VPN tunnel is like the one described below. In the client address range in the screenshot below (configuration), if 0 – 251 of the last octet of the /24 subnet is configured, a client or spoke can have the IP address 10.253.1.0 assigned to it. This IP address will cause this type of issue.
The error: The error message 'reverse path check fail(bad src),drop' will be seen in the 'debug flow' logs.
Command for taken/collecting 'debug flow' logs:
diag debug enable diag debug flow filter aadr x.x.x.x <- IP assigned to the spoke site with routing issue. diag debug console timestamp enable diag debug flow show iprope enable diag debug flow show function-name enable diag debug flow trace start 999 diag debug enable
The root cause:
Unlike routing issue with an error message msg='reverse path check fail, drop' which is caused by asymmetric routing, the error message in this article (bad src) is not caused by asymmetric routing, but a bad source IP (e.g. 192.168.1.0. This is expected to be a reserve IP, the network IP).
The spoke site assigned with IP 192.168.1.0 can face errors such as 'down health-check, BGP peering issue'.
The fix: Change the IP assignment on the HUB from 0 – 251 to something like 10 – 251 on the fourth octet of the /24 subnet. |
