Design Considerations
There are two separate considerations when using two Internet uplinks: Link Redundancy and Load Sharing. These two features can be combined or implemented separately.
Scenario
|
Link Redundancy
|
Load Sharing
|
1
|
Yes
|
No
|
2
|
No
|
Yes
|
3
|
Yes
|
Yes
|
In each scenario, you must configure the appropriate firewall policies between the interfaces in question to allow the traffic - this document focuses on the routing issues.
Design Scenario #1: Link Redundancy (only)
If Internet access is no longer available on one link, you want traffic to make use of the other link.
a.
Routing
You need one default route for each interface. Indicate which route is preferable by specifying the distance - the lower distance route is declared active and placed in the routing table.
You need one default route for each interface. Indicate which route is preferable by specifying the distance - the lower distance route is declared active and placed in the routing table.
b.
Determining whether link is down (ping servers)
Define the ping server - this is a device that will respond to ping thereby indicating whether that link is up. It is usually recommended that you use the next hop / gateway device as your ping server.
Define the ping server under System > Network > Edit Interface.
Define the ping server - this is a device that will respond to ping thereby indicating whether that link is up. It is usually recommended that you use the next hop / gateway device as your ping server.
Define the ping server under System > Network > Edit Interface.
c.
Firewall policies
You must define duplicate firewall policies to ensure that after traffic fails over, it is permitted through the firewall. For example, Internal > WAN1 & Internal > WAN2.
You must define duplicate firewall policies to ensure that after traffic fails over, it is permitted through the firewall. For example, Internal > WAN1 & Internal > WAN2.
Design Scenario #2: Load Sharing (only)
You want to make use of both Internet links simultaneously but do not have any requirements for failing traffic over in the event of link failure.
What is the minimum needed as far as routing is concerned?
·
one default route for the primary link
·
direct other traffic over the other link using specific static routes
Design Scenario #3: Link Redundancy and Load Sharing
While both links are available, you want to distribute the Internet traffic over both links. In the event that a link fails, send all traffic over the active link.
Use default routes with equal distance
This is similar to scenario #1, except that both default routes must have equal distance. The end result is that both routes will remain in the active routing table and and can be viewed in the Routing Monitor (see GUI). The presence of both routes is needed to satisfy reverse path lookup (anti-spoofing feature).
Set the distance:
·
when defining the static route
or
or
·
for interfaces acquiring IP dynamically (DHCP or PPPoE), you can set the distance for the interface System > Network > Interface and configure the following:
i.
check "retrieve gateway" (adds default route automatically)
ii.
enter value in distance field
To guarantee that 1 link is always preferred:
Use a default policy route to indicate which interface is the preferred interface for accessing the Internet.
** Warning -- Configure this with care! **
If a policy route matches traffic, this policy route overrides all entries in the routing table including connected routes. Consequently, you may need to add specific policy routes that override these default policy routes. The policy routing table will be read top to bottom.
If a policy route matches traffic, this policy route overrides all entries in the routing table including connected routes. Consequently, you may need to add specific policy routes that override these default policy routes. The policy routing table will be read top to bottom.
To redirect traffic over the secondary link:
To make use of the secondary link, you need to use policy routes to direct some of the traffic onto it rather than onto the primary link.
When defining the policy route, it is best to only define the outgoing interface and leave the gateway blank. Leaving the gateway field blank ensures that the policy route will not be active when the link is down (it is affected by the ping server status).
Special Cases
1. Monitoring both WAN interfaces simultaneously.
If you need to be able to ping both WAN interfaces in order to demonstrate that the links are up, you will need to set the distance on both default routes to be the same.
Note: this is the same requirement as for Design Scenario #3.
Note: this is the same requirement as for Design Scenario #3.
2. Routing of traffic directed at VIPs.
Sessions associated with VIPs are handled in a special way.
Sessions associated with VIPs are handled in a special way.
Case Scenario #1 (VIP on non-default interface):
Let us say that you have a FortiGate-60, and the default gateway is pointing to WAN 1 but you have a VIP on WAN 2 that points to the web server in the DMZ.
Let us say that you have a FortiGate-60, and the default gateway is pointing to WAN 1 but you have a VIP on WAN 2 that points to the web server in the DMZ.
In this case, you do not need to create an additional static route or policy route for this VIP because a route cache entry is made which tells the FortiGate unit which interface it should use on the return path.
Case Scenario #2 (Redundany VIPs):
If you have redundant VIPs defined on each of the WAN interfaces (WAN1 and WAN2 in the case of a FortiGate-60)
If you have redundant VIPs defined on each of the WAN interfaces (WAN1 and WAN2 in the case of a FortiGate-60)
e.
inbound sessions will be handled as discussed in case scenario #1
f.
outbound sessions (initiated by the server) will have the server IP modified according to one of the 2 VIPs -- which VIP is selected depends on which interface has the preferred default route
Conclusion (redundant VIPs): make sure a policy route directs the server traffic out the desired interface.