Adding a gateway
Static routes are a simple way to direct traffic exiting the FortiADC appliance — you can specify through which network interface a packet will leave, and the IP address of a next-hop router that is reachable from that network interface. Routers are aware of which IP addresses are reachable through various network pathways, and can forward those packets along pathways capable of reaching the packets’ ultimate destinations. Your FortiADC itself does not need to know the full route, as long as the routers can pass along the packet.
You must configure FortiADC with at least one static route that points to a router, often a router that is the gateway to the Internet. You may need to configure multiple static routes if you have multiple gateway routers (e.g. each of which should receive packets destined for a different subset of IP addresses), redundant routers (e.g. redundant Internet/ISP links), or other special routing cases.
| Alternatively, for traffic that your FortiADC is load balancing, you can also control the direction which FortiADC forwards packets by using: For information on how FortiADC chooses between the multiple packet forwarding methods that may apply, see “Sequence of packet routing evaluation”. |
However, often you will only need to configure one route: a default route.
For example, if a server is directly attached to one physical port on the FortiADC, but all other destinations, such as connecting clients, are located on distant networks, such as the Internet, you might need to add only one route: a default route that indicates the gateway router through which the FortiADC appliance can send traffic in the direction towards the Internet.
When you add a static route through the web UI, the FortiADC appliance evaluates the route to determine if it represents a different route compared to any other route already present in the list of static routes. If no route having the same destination exists in the list of static routes, the FortiADC appliance adds the static route, using the next unassigned route index number.
To add a static route via the web UI
1. Go to Router > Static > Static Route.
To access this part of the web UI, your administrator account’s access profile must have
Read-Write permission to items in the
Router category. For details, see
“Permissions”.
2. Click Add.
A dialog appears.
3. Configure these settings.
Setting name | Description |
Destination IP/Mask | Type the destination IP address and network mask of packets that will be subject to this static route, separated by a slash ( / ) or space. To make a default route for all packets, enter 0.0.0.0/0.0.0.0 or ::/0. |
Gateway | Type the IP address of the next-hop router where the FortiADC appliance will forward packets subject to this static route. This router must know how to route packets to the destination IP addresses that you have specified in Destination IP/Mask, or forward packets to another router with this information. For a direct Internet connection, this will be the router that forwards traffic towards the Internet, and could belong to your ISP. Note: The gateway IP address must be in the same subnet as an interface’s IP address. |
| Making a default route for your FortiADC is a typical best practice: if there is no other, more specific static route defined for a packet’s destination IP address, a default route will match the packet, and pass it to a gateway router so that any packet can reach its destination. If you do not define a default route, and if there is a gap in your routes where no route matches a packet’s destination IP address, packets passing through the FortiADC towards those IP addresses will, in effect, be null routed. While this can help to ensure that unintentional traffic cannot leave your FortiADC and therefore can be a type of security measure, the result is that you must modify your routes every time that a new valid destination is added to your network. Otherwise, it will be unreachable. A default route ensures that this kind of locally-caused “destination unreachable” problem does not occur. |
4. Click Save.
The FortiADC appliance should now be reachable to connections with networks indicated by the mask. Packets will egress from the network interface located on the same subnet as the gateway address.
5. To verify connectivity, from a host on the route’s destination network, attempt to connect to the FortiADC appliance’s web UI via HTTP and/or HTTPS. (At this point in the installation, you have not yet configured load balancing, and therefore cannot test connectivity through the FortiADC.)
If the connectivity test fails, you can use the CLI commands:
execute ping <destination_ip4>
to determine if a complete route exists from the FortiADC to the host, and
execute traceroute <destination_ipv4>
to determine the point of connectivity failure.
Also enable
PING on the FortiADC’s network interface, or configure an IP address on the bridge, then use the equivalent
tracert or
traceroute command on the host (depending on its operating system) to test routability for traffic traveling in the opposite direction: from the host to the FortiADC.
• If these tests
fail, or if you do not want to enable
PING, first examine the static route configuration on both the host and FortiADC.
To display the routing table, enter the CLI command:
diagnose netlink route list
You may also need to verify that the physical cabling is reliable and not loose or broken, that there are no IP address or MAC address conflicts or blacklisting, and otherwise rule out problems at the physical, network, and transport layer.
• If these tests succeed, a route exists, but you cannot connect using HTTP or HTTPS, an application-layer problem is preventing connectivity.
Verify that you have enabled
HTTPS and/or
HTTP on the network interface. Also examine routers and firewalls between the host and the FortiADC appliance to verify that they permit HTTP and/or HTTPS connectivity between them. Finally, you can also use the CLI command:
diagnose system top 5 delay 30
to verify that the daemons for the web UI and CLI, such as sshd, cli, nginx, and php-fpm are running and not overburdened.
To add a default route via the CLI
1. Enter the following commands:
config router static
edit <route_index>
set gateway <gateway_ipv4>
end
where:
• <route_index> is the index number of the route in the list of static routes
• <gateway_ipv4> is the IP address of the gateway router
The FortiADC appliance should now be reachable to connections with networks indicated by the mask.
2. To verify connectivity, from a host on the route’s destination network, attempt to connect to the FortiADC appliance’s web UI via HTTP and/or HTTPS. (At this point in the installation, you have not yet configured load balancing, and therefore cannot test connectivity through the FortiADC.)
If the connectivity test fails, you can use the CLI commands:
execute ping
to determine if a complete route exists from the FortiADC to the host, and
execute traceroute
to determine the point of connectivity failure. Also enable
ping on the FortiADC (see
“To configure a network interface’s IP address via the CLI”), then use the equivalent
tracert or
traceroute command on the host (depending on its operating system) to test routability for traffic traveling in the opposite direction: from the host to the FortiADC.
• If these tests
fail, or if you do not want to enable
PING, first examine the static route configuration on both the host and FortiADC.
To display all routes with their priorities, enter the CLI command:
diagnose netlink route list
You may also need to verify that the physical cabling is reliable and not loose or broken, that there are no IP address or MAC address conflicts or blacklisting, and otherwise rule out problems at the physical, network, and transport layer.
• If these tests succeed, a route exists, but you cannot connect using HTTP or HTTPS, an application-layer problem is preventing connectivity.
Verify that you have enabled
http and/or
http on the network interface (
“To configure a network interface’s IP address via the CLI”). Also examine routers and firewalls between the host and the FortiADC appliance to verify that they permit HTTP and/or HTTPS connectivity between them. Finally, you can also use the CLI command:
diagnose system top 5 delay 30
to verify that the daemons for the web UI and CLI, such as sshd, cli, nginx, and php-fpm are running and not overburdened.
See also