Policy with Internet Service

Using Internet Service in policy

This recipe shows how to apply a predefined Internet Service entry into a policy.

The Internet Service Database is a comprehensive public IP address database that combines IP address range, IP owner, service port number, and IP security credibility. The data comes from the FortiGuard service system. Information is regularly added to this database, for example, geographic location, IP reputation, popularity & DNS, and so on. All this information helps users define Internet security more effectively.

From FortiOS version 5.6 on, the Internet Service is included in the firewall policy, It can be applied to a policy only as a Destination object. From version 6.0, Internet Services can be applied both as Source and Destination objects in policy. You can also apply Internet Services to shaping policy.

There are three types of Internet Services we can apply to firewall policy:

l Predefined Internet Services. l Custom Internet Services. l Extension Internet Services.

Sample configuration

To apply a predefined Internet Service entry into a policy using the GUI:

1. Go to Policy & Objects and create a new policy.
2. In the Source or Destination field, click +.
3. In the Select Entries pane, click Internet Service.
4. Locate and click Gmail.
5. Configure the other fields and then click OK.

To apply a predefined Internet Service entry into a policy using the CLI:

In the CLI, enable the internet-service first and then use its ID to apply the policy.

This example uses Google Gmail and its ID is 65646. Each Internet Service has a unique ID.

config firewall policy edit 9 set name “Internet Service in Policy” set srcintf “wan2” set dstintf “wan1” set srcaddr “all” set internet-service enable set internet-service-id 65646 set action accept set schedule “always” set utm-status enable set av-profile “g-default”

set ssl-ssh-profile “certificate-inspection”

set nat enable

next end

To diagnose an Internet Service entry using the CLI:

diag internet-service id-summary 65646

Version: 0000600096

Timestamp: 201902111802

Total number of IP ranges: 444727

Number of Groups: 7

Group(0), Singularity(20), Number of IP ranges(142740)

Group(1), Singularity(19), Number of IP ranges(1210)

Group(2), Singularity(16), Number of IP ranges(241)

Group(3), Singularity(15), Number of IP ranges(38723)

Group(4), Singularity(10), Number of IP ranges(142586)

Group(5), Singularity(8), Number of IP ranges(5336)

Group(6), Singularity(6), Number of IP ranges(113891)

Internet Service: 65646(Google.Gmail)

Number of IP range: 60

Number of IP numbers: 322845

Singularity: 15

Reputation: 5(Known and verified safe sites such as Gmail, Amazon, eBay, etc.)

Icon Id: 510

Second Level Domain: 53(gmail.com)

Direction: dst

Data source: isdb

Result

Because the IP and services related to Google Gmail on the Internet are included in this Internet Service (65646), all traffic to Google Gmail is forwarded by this policy.

Using custom Internet Service in policy

Even though there are about 1,395 predefined Internet Services entries and a total of 444,727 IP ranges, we sometimes still need to create our own Internet Service entries. FortiOS supports custom Internet Service in a firewall policy.

When creating a custom Internet Service, you must set following elements:

l IP or IP Ranges l Protocol number l Port or Port Ranges l Reputation

You must use CLI to create a custom Internet Service. Custom Internet Service CLI syntax

config firewall internet-service-custom edit <name> set comment <comment> set reputation {1|2|3|4|5} config entry edit <ID #> set protocol <number #> set dst <object_name> config port-range

edit <ID #>

set start-port <number #> set end-port <number #>

next

end

next end end

end

Sample configuration

To configure a custom Internet Service using the CLI:

config firewall internet-service-custom

edit “test-isdb-1” set comment “Test Custom Internet Service” set reputation 4 config entry

edit 1

set protocol 6

config port-range

edit 1

set start-port 80

set end-port 443

next

end set dst “10-1-100-0”

next edit 2

set protocol 6 config port-range

edit 1

set start-port 80

set end-port 80

next

end set dst “172-16-200-0”

next

end

next

end

To apply a custom Internet Service into policy using the CLI:

config firewall policy

edit 1

set name “Internet Service in Policy” set srcintf “wan2” set dstintf “wan1” set srcaddr “all” set internet-service enable set internet-service-id 65646 set internet-service-custom “test-isdb-1” set action accept

set schedule “always” set utm-status enable set av-profile “g-default”

set ssl-ssh-profile “certificate-inspection”

set nat enable

next

end

Result

In addition to the IP/IP-Ranges and services allowed by Google.Gmail, this policy also allows the traffic which access to 10.1.100.0/24 and TCP/80-443 and 172.16.200.0/24 and TCP/80.

Using extension Internet Service in policy

Extension Internet Service lets you add custom IP_Range(s)+Port_Range(s) to an existing prpedefined Internet Servic, or remove IP_Range(s)+Port_Range(s) from an existing predefined Internet Service entry.

Using an extension type Internet Service is actually editing a predefined type Internet Service entry and add IP_Range (s)+ Port_Range(s) to it.

