Disabling RPF (Reverse Path Forwarding)

Fix the real problem in this case. So for your PBR for other traffic/network, is the remote knows to reply to that src_network via the WAN2 vrs MPLS cloud? basically, If I' m missing something from your simple but effective diagram, the left FW1 is routing over WAN2, so how does the rightside FW2 know about the 192.168.2.2 server? Can you place a " static" route on that firewall that says to use " wan2" to reach that host ? Or are we missing something? Route selection be via most exact match, so FW2 will say to reach this host use my WAN2 and for all other traffic in the 192.168.2.0/24 network use the MPLS If the later is doable, than RPF checks & maintaining statefull-checks would not be an issues and will still pass.

Thanks for the answer. On Firewall 1 - peer1 - we have: -policy route that says traffic from 192.168.2.1/32 to 10.1.102.0/24 goes through wan1 -static route to 10.1.102.0/24 through wan2 (this is for the rest of the net 192.168.2.0 be able to reach 10.1.102.0) On Firewall 2 - peer 2 -we have: -No policy route,only static routes -static host route to 192.168.2.1/32 through wan1 -static route to 192.168.2.0/24 through wan2 On both Firewalls we are permitting everything with FW policies. The problem is that when I do a ping from a PC in 10.1.102.0 to 192.168.2.1 the packet is dropped (because of RPF) because on Firewall 1 the packet arrives through wan1 (with origin IP 10.1.102.X) but in Its routing table It has a route back to 10.1.102.X through wan2 so It drops the packet because of RPF. If I enable asymetric routing on Firewall 1 the packets are not dropped,but I want to accomplish this without asym routing. Thanks in advance.

So if I' m hearing you correct, the PBR statement is not effecting ICMP traffic ? If that' s the case, it because the policy route statement is typically for some higher layer protocol & is not taking place for any icmp protocol ( proto #1 ), so that' s why the " pings" are dropping. And since you have a static for the hotst, it goes back thru the opposite WAN that the icmp originated from. (suggestion) Maybe ( just maybe ) , could you set a fwpolicy with NAT so that this traffic is NAT' d via the WAN interface address. This should give you " icmp ping checks" , ignores any PBR for icmp and all should be happy.

Hi,Im having the problem with all kind of traffic,not just icmp. Maybe the only solution is to enable asym routing... I dont know Thanks.

Post your PBR configuration and appropriate fwpolicies for the traffic that' s failing. Also have you diag debug flow any of the traffic that' s failing? You made the assumption is due to RPF so look at the policy to see what/where it' s failing at to make 100% sure that' s the issue. Also why do you need to PBR traffic over one WAN vrs the other?

The PBR configuration is very simple : policy route that says traffic from 192.168.2.1/32 to 10.1.102.0/24 goes through wan1 (very simple) The FW policies are allowing everithig in every interfaces involved. I did the diag debug flow commands before and with this was that I realized that RPF was dropping pakets. And I need PBR because how else can I tell the FW to route origin IP 192.168.2.1 to wan1? I need PBR to route traffic based on the source addresses. Thanks.

Kamarale, your analysis is IMHO absolutely correct. Because RBP bypasses the routing table the RPF drops the packets. Seems there is no other way to cure this than to disable RPF altogether (which is bad). I agree that the RPF should check all route based policies as well as the routing table. If you think it' s important you should bring this issue to Fortinet' s attention so that they can consider changing the procedure, by opening a support call. You have collected enough evidence to back up your arguments.