Policy based routing, design considerations.

[#1]

Just to define our simplified Network: We have one FortiGate unit. Internally there are 2 clients (ClientA and ClientB) in different subnets. We have two internet connections with static IP' s (ordinary Ethernet, no PPPoE) on WAN1 and WAN2 with gateways Gateway1 and Gateway2. One remote Subnet (Remote3) can be reached via Gateway3 on the DMZ interface and another remote subnet Remote4 is reached via policy-based IPSec. Our main goal: All routing should be done *normally* with static routes and WAN1 etc. except: ClientB (identified by source IP) should be routed to the Internet with WAN2 if ((destination != Remote3 or destination != Remote4 or destination != DMZ) and WAN2 is up) else route via WAN1. We start right with the previous definition, without WAN2 (and policy based routing). We do not consider NAT, Firewall policies since they are not relevant for this routing issue. As far as I got it (please correct me if I' m wrong): - Add a second default route using WAN2 with Gateway2 with the same Metric as the existing default route to WAN1. - set the priority of the WAN2 default route to a higher number than the WAN1 default route. - add a ping Server to the WAN2 interface and activate ping server. - add a policy route with " from" as internal/ClientB to force to WAN2 (without specifying the Gateway). - Is ClientB able to connect to Remote3 (since there is only a static route and no policy route)? Do I need an extra policy route? - Is this document " FortiGate Route Preference and Priority" http://kc.forticare.com/tmp/2008-5-17_6-56_63_1123_01-28009-0197-20050413_FortiGate_Route_Preference_and_Priority_Technical_Note.pdf still the most recent? - What if a packet matches a policy based routing entry, but no gateway or outgoing interface is matched? Can I use this to escape the policy based routing for some address range (e.g. add a policy based route with source=Client2 and no destination interface or gateway defined on top to route the private subnets like 10.0.0.0/8 using the traditional static routing table and force all other destinations to WAN2) - Do I need an extra policy route or static route for Client3 -> Remote4 (the IPSec thing)? - Do I need an extra static route for the IPSec Peers of the connection to Remote4 or is the default routing sufficient? - In Case the ping Server on WAN2 is unreachable, the default route to WAN2 is disabled. But the policy based routing forces this specific traffic still to WAN2. So there is no failover. Right? Is there any simple way to do this? Thank you for your help! Yours, woswasi

[abelio]

- Add a second default route using WAN2 with Gateway2 with the same Metric as the existing default route to WAN1.

agree

- set the priority of the WAN2 default route to a higher number than the WAN1 default route.

agree

- add a ping Server to the WAN2 interface and activate ping server.

only needed if you want failover over wan1 if wan2 eventually fails

- add a policy route with " from" as internal/ClientB to force to WAN2 (without specifying the Gateway).

ok; but ' blank' gateway is only for failover purposes

- Is ClientB able to connect to Remote3 (since there is only a static route and no policy route)? Do I need an extra policy route?

Only if metric distance of the static route to remote3 gateway is lower than respective one form wan1/2. If not the case, you' ll need the policy route.

- Is this document " FortiGate Route Preference and Priority" http://kc.forticare.com/tmp/2008-5-17_6-56_63_1123_01-28009-0197-20050413_FortiGate_Route_Preference_and_Priority_Technical_Note.pdf still the most recent?

an april2005 doc for fortios 2.80 doesn' t help too much.

- What if a packet matches a policy based routing entry, but no gateway or outgoing interface is matched?

output-device (outgoing interface) setting is mandatory in a policy route.

Can I use this to escape the policy based routing for some address range (e.g. add a policy based route with source=Client2 and no destination interface or gateway defined on top to route the private subnets like 10.0.0.0/8 using the traditional static routing table and force all other destinations to WAN2)

Quick answer should be no. Did you try? You need specify output-device; leaving the gateway blank is a trick to failover to the default alive connection, in your case is wan1.

- Do I need an extra policy route or static route for Client3 -> Remote4 (the IPSec thing)?

No policy routes, but consider the metric stuff if you use route based vpn

- In Case the ping Server on WAN2 is unreachable, the default route to WAN2 is disabled. But the policy based routing forces this specific traffic still to WAN2. So there is no failover. Right? Is there any simple way to do this?

