Configuring the network settings

When shipped, each of the FortiWeb appliance’s physical network adapter ports (or, for FortiWeb‑VM, vNICs) has a default IP address and netmask. If these IP addresses and netmasks are not compatible with the design of your unique network, you must configure them.

Default IP addresses and netmasks

You also must configure FortiWeb with the IP address of your DNS servers and gateway router.

You can use either the web UI or the CLI to configure these basic network settings.

If you are installing a FortiWeb-VM virtual appliance, and you followed the instructions in the FortiWeb-VM Install Guide, you have already configured some of the settings for port1. To fully configure all of the network interfaces, you must complete this chapter.

Network interface or bridge?

To connect to the CLI and web UI, you must assign at least one FortiWeb network interface (usually port1) with an IP address and netmask so that it can receive your connections. Depending on your network, you usually must configure others so that FortiWeb can connect to the Internet and to the web servers it protects.

How should you configure the other network interfaces? Should you add more? Should each have an IP address? That varies. In some cases, you may not want to assign IP addresses to the other network interfaces.

Initially, each physical network port (or, on FortiWeb-VM, a vNIC) has only one network interface that directly corresponds to it — that is, a “physical network interface.” Multiple network interfaces (“subinterfaces” or “virtual interfaces”) can be associated with a single physical port, and vice versa (“redundant interfaces”/”NIC teaming”/”NIC bonding” or “aggregated links”). These can provide features such as link failure resilience or multi-network links.

FortiWeb does not currently support IPSec VPN virtual interfaces nor redundant links. If you require these features, implement them separately on your FortiGate, VPN appliance, or firewall.

Usually, each network interface has at least one IP address and netmask. However, this is not true for bridges.

Bridges (V-zones) allow packets to travel between the FortiWeb appliance’s physical network ports over a physical layer link, without an IP layer connection with those ports.

Use bridges when:

• the FortiWeb appliance operates in true transparent proxy or transparent inspection mode, and
• you want to deploy FortiWeb between incoming connections and the web server it is protecting, without changing your IP address scheme or performing routing or network address translation (NAT)

For bridges, do not assign IP addresses to the ports that you will connect to either the web server or to the overall network. Instead, group the two physical network ports by adding their associated network interfaces to a bridge.

Configure each network interface that will connect to your network or computer (see Configuring the network interfaces or Configuring a bridge (V-zone)). If you want multiple networks to use the same wire while minimizing the scope of broadcasts, configure VLANs (see Adding VLAN subinterfaces).

See also

• Configuring the network interfaces
• Adding VLAN subinterfaces
• Link aggregation
• Configuring a bridge (V-zone)

Configuring the network interfaces

You can configure network interfaces either via the web UI or the CLI. If your network uses VLANs, you can also configure VLAN subinterfaces. For details, see Adding VLAN subinterfaces.

If the FortiWeb appliance is operating in true transparent proxy or transparent inspection mode and you will configure a V-zone (bridge), do not configure any physical network interfaces other than port1. Configured NICs cannot be added to a bridge. For details, see Configuring a bridge (V-zone).

If this FortiWeb will belong to a FortiWeb HA cluster, do not configure any network interface that will be used as an HA heartbeat and synchronization link. If you are re-cabling your network and must configure it, connect and switch to the new HA link first. Failure to do so could cause unintentional downtime, failover, and ignored IP address configuration. To switch the HA link, see Configuring a high availability (HA) FortiWeb cluster.

To customize the network interface information that FortiWeb displays when you go to System > Network > Interface, right-click the heading row. Select and clear the columns you want to display or hide, and then click Apply.

To configure a network interface’s IP address via the web UI

1.  Go to System > Network > Interface.

To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Network Configuration category. For details, see Permissions.

If the network interface’s Status column is Bring Up, its administrative status is currently “down” and it will not receive or emit packets, even if you otherwise configure it. To bring up the network interface, click the Bring Up link.