When creating an extension Internet Service and adding custom IP_Range(s)+Port_Range(s), you must set following elements:

l IP or IP Ranges l Protocol number l Port or Port Ranges

You must use CLI to add custom IP(s)+Port(s) entries into a predefined Internet Service.

You must use GUI to remove entries from a predefined Internet Service. Custom extension Internet Service CLI syntax

config firewall internet-service-extension edit <ID #> set comment <comment> config entry edit <ID #> set protocol <number #> set dst <object_name> config port-range edit <ID #> set start-port <number #> set end-port <number #>

next

end

next

end

end end

Sample configuration

To configure an extension Internet Service using the CLI:

config firewall internet-service-extension edit 65646 set comment “Test Extension Internet Service 65646” config entry edit 1 set protocol 6 config port-range edit 1 set start-port 80 set end-port 443

next

end

set dst “172-16-200-0”

next edit 2 set protocol 17 config port-range edit 1 set start-port 53 set end-port 53

next

end

set dst “10-1-100-0”

next

end

next

end

To removing IP(s)+Port(s) entries from an existing Internet Service:

1. Go to Policy & Objects > Internet Service Database.
2. Search for Gmail.
3. Select Gmail and click Edit.
4. Locate the IP entry you want to remove and click Disable beside that entry.
5. Click Return.
6. When you complete the actions in the GUI, the CLI automatically generates the configuration from your GUI actions:

config firewall internet-service-extension edit 65646 set comment “Test Extension Internet Service 65646” config entry

edit 1 set protocol 6 config port-range

edit 1 set start-port 80 set end-port 443

next

end set dst “172-16-200-0”

next edit 2 set protocol 17 config port-range

edit 1 set start-port 53 set end-port 53

next

end set dst “10-1-100-0”

next

end config disable-entry edit 1 set protocol 6 config port-range

edit 1 set start-port 25 set end-port 25

next edit 2 set start-port 80 set end-port 80

next edit 3 set start-port 110 set end-port 110

next edit 4 set start-port 143 set end-port 143

next edit 5 set start-port 443 set end-port 443

next edit 6 set start-port 465 set end-port 465

next edit 7 set start-port 587 set end-port 587

next edit 8 set start-port 993 set end-port 993

next edit 9 set start-port 995 set end-port 995

next edit 10 set start-port 2525 set end-port 2525

next

end config ip-range edit 1 set start-ip 2.20.183.160 set end-ip 2.20.183.160

next

end

next

end

next

end

To apply an extension Internet Service into policy using the CLI:

config firewall policy edit 9 set name “Internet Service in Policy” set srcintf “wan2” set dstintf “wan1” set srcaddr “all” set internet-service enable set internet-service-id 65646 set action accept set schedule “always” set utm-status enable set av-profile “g-default”

set ssl-ssh-profile “certificate-inspection”

set nat enable

next

end

Result

In addition to the IP(s)/IP-Range(s) and services allowed by Google.Gmail, this policy also allows the traffic which accesses 10.1.100.0/24 and UDP/53 and 172.16.200.0/24 and TCP/80-443. At the same time, the traffic which accesses 2.20.183.160 is dropped because this IP+Port(s) is disabled from Google.Gmail.

Policy with destination NAT

Static virtual IPs

Usually we use VIP to implement Destination Address Translation. Mapping a specific IP address to another specific IP address is usually referred to as Destination NAT. When the Central NAT Table is not used, FortiOS calls this a Virtual IP Address (VIP). FortiOS uses a DNAT or Virtual IP address to map an external IP address to an IP address. This address does not have to be an individual host, it can also be an address range. This mapping can include all TCP/UDP ports or, if Port Forwarding is enabled, it only refers to the configured ports. Because, the Central NAT table is disabled by default, the term Virtual IP address or VIP is predominantly used.

Virtual IP addresses are typically used to NAT external or public IP addresses to internal or private IP addresses. Using a Virtual IP address between two internal interfaces made up of private IP addresses is possible but there is rarely a reason to do so as the two networks can just use the IP addresses of the networks without the need for any address translation. Using a Virtual IP address for traffic going from the inside to the Internet is even less likely to be a requirement, but it is supported.

Sample configuration

To create a virtual IP using the GUI:

1. In Policy & Objects > Virtual IPs.
2. Click Create New and select Virtual IP.
3. Select a VIP Type.

Select the VIP Type depending on the IP version network on the FortiGate’s external interface and internal interface. l If IPv4 is on both sides of the FortiGate unit, select IPv4. l If IPv6 is on both sides of the FortiGate unit, select IPv6. l If traffic goes from an IPv4 network to an IPv6 network, select NAT46. l If traffic goes from an IPv6 network to an IPv4 network, select NAT64.

4. Enter a unique name for the virtual IP and fill in the other fields.

To create a virtual IP using the CLI:

