What I like in FortiGate devices, is that troubleshooting is quite straightforward. Of course, knowledge is necessary about troubleshooting capabilities and functions. Basically, every firewall is about to block and allow traffic. So, how to troubleshoot communications issue, when probably FortiGate is blocking some traffic, but it shouldn’t.
Lets’s analyze below scenario, quite specific actually:
FortiGate Branch and HUB should communicate over Ipsec VPN, but what is specific there, HUB has no idea about LAN subnet 10.255.225.0/24, only loopback1 subnet is propagated by routing. To enable communication, on Branch, SNAT and DNAT should be incorporated. To be specific, FortiGate should translate subnet to subnet, for example when host 10.255.225.2 want to communicate with infrastructure behind HUB, source NAT should translate it to 10.223.51.2, when traffic is initiiated by 10.255.225.3, should be translated to 10.223.51.3, and so on, and so on… For traffic initiated from infrastructure behind HUB, DNAT should translate with exactly the same logic.
SNAT config:
DNAT config:
Let’s test it, ping form HUB
Unfortunately unsuccessful. Ok, so let’s troubleshoot it. First step, let’s find out that traffic is hitting branch FortiGate using diag debug sniffer command
So I know that traffic initiated from Hub is reaching Branch, but why ping failed, let’s use debug flow to identify root cause
FortiGate Branch translated 10.223.51.5 to 10.255.255.4 but should to 10.255.255.5. I made small mistake in DNAT pool. External range should start from 0, not 1:
Let’s test again:
And debug flow to verify if translation is correct now:
Form FortiOS 7.4, debug flow is available through GUI as well
Basically, this is my troubleshooting methodology in such cases, first use diag sniffer to identify that traffic is reaching destination, than debug flow to analyze root cause. Debug flow will give you a clue when for example firewall policy is blocking traffic, routing is misconfigured, PBR issue and many, many other cases.