This Status column is not the detected physical link status; it is the administrative status that indicates whether you permit network interface to receive and/or transmit packets. For example, if the cable is physically unplugged, diagnose hardware nic list port1 or Operation widget may indicate that the link is down, even though you have administratively enabled it by clicking Bring Up. By definition, HA heartbeat and synchronization links should always be “up.” Therefore, if you have configured FortiWeb to use a network interface for HA, its Status column will always display HA Member.

2.  Double-click the row of the network interface that you want to modify.

The Edit Interface dialog appears. Name displays the name and media access control (MAC) address of this network interface. The network interface is directly associated with one physical link as indicated by its name, such as port2.

In HA, it may use a virtual MAC instead. See HA heartbeat & synchronization and Configuring a high availability (HA) FortiWeb cluster.

3.  Configure these settings:

4.  Click OK.

If you were connected to the web UI through this network interface, you are now disconnected from it.

5.  To access the web UI again, in your web browser, modify the URL t to match the new IP address of the network interface. For example, if you configured the network interface with the IP address 10.10.10.5, you would browse to: https://10.10.10.5

If the new IP address is on a different subnet than the previous IP address, and your computer is directly connected to the FortiWeb appliance, you may also need to modify the IP address and subnet of your computer to match the FortiWeb appliance’s new IP address.

To configure a network interface’s IPv4 address via the CLI

Enter the following commands:

config system interface

edit <interface_name>

set mode {manual|dhcp}

set ip <address_ipv4mask> <netmask_ipv4mask>

set allowaccess {http https ping snmp ssh telnet}

end

where:

• <interface_name> is the name of a network interface
• {manual|dhcp} specifies how the network interface is addressed.
• <address_ipv4> is the IP address assigned to the network interface
• <netmask_ipv4mask> is its netmask in dotted decimal format
• {http https ping snmp ssh telnet} is a space-delimited list of zero or more administrative protocols that you want to allow to access the FortiWeb appliance through the network interface

HTTP and Telnet connections are not secure, and can be intercepted by a third party. If possible, enable this option only for network interfaces connected to a trusted private network, or directly to your management computer. Failure to restrict administrative access through this protocol could compromise the security of your FortiWeb appliance.

If you were connected to the CLI through this network interface, you are now disconnected from it.

To access the CLI again, in your terminal client, modify the address to match the new IP address of the network interface. For example, if you configured the network interface with the IP address 172.16.1.20, you would connect to that IP address.

If the new IP address is on a different subnet than the previous IP address, and your computer is directly connected to the FortiWeb appliance, you may also need to modify the IP address and subnet of your computer to match the FortiWeb appliance’s new IP address.

Adding VLAN subinterfaces

You can add a virtual local area network (VLAN) subinterface to a network interface or bridge on the FortiWeb appliance.

Similar to a local area network (LAN), use a IEEE 802.1q VLAN to reduce the size of a broadcast domain and thereby reduce the amount of broadcast traffic received by network hosts, improving network performance.

VLANs are not designed to be a security measure, and should not be used where untrusted devices and/or individuals outside of your organization have access to the equipment. VLAN tags are not authenticated, and can be ignored or modified by attackers. VLAN tags rely on the voluntary compliance of the receiving host or switch.

Unlike physical LANs, VLANs do not require you to install separate hardware switches and routers to achieve this effect. Instead, VLAN-compliant switches, such as FortiWeb appliances, restrict broadcast traffic based upon whether its VLAN ID matches that of the destination network. As such, VLAN trunks can be used to join physically distant broadcast domains as if they were close.

The VLAN ID is part of the tag that is inserted into each Ethernet frame in order to identify traffic for a specific VLAN. VLAN header addition is handled automatically by FortiWeb appliances, and does not require that you adjust the maximum transmission unit (MTU). Depending on whether the device receiving a packet operates at Layer 2 or Layer 3 of the network, this tag may be added, removed, or rewritten before forwarding to other nodes on the network.

Cisco Discovery Protocol (CDP) is supported for VLANs, including when FortiWeb is operating in either of the transparent modes.

If your FortiWeb model uses Data Plane Development Kit (DPDK) for packet processing (for example, models 3000E, 3010E and 4000E), you cannot use VLAN subinterfaces as a data capture port for offline protection mode. For these models, remove any VLAN configuration on an interface before you use it for data capture. These models fully support the capture and transmission of VLAN traffic.