config firewall vip edit “Internal_WebServer” set extip 10.1.100.199 set extintf “any” set mappedip “172.16.200.55”

next

end

To apply a virtual IP to policy using the CLI:

config firewall policy edit 8 set name “Example_Virtual_IP_in_Policy”

set srcintf “wan2” set dstintf “wan1” set srcaddr “all”

set dstaddr “Internal_WebServer” set action accept set schedule “always” set service “ALL” set nat enable

next

end

Virtual IP with services

Virtual IP with services is a more flexible virtual IP mode. This mode allows users to define services to a single port number mapping.

This recipe shows how to use virtual IP with services enabled. This example has one public external IP address. We map TCP ports 8080, 8081, and 8082 to an internal WebServer TCP port 80. This allows remote connections to communicate with a server behind the firewall.

Sample configuration

To create a virtual IP with services using the GUI:

1. In Policy & Objects > Virtual IPs.
2. Click Create New and select Virtual IP.
3. For VIP Type, select IPv4.
4. Enter a unique name for the virtual IP and fill in the other fields.
5. Configure the fields in the Network For example: l Set Interface to any.
   • Set External IP Address/Range to 1.100.199.
   • Set Mapped IP Address/Range to 16.200.55.
6. Enable Optional Filters and then enable Services.
7. In the Services field, click + to display the Services pane.
8. In the Services pane, select TCP_8080, TCP_8081, and TCP_8082.
9. Enable Port Forwarding.
10. Set Map to Port to 80.
11. Click OK.

To see the results:

1. Apply the above virtual IP to the Firewall policy.
2. The results are:
   • Access 10.1.100.199:8080 from external network and FortiGate maps to 172.16.200.55:80 in internal network.
   • Access 10.1.100.199:8081 from external network and FortiGate maps to 172.16.200.55:80 in internal network.
   • Access 10.1.100.199:8082 from external network and FortiGate maps to 172.16.200.55:80 in internal network.

To create a virtual IP with services using the CLI:

config firewall vip edit “WebServer_VIP_Services” set service “TCP_8080” “TCP_8081” “TCP_8082” set extip 10.1.100.199 set extintf “any” set portforward enable set mappedip “172.16.200.55” set mappedport 80

next

end

Virtual IPs with port forwarding

If you need to hide the internal server port number or need to map several internal servers to the same public IP address, enable port-forwarding for Virtual IP.

This recipe shows how to use virtual IPs to configure port forwarding on a FortiGate unit. This example has one public external IP address. We map TCP ports 8080, 8081, and 8082 to different internal WebServers’ TCP port 80. This allows remote connections to communicate with a server behind the firewall.

Sample configuration

To create a virtual IP with port forwarding using the GUI:

1. In Policy & Objects > Virtual IPs.
2. Click Create New and select Virtual IP.
3. For VIP Type, select IPv4.
4. Enter a unique name for the virtual IP and fill in the other fields.
5. Configure the fields in the Network For example:
   • Set Interface to any.
   • Set External IP Address/Range to 1.100.199. l Set Mapped IP Address/Range to 172.16.200.55.
6. Leave Optional Filters
7. Enable Port Forwarding.
8. Configure the fields in the Port Forwarding For example:
   • Set Protocol to TCP. l Set External Service Port to 8080 -8080. l Set Map to Port to 80 -80.
9. Click OK.
10. Follow the above steps to create two additional virtual IPs.
11. For one virtual IP:
    • Use a different Mapped IP Address/Range, for example, 16.200.56. l Set External Service Port to 8081 -8081. l Use the same Map to Port numbers: 80 -80.

1. For the other virtual IP:

• Use a different Mapped IP Address/Range, for example, 16.200.57. l Set External Service Port to 8082 -8082. l Use the same Map to Port numbers: 80 -80.

11. Create a Virtual IP Group and put the above three virtual IPs into that group.

To see the results:

1. Apply the above virtual IP to the Firewall policy.
2. The results are:
   • Access 10.1.100.199:8080 from external network and FortiGate maps to 172.16.200.55:80 in internal network.
   • Access 10.1.100.199:8081 from external network and FortiGate maps to 172.16.200.56:80 in internal network.
   • Access 10.1.100.199:8082 from external network and FortiGate maps to 172.16.200.57:80 in internal network

Virtual server

This topic shows a special virtual IP type: virtual server, Use this type of VIP to implement server load balancing.

The FortiOS server load balancing contains all the features of a server load balancing solution. You can balance traffic across multiple backend servers based on multiple load balancing schedules including:

• Static (failover). l Round robin.
• Weighted (to account for different sized servers or based on the health and performance of the server including round trip time and number of connections).

The load balancer supports HTTP, HTTPS, IMAPS, POP3S, SMTPS, SSL/TLS, and generic TCP/UDP and IP protocols.