leaving gateway blank in those router policies. regards

[#3]

sorry for the late answer, but I did some research and made a few tests.

Can I use this to escape the policy based routing for some address range (e.g. add a policy based route with source=Client2 and no destination interface or gateway defined on top to route the private subnets like 10.0.0.0/8 using the traditional static routing table and force all other destinations to WAN2)

Quick answer should be no. Did you try? You need specify output-device; leaving the gateway blank is a trick to failover to the default alive connection, in your case is wan1.

Actually nearly all information in the policy route is optional, including the output-device. According to some hints at http://docs.forticare.com/fgt/archives/3.0/techdocs/FortiGate_Administration_Guide_01-30005-0203-20070830.pdf page 239, the unit " may refer to the routing table in an attempt to match the information in the packet header with a route in the routing table" in casepolicy routing is not fully specified. In the tests it seems to work: 1st policy route: Source=ClientB, inbound_interface=internal destination 10.0.0.0/255.0.0.0 no gateway, no outbound interface. 2nd policy route: Source=ClientB, inbound_interface=internal destination 0.0.0.0/0.0.0.0 gateway specified, outbound interface=WAN1. In this case it seems that all traffic (including those to directly connected 192.168.x.y Network and static route to 172.16.2.0/28) is sent to WAN1 except traffic to 10.a.b.c. The 10.0.0.0/8 Network seems to be routed ' normally' according to the static routing table.

- What if a packet matches a policy based routing entry, but no gateway or outgoing interface is matched?

output-device (outgoing interface) setting is mandatory in a policy route.

seems that this is false.

- Do I need an extra policy route or static route for Client3 -> Remote4 (the IPSec thing)?

No policy routes, but consider the metric stuff if you use route based vpn

[using policy based VPN] - Yes, i need a policy route, since whenever a packet matches a (destination fully specified) policy based routing entry, the static routing table is never gets ' asked' . I still have to test alls those failover events in the lab. Regards, woswasi

[abelio]

ORIGINAL: woswasi seems that this is false.

interesting.... it seems to be a MR firmware version matter.. I' ve checked with MR5 and MR6 and it let put things like: config router policy edit 1 set dst 10.0.0.0 255.0.0.0 set end-port 65535 set gateway 0.0.0.0 set input-device " internal" set output-device ' ' set protocol 0 set src 192.168.100.0 255.255.255.0 set start-port 1 next end But MR3 and MR2 (two boxes i could test) don' t, both claims when i tried to leave output-device empty.. ... (1)$ set output-device ' ' entry not found in datasource value parse error before ' ' Command fail. Return code -3 ...

[using policy based VPN] - Yes, i need a policy route, since whenever a packet matches a (destination fully specified) policy based routing entry, the static routing table is never gets ' asked' .

did you define such one policy route?

I still have to test alls those failover events in the lab.

good idea, and post the results and firmware version please.

[#5]

Hi Abelio! Very interesting... I just tried it with: Fortigate-200A 3.00-b0568(MR5 Patch 3) Currently I see no reson to change this version since it seems to be working fine ;-)

[using policy based VPN] - Yes, i need a policy route, since whenever a packet matches a (destination fully specified) policy based routing entry, the static routing table is never gets ' asked' .

did you define such one policy route?

Actually I did not fully rebuild this, since the solution with the empty output-device and empty gateway seems to be working and I read this in a manual some time ago. But you are right. This has to be verified. My hint: I have some IPSec tunnels with 10.0.0.0 as destination. This was not working with just one policy route (Source=ClientB, inbound_interface=internal destination 0.0.0.0/0.0.0.0 gateway specified, outbound interface=WAN2) but worked with both (policy route *exception* as mentioned above). All 10.x.y.z seem to behave as there was no policy routing at all. I will do the failover tests hopefully in about a week (next week I will be pretty busy). If I have to guess, failover will not work, since with policy based routing forces the traffic to one WAN interface, no matter what I do with ping server etc. Maybe not specifying the default gateway will help ;-) Then it would go back to ordinary routing and it is looking for the static default route. But following the admin guide, it will then be forced to the wrong interface... hmmmm.