To configure a VLAN subinterface

1.  Go to System > Network > Interface.

To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Network Configuration category. For details, see Permissions.

2.  Click Create New.

3.  Configure these settings:

4.  Click OK.

Your new VLAN is initially hidden in the list of network interfaces.

To expand the network interface listing in order to view all of a port’s associated VLANs, click the + (plus sign) the name of the port.

See also

• IPv6 support
• Network interface or bridge?
• Configuring a bridge (V-zone)
• Link aggregation
• Configuring DNS settings
• Adding a gateway
• Fail-to-wire for power loss/reboots
• Global web UI & CLI settings

Link aggregation

You can configure a network interface that is the bundle of several physical links via either the web UI or the CLI.

Link aggregation is currently supported only when FortiWeb is deployed in reverse proxy mode. It cannot be applied to VLAN subinterfaces, nor to ports that are used for the HA heartbeat. It is not supported in FortiWeb-VM.

Link aggregation (also called NIC teaming/bonding or link bundling) forms a network interface that queues and transmits over multiple wires (also called a port channel), instead of only a single wire (as FortiWeb would normally do with a single network interface per physical port). This multiplies the bandwidth that is available to the network interface, and therefore is useful if FortiWeb will be inline with your network backbone.

Link aggregation on FortiWeb complies with IEEE 802.3ad and distributes Ethernet frames using a modified round-robin behavior. If a port in the aggregate fails, traffic is redistributed automatically to the remaining ports with the only noticeable effect being a reduced bandwidth. When broadcast or multicast traffic is received on a port in the aggregate, reverse traffic will return on the same port.

When link aggregation uses a round-robin that considers only Layer 2, Ethernet frames that comprise an HTTP request can sometimes arrive out of order. Because network protocols at higher layers often do not gracefully handle this (especially TCP, which may decrease network performance by requesting retransmission when the expected segment does not arrive), FortiWeb’s frame distribution algorithm is configurable.

For example, if you notice that performance with link aggregation is not as high as you expect, you could try configuring FortiWeb to queue related frames consistently to the same port by considering the IP session (Layer 3) and TCP connection (Layer 4), not simply the MAC address (Layer 2).

You must also configure the router, switch, or other link aggregation control protocol (LACP)-compatible device at the other end of FortiWeb’s network cables to match, with identical:

• link speed
• duplex/simplex setting
• ports that can be aggregated

This will allow the two devices to use the cables between those ports to form a trunk, not an accidental Layer 2 (link) network loop. FortiWeb will use LACP to:

• detect suitable links between itself and the other device, and form a single logical link
• detect individual port failure so that the aggregate can redistribute queuing to avoid a failed port

To configure a link aggregate interface

1.  Go to System > Network > Interface.

To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Network Configuration category. For details, see Permissions.

2.  Click Create New.

3.  Configure these settings:

4.  Click OK.

Your new aggregate appears in the list of network interfaces.

To configure an IPv4link aggregate via the CLI

Enter the following commands:

config system interface

edit "aggregate"

set type agg

set status up

set intf <port_name> <port_name>

set algorithm {layer2 | layer2_3 | layer3_4}

set lacp-speed {fast | slow}

set mode {manual | dhcp}

set ip <address_ipv4> <netmask_ipv4mask>

next

end

where:

• <port_name> is the name of a physical network interface, such as port3
• <address_ipv4> is the IP address assigned to the network interface
• <netmask_ipv4mask> is its netmask in dotted decimal format
• {manual | dhcp} specifies how the network interface is addressed.
• {layer2 | layer2_3 | layer3_4} is a choice between the connectivity layers that will be considered when distributing frames among the aggregated physical ports.
• {fast | slow} is a choice of the rate of transmission for the LACP frames (LACPUs) between FortiWeb and the peer device at the other end of the trunking cables; this must match the LACP peer

See also

• Network interface or bridge?
• Configuring the network interfaces
• Configuring a bridge (V-zone)
• Adding a gateway

Configuring a bridge (V-zone)

