Purpose
The purpose of this article is to describe the Fortinet PBR (Policy Based Routing) behavior by design.
The PBR should work with the IP written in the “gateway” label of the policy that represents a general hop, not necessary the next hop, in the network reachable via routing table in the same FortiGate unit.
This means the gateway could be any general hop IP, even not reachable by an ICMP test.
Scope
When a packet is received by the FortiGate unit and properly selected by a PBR (checking source destination IP addresses, incoming outgoing port and Destination service port), it uses the IP “gateway” suggested in PBR as destination. Then the FortiGate checks in its routing table the next hop for the IP “gateway” destination and sends out the packet previously filtered by the PBR.
Please note that the destination IP in the header packet has been never changed. So the PBR only works locally within a particular FortiGate unit.
In conclusion, two main characteristics must be kept in mind about PBR:
- the destination IP in the header packet doesn't change;
- the routing table doesn't change (the PBR’s check is done before the routing table check).
Diagram
Expectations, Requirements
Requirements
Only the FGT60C-crt-1 is used to test the PBR’s behavior, while FGT60C-crt-2 and FGT300C are used as two common routers.
Please note that FGT60C-crt-1 is physically connected to the other devices using two internal ports on same vlan.
L3 Connectivity:
Before applying the PBR, the ping to the common loopback IP (20.0.0.1) from a Laptop connected to FGT60C-crt-1 is going through the FGT60C-crt-2.
Then, PBR on the FGT60C-crt-1 has been added to change the ping going to the FG300C-crt-2 using a NON next hop IP. So, a static route on FG300C-crt-2, known by the FGT60C-crt-1 from the OSPF, is used.
The PBR should change the direction of the traffic, going now through the FG300C-crt-2, that has the PBR “gateway” location in his routing table (as a static route).
Configuration
Note: only the FGT60C-crt-1 is reported.
config router ospf
config area
edit 0.0.0.0
next
end
config network
edit 1
set prefix 10.100.0.0 255.255.252.0
next
end
config ospf-interface
edit "int1"
set cost 10
set interface "internal"
set ip 10.100.0.244
next
end
config redistribute "connected"
end
config redistribute "static"
set status enable
end
set router-id 1.1.1.1
Five static routes configured like this in the example:
config router static
edit 2
set device "wan2"
set dst 10.10.1.20 255.255.255.255
next
config system interface
edit "internal"
set vdom "root"
set ip 10.100.0.244 255.255.252.0
set allowaccess ping https ssh http telnet fgfm
set type physical
next
end
Intermediate Verification
Check, if the ping changes the path from the default next hop (FGT60C-crt-2) to the second one (FG300C-crt-2) just by disabling the Loopback on FGT60C-crt-2.
Verification
What follows proves that the PBR pointing to a static route behind the FG300C-crt-2 (10.10.1.30) changes the ping path from the default next hop (FGT60C-crt-2) to the second one (FG300C-crt-2) as expected by the PBR’s Fortinet design behavior.
The configuration to add on the FGT60C-crt-1 is:
The route in routing table for 20.0.0.1 is still pointing to the FG300C-crt-2 (see route for 20.0.0.1 below)
Conclusion:
It is possible to set a PBR route that points to a static route that is behind a next hop FortiGate unit (see the Scope paragraph).
The purpose of this article is to describe the Fortinet PBR (Policy Based Routing) behavior by design.
The PBR should work with the IP written in the “gateway” label of the policy that represents a general hop, not necessary the next hop, in the network reachable via routing table in the same FortiGate unit.
This means the gateway could be any general hop IP, even not reachable by an ICMP test.
Scope
The scope is to explain and demonstrate how the PBR and routing table check work together in FortiGate units.
When a packet is received by the FortiGate unit and properly selected by a PBR (checking source destination IP addresses, incoming outgoing port and Destination service port), it uses the IP “gateway” suggested in PBR as destination. Then the FortiGate checks in its routing table the next hop for the IP “gateway” destination and sends out the packet previously filtered by the PBR.
Please note that the destination IP in the header packet has been never changed. So the PBR only works locally within a particular FortiGate unit.
In conclusion, two main characteristics must be kept in mind about PBR:
- the destination IP in the header packet doesn't change;
- the routing table doesn't change (the PBR’s check is done before the routing table check).
Diagram
Expectations, Requirements
Requirements
Only the FGT60C-crt-1 is used to test the PBR’s behavior, while FGT60C-crt-2 and FGT300C are used as two common routers.
Please note that FGT60C-crt-1 is physically connected to the other devices using two internal ports on same vlan.
L3 Connectivity:
FGT60C-crt-1 has only one IP configured in the Internal ports (the two internal ports are running as switch port).
Moreover, all three devices run OSPF and have 5 static routes each redistributed on OSPF.
The two external devices have a route to the same IP using a loopback.
FGT60C-crt-1 sees the common IP loopback (20.0.0.1) through the OSPF redistribution and by default, it elects in its routing table the one from the FGT60C-crt-2.
Expectations
Before applying the PBR, the ping to the common loopback IP (20.0.0.1) from a Laptop connected to FGT60C-crt-1 is going through the FGT60C-crt-2.
Then, PBR on the FGT60C-crt-1 has been added to change the ping going to the FG300C-crt-2 using a NON next hop IP. So, a static route on FG300C-crt-2, known by the FGT60C-crt-1 from the OSPF, is used.
The PBR should change the direction of the traffic, going now through the FG300C-crt-2, that has the PBR “gateway” location in his routing table (as a static route).
Configuration
Note: only the FGT60C-crt-1 is reported.
config router ospf
config area
edit 0.0.0.0
next
end
config network
edit 1
set prefix 10.100.0.0 255.255.252.0
next
end
config ospf-interface
edit "int1"
set cost 10
set interface "internal"
set ip 10.100.0.244
next
end
config redistribute "connected"
end
config redistribute "static"
set status enable
end
set router-id 1.1.1.1
Five static routes configured like this in the example:
config router static
edit 2
set device "wan2"
set dst 10.10.1.20 255.255.255.255
next
config system interface
edit "internal"
set vdom "root"
set ip 10.100.0.244 255.255.252.0
set allowaccess ping https ssh http telnet fgfm
set type physical
next
end
Intermediate Verification
Check, if the ping changes the path from the default next hop (FGT60C-crt-2) to the second one (FG300C-crt-2) just by disabling the Loopback on FGT60C-crt-2.
Before disabling the Loopback on FGT60C-crt-2:
After disabling the Loopback on FGT60C-crt-2:
Verification
What follows proves that the PBR pointing to a static route behind the FG300C-crt-2 (10.10.1.30) changes the ping path from the default next hop (FGT60C-crt-2) to the second one (FG300C-crt-2) as expected by the PBR’s Fortinet design behavior.
The configuration to add on the FGT60C-crt-1 is:
config router policy
edit 1
set input-device "wan2"
set src 172.31.16.18 255.255.255.255
set gateway 10.10.1.30
set output-device "internal"
next
end
Before applying the changes:
After applying the PBR on the FGT60C-crt-1:
Conclusion:
It is possible to set a PBR route that points to a static route that is behind a next hop FortiGate unit (see the Scope paragraph).
