Policy with destination NAT

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.

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.

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.