You can configure a bridge either via the web UI or the CLI.

Bridges allow network connections to travel through the FortiWeb appliance’s physical network ports without explicitly connecting to one of its IP addresses. Due to this nature, bridges are configured only when FortiWeb is operating in either true transparent proxy or transparent inspection mode.

Bridges on the FortiWeb appliance support IEEE 802.1d spanning tree protocol (STP) by forwarding bridge protocol data unit (BPDU) packets, but do not generate BPDU packets of their own. Therefore, in some cases, you might need to manually test the bridged network for Layer 2 loops. Also, you may prefer to manually design a tree that uses the minimum cost path to the root switch for design and performance reasons.

True bridges typically have no IP address of their own. They use only media access control (MAC) addresses to describe the location of physical ports within the scope of their network and do network switching at Layer 2 of the OSI model.

You can configure FortiWeb to monitor the members of bridge. When monitoring is enabled, if a network interface that belongs to the bridge goes down, FortiWeb automatically brings down the other members.

Using network interface MAC addresses in true transparent proxy mode

When the operation mode is true transparent proxy, by default, traffic that travels through a bridge to the back-end servers preserves the MAC address of the source.

If you are using FortiWeb with front-end load balancers that are in a high availability cluster that connects via multiple bridges, this mechanism can cause switching problems on failover.

To avoid this problem, the config system v-zone command allows you to configure FortiWeb to use the MAC address of the FortiWeb network interface instead. The option is not available in the web UI. For more information, see the FortiWeb CLI Reference.

To configure a bridge via the web UI

1.  If you have installed a physical FortiWeb appliance, plug in network cables to connect one of the physical ports in the bridge to your protected web servers, and the other port to the Internet or your internal network.

Because port1 is reserved for connections with your management computer, for physical appliances, this means that you must plug cables into at least 3 physical ports:

• port1 to your management computer
• one port to your web servers
• one port to the Internet or your internal network

If you have installed a virtual FortiWeb appliance (FortiWeb-VM), the number and topology of connections of your physical ports depend on your vNIC mappings. For details, see the FortiWeb-VM Install Guide.

To use fail-to-wire, the bridge must be comprised of the ports that have hardware support for fail-to-wire. For example, on FortiWeb 1000C, this is port3 and port4. See Fail-to-wire for power loss/reboots and the QuickStart Guide for your model.

2.  If you have installed FortiWeb-VM, configure the virtual switch (vSwitch). For details, see the FortiWeb-VM Install Guide.

3.  Go to System > Network > V-zone.

This option is not displayed if the current operating mode does not support bridges.

To access this part of the web UI, your administrator's account access profile must have Read and Write permission to items in the Network Configuration category. For details, see Permissions.

4.  Click Create New.

5.  Configure these settings:

6.  Click OK.

The bridge appears in System > Network > V-zone.

7.   To configure FortiWeb to automatically bring down all members of this v-zone when one member goes down, select Member Monitor.

8.  To use the bridge, select it in a policy (see Configuring a server policy).

To configure an IPv4 bridge in the CLI

1.  If you have installed a physical FortiWeb appliance, connect one of the physical ports in the bridge to your protected web servers, and the other port to the Internet or your internal network.

Because port1 is reserved for connections with your management computer, for physical appliances, this means that you must connect at least 3 ports:

• port1 to your management computer
• one port to your web servers
• one port to the Internet or your internal network

If you have installed a virtual FortiWeb appliance, the number and topology of connections of your physical ports depend on your vNIC mappings. For details, see the FortiWeb-VM Install Guide.

2.  If you have installed FortiWeb as a virtual appliance (FortiWeb-VM), configure the virtual switch. For details, see the FortiWeb-VM Install Guide.

3.  Enter the following commands:

config system v-zone

edit <v-zone_name>

[set ip <address_ipv4> <netmask_ipv4>]

set interfaces {<port_name> ...}

set monitor {enable | disable}

end

where:

• <v-zone_name> is the name of the bridge
• {<port_name> ...} is a space-delimited list of one or more network ports that will be members of this bridge. Eligible network ports must not yet belong to a bridge, and have no assigned IP address. For a list of eligible ports, enter:
  
  set interfaces ?
  
  