Session persistence is supported based on the SSL session ID based on an injected HTTP cookie, or based on the HTTP or HTTPS host. SSL/TLS load balancing includes protection from protocol downgrade attacks. Server load balancing is supported on most FortiGate devices and includes up to 10,000 virtual servers on high end systems.

Sample topology

SSL/TLS offloading

FortiGate SSL/TLS offloading is designed for the proliferation of SSL/TLS applications. The key exchange and encryption/decryption tasks are offloaded to the FortiGate unit where they are accelerated using FortiASIC technology which provides significantly more performance than a standard server or load balancer. This frees up valuable resources on the server farm to give better response to business operations. Server load balancing offloads most SSL/TLS versions including SSL 3.0, TLS 1.0, and TLS 1.2; and supports full mode or half mode SSL offloading with DH key sizes up to 4096 bits.

FortiGate SSL offloading allows the application payload to be inspected before it reaches your servers. This prevents intrusion attempts, blocks viruses, stops unwanted applications, and prevents data leakage. SSL/TLS content inspection supports TLS versions 1.0, 1.1, and 1.2 and SSL versions 1.0, 1.1, 1.2, and 3.0.

Virtual server requirements

When creating a new virtual server, you must configure the following options:

• Virtual Server Type. l Load Balancing Methods. l Health check monitoring (optional). l Session persistence (optional).
• Virtual Server IP (External IP Address).
• Virtual Server Port (External Port). l Real Servers (Mapped IP Address & Port).

Virtual server types

Select the protocol to be load balanced by the virtual server. If you select a general protocol such as IP, TCP, or UDP, the virtual server load balances all IP, TCP, or UDP sessions. If you select specific protocols such as HTTP, HTTPS, or SSL, you can apply additional server load balancing features such as Persistence and HTTP Multiplexing.

HTTP	Select HTTP to load balance only HTTP sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced (usually port 80 for HTTP sessions). You can also select HTTP Multiplexing. You can also set Persistence to HTTP Cookie to enable cookie-based persistence.
HTTPS	Select IMAPS to load balance only IMAPS sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced (usually port 993 for IMAPS sessions). You can also set Persistence to SSL Session ID.
IMAPS	Select IMAPS to load balance only IMAPS sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced (usually port 993 for IMAPS sessions). You can also set Persistence to SSL Session ID.
POP3S	Select POP3S to load balance only POP3S sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced (usually port 995 for POP3S sessions). You can also set Persistence to SSL Session ID.
SMTPS	Select SMTPS to load balance only SMTPS sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced (usually port 465 for SMTPS sessions). You can also set Persistence to SSL Session ID.
SSL	Select SSL to load balance only SSL sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced.
TCP	Select TCP to load balance only TCP sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced.
UDP		Select UDP to load balance only UDP sessions with the destination port number that matches the Virtual ServerPort setting. Change Virtual ServerPort to match the destination port of the sessions to be load balanced.
IP		Select IP to load balance all sessions accepted by the security policy that contains this virtual server.

Load balancing methods

The load balancing method defines how sessions are load balanced to real servers.

All load balancing methods do not send traffic to real servers that are down or not responding. FortiGate can only determine if a real server is not responding by using a health check monitor. You should always add at least one health check monitor to a virtual server or to real servers; otherwise load balancing might try to distribute sessions to real servers that are not functioning.

Static	The traffic load is statically spread evenly across all real servers. Sessions are not assigned according to how busy individual real servers are. This load balancing method provides some persistence because all sessions from the same source address always go to the same real server. Because the distribution is stateless, so if a real server is added, removed, or goes up or down, the distribution is changed and persistence might be lost.
Round Robin	Directs new requests to the next real server. This method treats all real servers as equals regardless of response time or the number of connections. This method does not direct requests to real servers that down or non responsive.
Weighted	Real servers with a higher weight value receive a larger percentage of connections. Set the real server weight when adding a real server.
Least Session	Directs requests to the real server that has the least number of current connections. This method works best in environments where the real servers or other equipment you are load balancing all have similar capabilities. This load balancing method uses the FortiGate session table to track the number of sessions being processed by each real server. The FortiGate unit cannot detect the number of sessions actually being processed by a real server.
Least RTT	Directs sessions to the real server with the lowest round trip time. The round trip time is determined by a ping health check monitor. The default is 0 if no ping health check monitors are added to the virtual server.
First Alive	Directs sessions to the first live real server. This load balancing schedule provides real server failover protection by sending all sessions to the first live real server. If a real server fails, all sessions are sent to the next live real server. Sessions are not distributed to all real servers so all sessions are processed by the first real server only.
HTTP Host	Load balances HTTP host connections across multiple real servers using the host’s HTTP header to guide the connection to the correct real server.

Health check monitoring

