Networking – Best Practice – FortiOS 5.4.x

Networking

When configuring your network, ensure that there is no ‘back door’ access to the protected network. For example, if there is a wireless access point, it must be appropriately protected with password and encryption.

Be sure to also maintain an up-to-date network diagram which includes IP addressing, cabling, and network elements.

 

Routing configuration

  • Always configure a default route.
  • Add blackhole routes for subnets reachable using VPN tunnels. This ensures that if a VPN tunnel goes down, traffic is not mistakingly routed to the Internet unencrypted.

 

Policy routing

Keep the number of policy routes to a minimum to optimize performance in route lookup and to simplify troubleshooting.

 

Dynamic routing

  • Select a Router ID that matches an IP assigned to an interface. This avoids the likelihood of having two devices with the same router ID.
  • For routing over an IPsec tunnel, assign IP addresses to both ends of the tunnel.

 

Advanced routing

Use the following best practices for advanced routing when dealing with Border Gateway Protocol (BGP) and Open Shortest Path First (OSPF).

 

Border Gateway Protocol (BGP)

If you are using BGP, it is recommended that you enable soft-reconfiguration. This has two benefits:

  • It allows you to perform ‘soft clear’ of peers after a change is made to a BGP policy.
  • It provides greater visibility into the specific prefixes learned from each neighbor.

Leave soft-reconfiguration disabled if your FortiGate does not have much unused memory. Soft-reconfiguration requires keeping separate copies of prefixes received and advertised, in addition to the local BGP database.

 

Open Shortest Path First (OSPF)

  • Avoid use of passive interfaces wherever possible.
  • Avoid use of virtual links to connect areas. All areas should be designed to connect directly to the backbone area.
  • Ensure that all backbone routers have a minimum of two peering connections to other backbone neighbors.
  • An entire OSPF domain should be under common administration.

 

Network Address Translation (NAT)

  • Beware of misconfiguring the IP Pool range. Double-check the start and end IPs of each IP pool. The IP pool should not overlap with addresses assigned to FortiGate interfaces or to any hosts on directly connected networks.
  • If you have internal and external users accessing the same servers, use split DNS to offer an internal IP to internal users so that they don’t have to use the external-facing VIP.

 

Configuring NAT

Do not enable NAT for inbound traffic unless it is required by an application. If, for example, NAT is enabled for inbound SMTP traffic, the SMTP server might act as an open relay.

 

Transparent Mode

  • Do not connect two ports to the same VLAN on a switch or to the same hub. Some Layer 2 switches become unstable when they detect the same MAC address originating on more than one switch interface or from more than one VLAN.
  • If you operate multiple VLANs on your FortiGate unit, assign each VLAN id to its own forwarding domain to ensure that the scope of the broadcast does not extend beyond the VLAN it originated in.

 

To protect against Layer 2 loops:

  • Enable stpforward on all interfaces.
  • Use separate VDOMs for production traffic (TP mode VDOM) and management traffic (NAT/Route mode VDOM).
  • Only place those interfaces used for production in the TP mode VDOM. Place all other interfaces in the NAT/Route mode VDOM. This protects against potential Layer 2 loops.

Using Virtual IPs (VIPs)

  • Use the external IP of 0.0.0.0 when creating a VIP for a FortiGate unit where the external interface IP address is dynamically assigned.
  • Be sure to select the correct external interface when creating a new virtual IP (VIP). The external interface should be set to the interface at which the FortiGate unit receives connection requests from external networks.

 

2 thoughts on “Networking – Best Practice – FortiOS 5.4.x

  1. Zack

    What is the best practice for enabling UTM features on External to Internal/DMZ firewall policies?

    Does it make sense to enable all UTM features, or are some of them working only one way (for the external clients) for example Web Filtering or Antivirus?

    Reply
    1. Mike Post author

      I tend to do a policy per service/application.

      So, if SFTP is allowed to come in, I service and application control it to where that is all that can come through.
      If it is a web server I do a policy for http and a separate one for https. Doing Deep packet inspection on the https one and then slamming whatever I needed on the other.

      That’s my line of thinking and the best way to approach it. Mainly you don’t want the Gate to have to lift harder than necessary. Situations are rare where you need a ton of sensors on one policy (unless you just don’t break the policy out)

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.