• <address_ipv4> <netmask_ipv4> is an IP address for the bridge ports, if the operating mode is transparent inspection
• set monitor {enable | disable} is an optional setting that specifies whether FortiWeb automatically brings down all members of this v-zone when one member goes down.

4.  To use the bridge, select it in a policy (see Configuring a server policy).

See also

• Network interface or bridge?
• Configuring the network interfaces
• Link aggregation
• Adding a gateway

Adding a gateway

Static routes direct traffic exiting the FortiWeb appliance based upon the packet’s destination — you can specify through which network interface a packet leaves 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 FortiWeb itself does not need to know the full route, as long as the routers can pass along the packet.

You must configure FortiWeb 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.

However, often you will only need to configure one route: a default route.

True transparent and transparent inspection operation modes require that you specify the gateway when configuring the operation mode. In that case, you have already configured a static route. You do not need to repeat this step.

For example, if a web server is directly attached to one physical port on the FortiWeb, 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 FortiWeb sends traffic towards the Internet.

If your management computer is not directly attached to one of the physical ports of the FortiWeb appliance, you may also require a static route so that your management computer is able to connect with the web UI and CLI.

When you add a static route through the web UI, the FortiWeb 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 FortiWeb appliance adds the static route, using the next unassigned route index number.

The index number of the route in the list of static routes is not necessarily the same as its position in the routing table (diagnose network route list).

You can also configure FortiWeb to route traffic to a specific network interface/gateway combination based on a packet’s source and destination IP address, instead of the static route configuration. For more information, see Creating a policy route.

To add a static route via the web UI

1.  Go to System > Network > Static Route.

To access this part of the web UI, your administrator account’s access profile must have Read and Write permission to items in the Router Configuration category. For details, see Permissions.

2.  Click Create New.

3.  Configure these settings:

Making a default route for your FortiWeb 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 FortiWeb towards those IP addresses will, in effect, be null routed. While this can help to ensure that unintentional traffic cannot leave your FortiWeb 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 OK.

The FortiWeb appliance should now be reachable to connections with networks indicated by the mask.

5.  To verify connectivity, from a host on the route’s destination network, attempt to connect to the FortiWeb appliance’s web UI via HTTP and/or HTTPS. (At this point in the installation, you have not yet configured a policy, and therefore, if in reverse proxy mode, cannot test connectivity through the FortiWeb.)

By default, in reverse proxy mode, FortiWeb’s virtual servers will not forward non-HTTP/HTTPS traffic to your protected web servers. (Only traffic picked up and allowed by the HTTP reverse proxy will be forwarded.) You may be able to provide connectivity by either deploying in a one-arm topology where other protocols bypass FortiWeb, or by enabling FortiWeb to route other protocols. See also Topology for reverse proxy mode and the config router setting command in the FortiWeb CLI Reference.

If the connectivity test fails, you can use the CLI commands:

execute ping <destination_ip4>

to determine if a complete route exists from the FortiWeb to the host, and

execute traceroute <destination_ipv4>

to determine the point of connectivity failure.

Also enable PING on the FortiWeb’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 FortiWeb.

• If these tests fail, or if you do not want to enable PING, first examine the static route configuration on both the host and FortiWeb.
  
  To display the routing table, enter the CLI command:
  
  diagnose network 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 FortiWeb 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 30
  
  to verify that the daemons for the web UI and CLI, such as sshd, newcli, and httpsd are running and not overburdened. For details, see the FortiWeb CLI Reference.

To add a default route via the CLI

1.  Enter the following commands:

config router static

edit <route_index>

set gateway <gateway_ipv4>

set device <interface_name>

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
• <interface_name> is the name of the network interface through which packets will egress, such as port1

The FortiWeb appliance should now be reachable to connections with networks indicated by the mask.

2.  To verify connectivity, from a host on the network applicable to the route, attempt to connect to the FortiWeb appliance’s web UI via HTTP and/or HTTPS. (At this point in the installation, you have not yet configured a policy, and therefore, if in reverse proxy mode, cannot test connectivity through the FortiWeb.)