In the FortiGate GUI, you can configure health check monitoring so that the FortiGate unit can verify that real servers are able respond to network connection attempts. If a real server responds to connection attempts, the load balancer continues to send sessions to it. If a real server stops responding to connection attempts, the load balancer assumes that the server is down and does not send sessions to it. The health check monitor configuration determines how the load balancer tests real servers. You can use a single health check monitor for multiple load balancing configurations. You can configure TCP, HTTP, and Ping health check monitors. You usually set the health check monitor to use the same protocol as the traffic being load balanced to it. For example, for an HTTP load balancing configuration, you would normally use an HTTP health check monitor.

Session persistence

Use persistence to ensure a user is connected to the same real server every time the user makes an HTTP, HTTPS, or SSL request that is part of the same user session. For example, if you are load balancing HTTP and HTTPS sessions to a collection of eCommerce web servers, when users make a purchase, they will be starting multiple sessions as they navigate the eCommerce site. In most cases, all the sessions started by this user during one eCommerce session should be processed by the same real server. Typically, the HTTP protocol keeps track of these related sessions using cookies. HTTP cookie persistence ensure all sessions that are part of the same user session are processed by the same real server.

When you configure persistence, the FortiGate unit load balances a new session to a real server according to the load balance method. If the session has an HTTP cookie or an SSL session ID, the FortiGate unit sends all subsequent sessions with the same HTTP cookie or SSL session ID to the same real server.

Real servers

Add real servers to a load balancing virtual server to provide information the virtual server requires to send sessions to the server. A real server configuration includes the IP address of the real server and port number the real server receives sessions on. The FortiGate unit sends sessions to the real server’s IP address using the destination port number in the real server configuration.

When configuring a real server, you can also specify the weight (if the load balance method is set to Weighted) and you can limit the maximum number of open connections between the FortiGate unit and the real server. If the maximum number of connections is reached for the real server, the FortiGate unit automatically switches all further connection requests to other real servers until the connection number drops below the limit. Setting Maximum Connections to 0 means that the FortiGate unit does not limit the number of connections to the real server.

Sample of HTTP load balancing to three real web servers

This example describes the steps to configure the load balancing configuration below. In this configuration, a FortiGate unit is load balancing HTTP traffic from the Internet to three HTTP servers on the internal network. HTTP sessions are accepted at the wan1 interface with destination IP address 172.20.120.121 on TCP port 8080, and forwarded from the internal interface to the web servers. When forwarded, the destination address of the session is translated to the IP address of one of the web servers.

This load balancing configuration also includes session persistence using HTTP cookies, round-robin load balancing, and TCP health monitoring for the real servers. Ping health monitoring consists of the FortiGate unit using ICMP ping to ensure the web servers can respond to network traffic.

To configure load balancing using the GUI:

1. Go to Policy & Objects > Health Check.
2. Create a new Health Check Monitor and set the following fields as an example:
   • Set Name to Ping-mon-1.
   • Set Type to Ping. l Set Interval to 10 l Set Timeout to 2 seconds. l Set Retry to 3 attempt(s).
3. Go to Policy & Objects > Virtual Servers.
4. Create a new Virtual Server and set the following fields as an example:
   • Set Name to Vserver-HTTP-1. l In the Network section, set Type to HTTP.
   • Set Interface to wan1. l Set Virtual ServerIP to 20.120.121.
   • Set Virtual ServerPort to 8080.
   • Set Load Balance Method to Round Robin.
   • Set Persistence to HTTP Cookie. l Set Health Check to Ping-mon-1. l Do not enable HTTP Multiplexing.
   • Do not enable Preserve Client IP.
5. In the Real Servers section, add the three load balance real servers to the virtual server. For example:
   • Add the IP Address 31.101.30, 10.31.101.40, and 10.31.101.50.
   • For all IP addresses, set Port to 80. l For all IP addresses, set Max Connections to 0. l For all IP addresses, set Mode to Active.
6. Add a security policy that includes the load balance virtual server as the destination address.

To see the results:

• Traffic accessing 172.20.120.121:8080 is forwarded to the three real servers in turn.
• If the access request has an http-cookie, FortiGate forwards the access to the corresponding real server according to the cookie.

Policy with source NAT

Static SNAT

NAT or Network Address Translation is the process that enables a single device such as a router or firewall to act as an agent between the Internet or Public Network and a local or private network. This agent acts in real time to translate the source or destination IP address of a client or server on the network interface. For the source IP translation, this enables a single public address to represent a significantly larger number of private addresses. For the destination IP translation, the firewall can translate a public destination address to a private address. So we don’t have to configure a real public IP address for the server deployed in a private network.

We can subdivide NAT into two types: source NAT (SNAT) and destination NAT (DNAT). This topic is about SNAT, We support three NAT working modes: static SNAT, dynamic SNAT, and central SNAT.

In static SNAT all internal IP addresses are always mapped to the same public IP address. This is a port address translation, Since we have 60416 available port numbers, this one public IP address can handle the conversion of 60,416 internal IP addresses. See example below.

FortiGate firewall configurations commonly use the Outgoing Interface address.

Sample configuration

