External traffic from secondary WAN link being blocked

[hwong]

Hi all,

My set up is a little weird so I'll explain that first. Our network is migrating between one WAN provider to another. Originally it pretty much had the following links:

- WAN (to other branches)

- Internet

- Local subnets

As we are now transitioning to another WAN slowly, we added another port for use with the new WAN.

- WAN (to other branches)

- Internet

- Local subnets

- New WAN with internet

So the new WAN will at the end replace both our original links, but for now we are trying to have some of our existing externally accessible services moved over to the new WAN. NAT for it is handled a few hops from our fortigate. I've added a default route to the fortigate for the new WAN with a lower priority and was planning to use Policy Routes to forward traffic to the correct link.

Problem:

External access via the new WAN does not seem to work. The packets are hitting our fortigate but it does not get forwarded to the destination subnet. It does not matter if I implemented the policy routes or not, the packet sniffer is not picking up traffic to the target IP on the destination subnet. In terms of policy rules. I have ALL on the WAN side and the target subnet for the destination side.

Anyone with ideas on where this is going wrong for me?

[emnoc]

The diagnostic command diag debug flow should be used 1st for all flow related issues. Do a search here for numerous examples of how to conduct this cmd and provide the output here if you can't follow the output.

(just guessing ) but it sounds like a policy ordering issue, but can you ping the 2nd wan next-hop for starters?

[hwong]

Thanks. I tried it and got :

id=20085 trace_id=6 msg="vd-root received a packet(proto=6, e.e.e.e:34783->y.y.y.y:10018) from port1."

id=20085 trace_id=6 msg="allocate a new session-211ad2e2"

id=20085 trace_id=6 msg="reverse path check fail, drop"

So I suppose that means that it is disregarding static route? I added a policy route in but it didn't change the outcome:

config router policy

 edit 1

 set input-device "DATA-LAN-L2"

 set src "y.y.y.y/32"

 set dst "0.0.0.0/0.0.0.0"

 set gateway x.x.x.x

 set output-device "port1"

 next

end

port1 being the what the 2nd WAN is being connected to and x.x.x.x being the WAN next hop.

Looks like this is caused by Reverse Path Forwarding checks.