Routing Issue w/ SD-WAN

[Jyce]

Hi Guys,

I'm trying to fix an issue with an SD-WAN connection between 2 Fortigate firewall (v6.2.1).

Find attached the network configuration.

I can successfully ping from 172.16.210.30 to 172.16.37.30, but ping to 192.168.5.248 fails.

A tcpdump on the server 192.168.5.248 shows that the server receive the ICMP 'echo request' and send back the ICMP 'echo reply'.

A tracert -d 192.168.5.248 from 172.16.210.30 is stuck @ 10.10.201.2.

Can someone tell me why server 192.168.4.248 is no reachable (I can see the rule that allowed the traffic) ?

Thanks & Best Regards.

Jean-Christophe

[emnoc]

A tracert -d 192.168.5.248 from 172.16.210.30 is stuck @ 10.10.201.2.

Start here and look at your policies. Also diag debug flow is your  best friend here assuming these are all Fortigates

You ruled 89% of this out by seeing the pings reaching the server. I would look at SNAT rules if applicable  and next-hops gateways

Ken Felix

[Toshi_Esumi]

In the diagram you put 10.10.201.x/32 on the WAN interface, which are private IPs. Are they VPN interface IPs and a site-to-site VPN is there over SD-WAN interface on both sides?

If a ping packet can reach the destination, that direction is working fine including routes and policies. Then likely the problem is on the returning direction either no route for the source subnet, no policy for the direction through the VPN, or phase2 selectors are not allowing for the direction.

The "diag debug flow" on the FGT w/ 10.10.201.2 would show exactly why it is dropped there as Ken suggest. But just checking routes and polcies and vpn config would probably let you find the problem easily.

[Toshi_Esumi]

I need to correct my misstatements in my previous post.

If ping request packets reach the destination, you have enough policies on both FGTs for that particular direction of pinging. One direction policy should be enough. You might not be able to ping from the opposite side though.

Then since phase2 selectors need to be matching both ends, you should have proper phase2 selector(s) too.

So, I would check the returning routes first, then go to "diag debug flow" as Ken suggests.