The following example of static SNAT uses an internal network with subnet 10.1.100.0/24 (vlan20) and an external/ISP network with subnet 172.16.200.0/24 (vlan30).

When the clients in internal network need to access the servers in external network, We need to translate IP addresses from 10.1.100.0/24 to an IP address 172.16.200.0/24, In this example, we implement static SNAT by creating a firewall policy.

To configure static NAT:

1. In Policy & Objects > IPv4 Policy, click Create New.
2. Enter the required policy parameters.
3. Enable NAT and select Use Outgoing Interface Address.
4. If needed, enable Preserve Source Port.

Enable Preserve Source Port to keep the same source port for services that expect traffic to come from a specific source port.

Disable Preserve Source Port to allow more than one connection through the firewall for that service.

For packets that match this policy, its source IP address is translated to the IP address of the outgoing interface.

Dynamic SNAT

Dynamic SNAT maps the private IP addresses to the first available public address from a pool of addresses. In the

FortiGate firewall, this can be done by using IP pools. IP pools is a mechanism that allows sessions leaving the FortiGate firewall to use NAT. An IP pool defines a single IP address or a range of IP addresses to be used as the source address for the duration of the session. These assigned addresses are used instead of the IP address assigned to that FortiGate interface.

IP pool types

FortiGate uses four types of IPv4 IP pools. This recipe focuses on some of the differences between them.

Overload

This type of IP pool is similar to static SNAT mode. We just need to define an external IP range, This range can contain one or multiple IP addresses, When there is only one IP address, it almost as same as static SNAT – use Outgoing Interface address. When it contains multiple IP addresses, It is equivalent to an extended mode of static SNAT.

For instance, if we define an overload type IP pool with two external IP addresses (172.16.200.1—172.16.200.2), since there are 60,416 available port numbers per IP, this IP pool can handle 60,416*2 internal IP addresses. See example below.

One-to-one

This type of IP pool means that the internal IP address and the external (translated) IP address match one-to-one. The port address translation (PAT) is disabled when using this type of IP pool. For example, if we define a one-to-one type IP pool with two external IP addresses (172.16.200.1-172.16.200.2), this IP pool only can handle two internal IP addresses.

Fixed port range

For the overload and one-to-one IP pool types, we do not need to define the internal IP range. For the fixed port range type of IP pool, we can define both internal IP range and external IP range. Since each external IP address and the number of available port numbers is a specific number, if the number of internal IP addresses is also determined, we can calculate the port range for each address translation combination. So we call this type fixed port range. This type of IP pool is a type of port address translation (PAT).

For instance, if we define one external IP address (172.16.200.1) and ten internal IP addresses (10.1.100.110.1.100.10), we have translation IP+Port combination like following table:

Port block allocation

This type of IP pool is also a type of port address translation (PAT). It gives users a more flexible way to control the way external IPs and ports are allocated. Users need to define Block Size/Block PerUser and external IP range. Block Size means how many ports each Block contains. Block perUser means how many blocks each user (internal IP) can use.

Following is a simple example:

External IP Range: 172.16.200.1—172.16.200.1

Block Size: 128 Block Per User: 8

Result:

Total-PBAs: 472 (60416/128)

Maximum ports can be used per User (Internal IP Address): 1024 (128*8)

How many Internal IP can be handled: 59 (60416/1024 or 472/8)

Sample configuration

To configure Overload IP pool using the GUI:

1. In Policy & Objects > IP Pools, click Create New.
2. Select IPv4 Pool and then select Overload.

To configure Overload IP pool using the CLI:

config firewall ippool

edit “Overload-ippool” set startip 172.16.200.1 set endip 172.16.200.1

next

end

To configure One-to-One IP pool using the GUI:

1. In Policy & Objects > IP Pools, click Create New.
2. Select IPv4 Pool and then select One-to-One.

To configure One-to-One IP pool using the CLI:

config firewall ippool

edit “One-to-One-ippool” set type one-to-one set startip 172.16.200.1 set endip 172.16.200.2

next

end

To configure Fixed Port Range IP pool using the GUI:

1. In Policy & Objects > IP Pools, click Create New.
2. Select IPv4 Pool and then select Fixed Port Range.

To configure Fixed Port Range IP pool using the CLI:

config firewall ippool edit “FPR-ippool”

set type fixed-port-range set startip 172.16.200.1 set endip 172.16.200.1 set source-startip 10.1.100.1 set source-endip 10.1.100.10

next

end

To configure Port Block Allocation IP pool using the GUI:

1. In Policy & Objects > IP Pools, click Create New.
2. Select IPv4 Pool and then select Port Block Allocation.

To configure Port Block Allocation IP pool using the CLI:

config firewall ippool edit PBA-ippool set type port-block-allocation set startip 172.16.200.1 set endip 172.16.200.1 set block-size 128 set num-blocks-per-user 8

next

end

Central SNAT