By default, in reverse proxy mode, FortiWeb’s virtual servers will not forward non-HTTP/HTTPS traffic to your protected web servers. (Only traffic picked up and allowed by the HTTP reverse proxy will be forwarded.) You may be able to provide connectivity by either deploying in a one-arm topology where other protocols bypass FortiWeb, or by enabling FortiWeb to route other protocols. See also Topology for reverse proxy mode and the config router setting command in the FortiWeb CLI Reference.

If the connectivity test fails, you can use the CLI commands:

execute ping

to determine if a complete route exists from the FortiWeb to the host, and

execute traceroute

to determine the point of connectivity failure. For details, see the FortiWeb CLI Reference. Also enable ping on the FortiWeb (see To configure a network interface’s IPv4 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 FortiWeb.

• If these tests fail, or if you do not want to enable PING, first examine the static route configuration on both the host and FortiWeb.
  
  To display all routes with their priorities, enter the CLI command:
  
  diagnose network 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 IPv4 address via the CLI). Also examine routers and firewalls between the host and the FortiWeb 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 30
  
  to verify that the daemons for the web UI and CLI, such as sshd, newcli, and httpsd are running and not overburdened. For details, see the FortiWeb CLI Reference.

See also

• Creating a policy route
• Routing based on HTTP content
• Configuring the network interfaces
• Configuring a bridge (V-zone)
• Configuring DNS settings
• IPv6 support

Creating a policy route

FortiWeb allows you to configure policy routes that redirect traffic away from a static route. This mechanism can be useful for the following tasks:

• Diverting traffic for intrusion protection scanning (IPS).
• Protecting web servers for different customers (for example, the clients of a Managed Security Service Provider).
• Resolving asymmetric routing issues. See Fixing asymmetric routing problems with policy-based routing.

Policy routes can direct traffic to a specific network interface and gateway based on the packet’s source and destination IP address. In addition, you can also specify the interface on which FortiWeb receives packets it applies this routing policy to.

In most cases, you use policy routes when FortiWeb is operating in reverse proxy mode. In this mode, FortiWeb opens its own HTTP connection to the back-end server (a server pool member) and does not transmit the client’s request to the pool member. Because the pool member’s reply contains no incoming interface information that FortiWeb can use to route the reply, you do not specify an incoming interface value to match. Instead, the policy route specifies a source address (for example, the virtual server’s IP address), outgoing interface, and gateway only. In other operating modes (true transparent inspection, transparent inspection, and offline protection), specifying an incoming interface in the policy route configures FortiWeb to act as a router.

To create a policy route

1.  Go to System > Network > Policy Route.

2.  Complete the following settings:

3.  Click OK.

Notice for using policy route in an one-arm topology

Since FortiWeb's policy route has higher priority than static route (any packet will be evaluated against policy routes first, then static routes), when a FortiWeb is deployed in a one-arm topology (see Planning the network topology) and any policy route is configured for the FortiWeb to access to other networks, you are strongly recommended to add particular policy routes with higher priority for the static routing within the connected network subnets.

Take the one-arm with reverse proxy mode as an example, a policy route might be set for updating the signature and virus databases through the Internet. In this example, packets that FortiWeb forwards for reverse proxy mode within subnet 192.0.2.0/24 might match the policy route first rather than the static route, and so that the packets might be directed to incorrect path (which result in a failed reverse proxy). Therefore, no matter what the configurations you have for the policy routes, we strongly suggest an extra policy route being set (for this example) like

Destination address/mask = 192.0.2.0/24

Outgoing Interface = port3

Priority = 10

Configuration of the particular policy route is a static route for choosing port 3 as the path to forward packets destined to subnet 192.0.2.0/24. To make sure all the packets are evaluated against the particular policy routes before other normal policy routes, those particular policy routes must be assigned a higher (or the highest) priority than other policy routes'. This particular policy route, with a higher (or the highest) priority and no gateway being specified, essentially reverses the fact that policy routes have higher priority than static routes.

See also

• Adding a gateway

Open topic with navigation