The central SNAT table enables you to define and control (with more granularity) the address translation performed by FortiGate. With the NAT table, you can define the rules for the source address or address group, and which IP pool the destination address uses.

While similar in functionality to IP pools where a single address is translated to an alternate address from a range of IP addresses, with IP pools there is no control over the translated port. When using the IP pool for source NAT, you can define a fixed port to ensure the source port number is unchanged. If no fixed port is defined, the port translation is randomly chosen by FortiGate. With the central NAT table, you have full control over both the IP address and port translation.

FortiGate reads the NAT rules from the top down until it hits a matching rule for the incoming address. This enables you to create multiple NAT policies that dictate which IP pool is used based on the source address. NAT policies can be rearranged within the policy list. NAT policies are applied to network traffic after a security policy.

The central SNAT table allows you to create, edit, delete, and clone central SNAT entries.

Central SNAT notes

• The central NAT feature in not enabled by default.
• If central NAT is enabled, the NAT option under IPv4 policies is skipped and SNAT must be done via centralsnat-map. The IPv4 policy list and dialog boxes have messages and redirection links to show this information. l If NGFW mode is policy-based, then it is assumed that central NAT (specifically SNAT) is enabled implicitly.
• The option to toggle NAT in central-snat-map policies has been added. Previously it was only shown in NGFW policy-based mode.
• In the central SNAT policy dialog box, the port mapping fields for the original port have been updated to accept ranges.
• If per VDOM NAT is enabled, NAT is skipped in firewall policy. l The central SNAT window contains a table of all the central SNAT policies.

Sample configuration

To enable or disable central SNAT using the CLI:

config system settings set central-nat [enable | disable]

end

When central NAT is enabled, Policy & Objects displays the Central SNAT section.

To create central SNAT using the GUI:

1. In Policy & Objects > Central SNAT.

The right pane displays a table of Central SNAT entries.

2. To create a new entry, click Create New in the right pane. To edit an entry, double-click the policy you want to edit.
3. To set the Incoming Interface, click + in that field.
4. In the pane on the right, select an interface to add it. You can select multiple interfaces.
5. To set the Outgoing Interface, click click + in that field.
6. In the pane on the right, select an interface to add it. You can select multiple interfaces.
7. To set the Source Address, click click + in that field.
8. In the pane on the right, select an address to add it. You can select multiple addresses.
9. To set the Destination Address, click click + in that field.
10. In the pane on the right, select an address to add it. You can select multiple addresses.
11. In NAT > IP Pool Configuration, select either Use Outgoing Interface Address or Use Dynamic IP Pool.

If you select Use Dynamic IP Pool, click + and select which IP pool to use.

12. Select one of the following Protocol
    • ANY. Use any protocol traffic. l TCP. Use TCP traffic only. Protocol number is set to 6. l UDP. Use UDP traffic only. Protocol number is set to 17. l SCTP. Use SCTP traffic only. Protocol number is set to 132.
    • Specify. You can specify the traffic filter protocol by setting the protocol number.
13. If you use the Overload type of IP pool, you can enable Explicit Port Mapping.
    1. If you enable Explicit Port Mapping, set the Original Source Port to the start number of the source port range.
    2. Set the Translated Port to the start number of the translated port range.
14. Click OK.

To configure central SNAT using the CLI:

config firewall central-snat-map

edit <policyID number>set status [enable|disable] set orig-addr <valid address object preconfigured on the FortiGate> set srcintf <name of interface on the FortiGate>

set dst-addr <valid address object preconfigured on the FortiGate> set dstintf <name of interface on the FortiGate> set protocol <integer for protocol number> set orig-port <integer for original port number> set nat-port <integer for translated port number> set comments <string>

end

To set NAT to be not available regardless of NGFW mode:

config firewall central-snat-map edit 1 set orig-addr “192-86-1-86” set srcintf “port23” set dst-addr “192-96-1-96” set dstintf “port22” set nat-ippool “pool1” set protocol 17 set orig-port 2896-2897 set nat enable

end

To hide NAT port if NAT IP pool is not set or if NAT is disabled:

config firewall central-snat-map edit 1 set orig-addr “192-86-1-86” set srcintf “port23” set dst-addr “192-96-1-96” set dstintf “port22” set nat-ippool “pool1” set protocol 17 set orig-port 2896-2897 set nat disable

end

To change original port to accept range:

config firewall central-snat-map edit 1

set orig-addr “192-86-1-86” set srcintf “port23” set dst-addr “192-96-1-96” set dstintf “port22” set nat-ippool “pool1” set protocol 17 set orig-port 2896-2897 (help text changed to: Original port or port range).

set nat-port 35804-35805

end

Policy views and policy lookup

This topic provides a sample of firewall policy views and firewall policy lookup.

Policy views

In Policy & Objects policy list page, there are two policy views: Interface PairView and By Sequence view.

Interface PairView displays the policies in the order that they are checked for matching traffic, grouped by the pairs of Incoming and Outgoing interfaces. For example, all policies referencing traffic from WAN1 to DMZ are in one section. The policies referencing traffic from DMZ to WAN1 are in another section. The sections are collapsible so that you only need to look at the sections you want.

By Sequence displays policies in the order that they are checked for matching traffic without any grouping.

The default display is Interface PairView. You can switch between the two views except if any or multiple-interfaces are applied in the policy.

How Any or multiple-interfaces policy can change the Interface Pair View

The FortiGate unit automatically changes the view on the policy list page to By Sequence whenever there is a policy containing any or multiple-interfaces as the Source or Destination interface. If the Interface PairView is grayed out, it is likely that one or more policies have used the any or multiple-interfaces.

When you use the any or multiple-interfaces, the policy goes into multiple sections because it might be any one of a number of interface pairings. Policies are divided into sectioned using the interface pairings, for example, port1 to port2.

Each section has its own policy order. The order in which a policy is checked for matching criteria to a packet’s information is based solely on the position of the policy within its section or within the entire list of policies. If the policy is in multiple sections, FortiGate cannot place the policy in order in multiple sections. Therefore the view can only be By Sequence.

Policy lookup

Firewall policy lookup is based on the Source_interfaces/Protocol/Source_Address/Destination_

Address that matches the source-port and dst-port of the protocol. Use this tool to find out which policy matches specific traffic from a number of policies. After completing the lookup, the matching firewall policy is highlighted on the policy list page.

The Policy Lookup tool has the following requirements:

• Transparent mode does not support Policy lookup function.
• When executing the policy lookup, you need to confirm whether the relevant route required for the policy work already exists.

Sample configuration

This example uses the TCP protocol to show how policy lookup works:

1. In Policy & Objects policy list page, click Policy Lookup and enter the traffic parameters.
2. Click Search to display the policy lookup results.

Other NGFW policy-based mode options

You can combine both application control and web filtering in the same NGFW policy mode policy. If the policy accepts applications or URL categories, you can apply Antivirus, DNS Filtering, and IPS profiles in NGFW mode policies as well as logging and policy learning mode.

Application control in NGFW policy-based mode

Configure Application Control by adding individual applications to security policies. You can set the action to ACCEPT or DENY to allow or block applications.

In the above example, if you browse to www.facebook.com, your connection will time out.

NGFW policy mode and NAT

If your FortiGate is operating in NAT mode, rather than enabling source NAT in individual NGFW policies, go to Policy & Objects > Central SNAT and add source NAT policies that apply to all matching traffic. In many cases, you may only need one SNAT policy for each interface pair. For example, if you allow users on the internal network (connected to LAN) to browse the Internet (connected to wan1), you can add a LAN to wan1 Central SNAT policy similar to the following.

Profile-based NGFW vs policy-based NGFW

From version 5.6, we added a new policy mode called Next Generation Firewall (NGFW). This mode is only available when the VDOM inspection-mode is flow. This model is divided into two working modes — profile-based and policybased. Profile-based NGFW is the traditional mode where a user needs to create an AV/web/IPS profile which is applied to the policy.

Policy-based mode is new. In this mode, users can add applications and web filtering categories directly to a policy without having to first create and configure Application Control or Web Filtering profiles. If a URL category is set, the applications that are added to the policy must be within the browser-based technology category. NGFW is per VDOM setting. This means users can operate their FortiGate or individual VDOMs on their FortiGate in NGFW policy-based mode when they select flow-based inspection.

Switching NGFW mode from profile-based to policy-based converts your profile-based security policies to policy-based security policies. If you don’t want this to happen or you just want to experiment with policy-based NGFW mode, consider creating a new VDOM for policy-based NGFW mode. You can also backup your configuration before switching modes.

NGFW policy-based firewall policies might have unintended consequences to the passing or blocking of traffic. For example, if you add new firewall policies that are designed to DENY social media traffic based on applications or URLs, having a traditional “catch all” firewall policy to DENY all other traffic at the bottom of the firewall policy list may have the unintended consequence of blocking legitimate traffic. Also note that NGFW policy-based mode applies the NAT settings from matching Central SNAT policies. If you don’t already have a Central SNAT policy in place, you must create one.

After version 6.2, we removed the inspection-mode from VDOM to firewall policy, and the default inspection-mode is flow so we can change NGFW mode from profile-based (default) to policy-based directly in the VDOM’s System > Settings.

To enable policy-based NGFW mode using the GUI:

You can operate your FortiGate or individual VDOMs in Next Generation Firewall (NGFW) policy mode.

1. Go to System > Settings.
2. In NGFW Mode, select Policy-based.
3. In SSL/SSH Inspection, select the SSL/SSH inspection mode to be applied to all policies.

To enable policy-based NGFW mode using the CLI:

config system settings set ngfw-mode {profile-based | policy-based} end