Category Archives: FortiGate

Example topologies relevant to WAN optimization

FortiGate WAN optimization consists of a number of techniques that you can apply to improve the efficiency of communication across your WAN. These techniques include protocol optimization, byte caching, web caching, SSL offloading, and secure tunneling. Protocol optimization can improve the efficiency of traffic that uses the

CIFS, FTP, HTTP, or MAPI protocol, as well as general TCP traffic. Byte caching caches files and other data on

FortiGate units to reduce the amount of data transmitted across the WAN. Web caching stores web pages on FortiGate units to reduce latency and delays between the WAN and web servers. SSL offloading offloads SSL decryption and encryption from web servers onto FortiGate SSL acceleration hardware. Secure tunneling secures traffic as it crosses the WAN.

You can apply different combinations of these WAN optimization techniques to a single traffic stream depending on the traffic type. For example, you can apply byte caching and secure tunneling to any TCP traffic. For HTTP and HTTPS traffic, you can also apply protocol optimization and web caching.

You can configure a FortiGate unit to be an explicit web proxy server for both IPv4 and IPv6 traffic and an explicit FTP proxy server. Users on your internal network can browse the Internet through the explicit web proxy server or connect to FTP servers through the explicit FTP proxy server. You can also configure these proxies to protect access to web or FTP servers behind the FortiGate unit using a reverse proxy configuration.

Web caching can be applied to any HTTP or HTTPS traffic, this includes normal traffic accepted by a security policy, explicit web proxy traffic, and WAN optimization traffic.

You can also configure a FortiGate unit to operate as a Web Cache Communication Protocol (WCCP) client or server. WCCP provides the ability to offload web caching to one or more redundant web caching servers.

FortiGate units can also apply security profiles to traffic as part of a WAN optimization, explicit web proxy, explicit FTP proxy, web cache and WCCP configuration. Security policies that include any of these options can also include settings to apply all forms of security profiles supported by your FortiGate unit.

Basic WAN optimization topology

The basic FortiGate WAN optimization topology consists of two FortiGate units operating as WAN optimization peers intercepting and optimizing traffic crossing the WAN between the private networks.

Security device and WAN optimization topology

Out-of-path WAN optimization topology

FortiGate units can be deployed as security devices that protect private networks connected to the WAN and also perform WAN optimization. In this configuration, the FortiGate units are configured as typical security devices for the private networks and are also configured for WAN optimization. The WAN optimization configuration intercepts traffic to be optimized as it passes through the FortiGate unit and uses a WAN optimization tunnel with another FortiGate unit to optimize the traffic that crosses the WAN.

You can also deploy WAN optimization on single-purpose FortiGate units that only perform WAN optimization. In the out of path WAN optimization topology shown below, FortiGate units are located on the WAN outside of the private networks. You can also install the WAN optimization FortiGate units behind the security devices on the private networks.

The WAN optimization configuration is the same for FortiGate units deployed as security devices and for singlepurpose WAN optimization FortiGate units. The only differences would result from the different network topologies.

Out-of-path WAN optimization topology

In an out-of-path topology, one or both of the FortiGate units configured for WAN optimization are not directly in the main data path. Instead, the out-of-path FortiGate unit is connected to a device on the data path, and the device is configured to redirect sessions to be optimized to the out-of-path FortiGate unit.

Single-purpose WAN optimization topology

The following out-of-path FortiGate units are configured for WAN optimization and connected directly to FortiGate units in the data path. The FortiGate units in the data path use a method such as policy routing to redirect traffic to be optimized to the out-of-path FortiGate units. The out-of-path FortiGate units establish a WAN optimization tunnel between each other and optimize the redirected traffic.

Out-of-path WAN optimization

One of the benefits of out-of-path WAN optimization is that out-of-path FortiGate units only perform WAN optimization and do not have to process other traffic. An in-path FortiGate unit configured for WAN optimization also has to process other non-optimized traffic on the data path.

The out-of-path FortiGate units can operate in NAT/Route or transparent mode.

Other out-of-path topologies are also possible. For example, you can install the out-of-path FortiGate units on the private networks instead of on the WAN. Also, the out-of-path FortiGate units can have one connection to the network instead of two. In a one-arm configuration such as this, security policies and routing have to be configured to send the WAN optimization tunnel out the same interface as the one that received the traffic.

Topology for multiple networks

As shown in below, you can create multiple WAN optimization configurations between many private networks. Whenever WAN optimization occurs, it is always between two FortiGate units, but you can configure any FortiGate unit to perform WAN optimization with any of the other FortiGate units that are part of your WAN.

WAN optimization among multiple networks

You can also configure WAN optimization between FortiGate units with different roles on the WAN. FortiGate units configured as security devices and for WAN optimization can perform WAN optimization as if they are single-purpose FortiGate units just configured for WAN optimization.

WAN optimization with web caching

You can add web caching to a WAN optimization topology when users on a private network communicate with web servers located across the WAN on another private network.

WAN optimization with web caching topology

The topology above is the same as that shown in WAN optimization with web caching on page 269 with the addition of web caching to the FortiGate unit in front of the private network that includes the web servers. You can also add web caching to the FortiGate unit that is protecting the private network. In a similar way, you can add web caching to any WAN Optimization topology.

Explicit web proxy topologies

You can configure a FortiGate unit to be an explicit web proxy server for Internet web browsing of IPv4 and IPv6 web traffic. To use the explicit web proxy, users must add the IP address of the FortiGate interface configured for the explicit web proxy to their web browser proxy configuration.

Explicit web proxy topology

If the FortiGate unit supports web caching, you can also add web caching to the security policy that accepts explicit web proxy sessions The FortiGate unit then caches Internet web pages on a hard disk to improve web browsing performance.

Explicit web proxy with web caching topology

Explicit FTP proxy topologies

You can configure a FortiGate unit to be an explicit FTP proxy server for FTP users. To use the explicit web proxy, FTP users must connect to and authenticate with the explicit FTP proxy before connecting to an FTP server.

Explicit FTP proxy topology

You can also configure reverse explicit FTP proxy. In this configuration, users on the Internet connect to the explicit web proxy before connecting to an FTP server installed behind a FortiGate unit.

Reverse explicit FTP proxy topology

Web caching topologies

FortiGate web caching can be added to any security policy and any HTTP or HTTPS traffic accepted by that security policy can be cached on the FortiGate unit hard disk. This includes WAN optimization and explicit web proxy traffic. The network topologies for these scenarios are very similar. They involved a FortiGate unit installed between users and web servers with web caching enabled.

A typical web-caching topology includes one FortiGate unit that acts as a web cache server. Web caching is enabled in a security policy and the FortiGate unit intercepts web page requests accepted by the security policy, requests web pages from the web servers, caches the web page contents, and returns the web page contents to the users. When the FortiGate unit intercepts subsequent requests for cached web pages, the FortiGate unit contacts the destination web server just to check for changes.

WCCP topologies

Web caching topology

You can also configure reverse proxy web-caching. In this configuration, users on the Internet browse to a web server installed behind a FortiGate unit. The FortiGate unit intercepts the web traffic (HTTP and HTTPS) and caches pages from the web server. Reverse proxy web caching on the FortiGate unit reduces the number of requests that the web server must handle, leaving it free to process new requests that it has not serviced before. Reverse proxy web caching topology

WCCP topologies

You can operate a FortiGate unit as a Web Cache Communication Protocol (WCCP) router or cache engine. As a router, the FortiGate unit intercepts web browsing requests from client web browsers and forwards them to a WCCP cache engine. The cache engine returns the required cached content to the client web browser. If the cache server does not have the required content it accesses the content, caches it and returns the content to the client web browser.

WCCP topology

FortiGate units can also operate as WCCP cache servers, communicating with WCCP routers, caching web content and providing it to client web browsers as required.

WCCP is transparent to client web browsers. The web browsers do not have to be configured to use a web proxy.

Having trouble configuring your Fortinet hardware or have some questions you need answered? Check Out The Fortinet Guru Youtube Channel! Want someone else to deal with it for you? Get some consulting from Fortinet GURU!

Firewall schedules

Leave a reply

Firewall schedules

Firewall schedules control when policies are in effect. When you add a security policy on a FortiGate unit you need to set a schedule to determine the time frame in which that the policy will be functioning. While it is not set by default, the normal schedule would be always. This would mean that the policy that has been created is always function and always policing the traffic going through the FortiGate. The time component of the schedule is based on a 24 hour clock notation or military time as some people would say.

There are two types of schedules: One-time schedules and recurring schedules.

One-time schedule object

One-Time schedules are in effect only once for the period of time specified in the schedule. This can be useful for testing to limit how long a policy will be in effect in case it is not removed, or it can be used for isolated events such as a conference where you will only need a temporary infrastructure change for a few days.

The time frame for a One-time schedule is configured by using a start time which includes, Year | Month | Day | Hour | Minute and a Stop time which includes the same variables. So while the frequency of the schedule is only once it can last anywhere from 1 minute to multiple years. Configuring a one-time schedule object in the GUI

Go to Policy & Objects > Schedules.
Select Create New. A drop down menu is displayed. Select Schedule.
From the Type options, choose One-time.
Input a Name for the schedule object.
If you which to add a Color to the icon in the GUI, you can click on the Change link to choose 1 of 32 color options.
Choose a Start Date.

Selecting the field with the mouse will bring up a interactive calendar graphic that will allow the user to select the date. The date can also be typed in using the format YYYY/MM/DD.

Choose a Start Time.

The Start Time is composed of two fields, Hour and Minute. Think of setting the time for a digital clock in 24 hour mode. The Hour value can be an integer from 0 and 23. The Minute value can be from 0 to 59. 0 and 0 would be midnight at the start of the day and 23 and 59 would be one minute to midnight at the end of the day. The value can be entered by keyboard or by using the up and down arrows in the field to select the value.

Choose an End Date.

Configuration is the same as Start Date.

Choose a Stop Time.

Configuration is the same as Start Time.

Enable/Disable Pre-expiration event log.

This configures the system to create an event log 1 to 100 days before the End Date as a warning in case the schedule needs to be extended.

If the Pre-expiration event log is enabled, set the value for Number of days before.
Press OK.

Example: Firewall schedule – one-time

The company wants to change over their web site image to reference the new year. They have decided to take this opportunity to do some hardware upgrades as well. Their web site is business oriented so they have determined that over New Year’s Eve there will be very limited traffic.

l They are going to need a maintenance window of 2 hours bracketing midnight on New Year’s Eve.

Configuration in the GUI

Go to Policy & Objects > Objects > Schedule.
Select Create New > Schedule.
Fill out the fields with the following information:

Type	One-time
Name	NewYearsEve_Maintenance
Start Date	2014/12/31 <use the built in calendar>
End Date	2015/01/01 <use the built in calendar>
Start Time	Hour: 23, Minute: 0
Stop Time	Hour: 1Minute: 0
Pre-expiration event log	<disable>

Select OK.

To verify that the schedule was added correctly:

Go to Policy & Objects > Objects > Schedule.
Check that the schedule with the name you used has been added to the list of recurring schedules and that the listed settings are correct.

Configuration in the CLI

Enter the following CLI command:

config firewall schedule onetime edit maintenance_window set start 23:00 2012/12/31 set end 01:00 2013/01/01 next

end

To verify that the schedule was added correctly:

Enter the following CLI command:

config firewall schedule onetime edit <the name of the schedule you wish to verify> show full-configuration

Recurring schedule object

Recurring schedules are in effect repeatedly at specified times of specified days of the week. The Recurring schedule is based on a repeating cycle of the days of the week as opposed to every x days or days of the month. This means that you can configure the schedule to be in effect on Tuesday, Thursday, and Saturday but not every 2 days or on odd numbered days of the month.

If a recurring schedule has a stop time that is earlier than the start time, the schedule will take effect at the start time but end at the stop time on the next day. You can use this technique to create recurring schedules that run from one day to the next.

Configuring a recurring schedule object in the GUI

Go to Policy & Objects > Schedules.
Select Create New. A drop down menu is displayed. Select Schedule.
From the Type options, choose Recurring.
Input a Name for the schedule object.
If you which to add a Color to the icon in the GUI, you can click on the Change link to choose 1 of 32 color options.
From the Days options, choose the day of the week that you would like this schedule to apply to. The schedule will be in effect on the days of the week that have a check mark in the checkbox to the left of the name of the weekday.
If the scheduled time is the whole day, leave the All Day toggle switch enabled. If the schedule is for specific times during the day, disable the All Day toggle switch.
If the All Day option is disabled, choose a Start Time.

Choose a Stop Time.

Configuration is the same as Start Time.

Press OK.

Because recurring schedules do not work with DENY policies, the strategy when designing a schedule should not be to determine when users cannot access a policy but to build the schedules around when it is possible to access the policy.

Example: Firewall schedule – recurring

The Company wants to allow the use of Facebook by employees, but only during none business hours and the lunch break.

The business hours are 9:00 p.m. to 6:00 p.m. l The Lunch break is 12:00 p.m. to 1:00 p.m.
The plan is to create a schedule to cover the morning business hours and the afternoon business hours and block access to the Facebook web site during that time.

Configuration in the GUI

Go to Policy & Objects > Objects > Schedule.
Select Create New > Schedule.
Fill out the fields with the following information:

Type	Recurring
Name	Morning_Business_Hours
Days	Monday, Tuesday, Wednesday, Thursday, Friday
Start Time	Hour = 9, Minute = 0
Stop Time	Hour = 12, Minute = 0

Select OK.
Create a second new schedule.

Type	Recurring
Name	Morning_Business_Hours
Days	Monday, Tuesday, Wednesday, Thursday, Friday
Start Time	Hour = 13, Minute = 0
Stop Time	Hour = 18, Minute = 0

Select OK.

To verify that the schedule was added correctly:

Go to Policy & Objects > Objects > Schedule.
Check that the schedule with the name you used has been added to the list of recurring schedules and that the listed settings are correct.

Configuration in the CLI

Enter the following CLI command:

config firewall schedule recurring edit Morning_Business_Hours

set day monday tuesday wednesday thursday friday set start 09:00 set end 12:00

end

Enter the following CLI command:

config firewall schedule recurring edit Afternoon_Business_Hours set day monday tuesday wednesday thursday friday set start 13:00 set end 18:00

end

To verify that the schedule was added correctly:

Enter the following CLI command:

config firewall schedule recurring edit <the name of the schedule you wish to verify> show full-configuration

Schedule groups

You can organize multiple firewall schedules into a schedule group to simplify your security policy list. The schedule parameter in the policy configuration does not allow for the entering of multiple schedules into a single policy so if you have a combination of time frames that you want to schedule the policy for then the best approach, rather than making multiple policies is to use a schedule group.

Creating a schedule group object

Go to Policy & Objects > Schedules.
Select Create New. A drop down menu is displayed. Select Schedule Group
Input a Name for the schedule object.
In the Members field, select the “+” to bring forth the panel for selecting entries.
Press OK.

Example

Your Internet policy allows employees to visit Social Media sites from company computers but not during what is considered working hours. The offices are open a few hours before working hours and the doors are not locked until a few hours after official closing so work hours are from 9 to 5 with a lunch break from Noon to 1:00 p.m.

Your approach is to block the traffic between 9 and noon and between 1:00 p.m. and 5:00 p.m. This means you will need two schedules for a single policy and the schedule group handles this for you. Schedule groups can contain both recurring and one-time schedules. Schedule groups cannot contain other schedule groups.

Schedule expiration

The schedule in a security policy enables certain aspects of network traffic to occur for a specific length of time. What it does not do however, is police that time. That is, the policy is active for a given time frame, and as long as the session is open, traffic can continue to flow.

For example, in an office environment, Skype use is allowed between noon and 1pm. During that hour, any Skype traffic continues. As long as that session is open, after the 1pm end time, the Skype conversations can continue, yet new sessions will be blocked. Ideally, the Skype session should close at 1pm.

Using a CLI command you can set the schedule to terminate all sessions when the end time of the schedule is reached. Within the config firewall command enter the command: set schedule-timeout enable

By default, this option is set to disable.

A few further settings are needed to make this work.

config firewall policy edit ID set firewall-session-dirty check-new end

config system settings set firewall-session-dirty check-policy-option end

Firewall-session-dirty setting

The firewall-session-dirty setting has three options

check-all	CPU flushes all current sessions and re-evaluates them. [default]
check-new	CPU keeps existing sessions and applies policy changes to new sessions only. This reduces CPU load and the possibility of packet loss.
check-policy-option	Use the option selected in the firewall-session-dirty field of the firewall policy (check-all or check-new, as above, but per policy).

Dynamic VIP according to DNS translation

Leave a reply

Dynamic VIP according to DNS translation

When a dynamic virtual IP is used in a policy, the dynamic DNS translation table is installed along with the dynamic NAT translation table into the kernel. All matched DNS responses will be translated and recorded regardless if they hit the policy. When a client request hits the policy, dynamic NAT translation will occur if it matches a record, otherwise the traffic will be blocked.

Syntax

config firewall vip edit “1” set type dns-translation set extip 192.168.0.1-192.168.0.100

set extintf “dmz” set dns-mapping-ttl 604800 set mappedip “3.3.3.0/24” “4.0.0.0/24” end end

FQDN in VIPs

2 Replies

FQDN in VIPs

Instead of mapping to an IP address a VIP can use a FQDN(Fully Qualified Domain Name). This has to be configured in the CLI and the FQDN must be an address object that is already configured in the address listing.

The syntax for using a FQDN is:

config firewall vip edit <VIP id> set type fqdn

set mappped-addr <FQDN address object> end

Creating a virtual IP

1 Reply

Creating a virtual IP

Go to Policy & Objects > Virtual IPs.
Select Create New. A drop down menu is displayed. Select Virtual IP.
From the VIP Type options, choose an applicable type based on the IP addressing involved. Which is chosen will depend on which of the IP version networks is on the external interface of the FortiGate unit and which is on the internal interface.

The available options are:

IPv4 – IPv4 on both sides of the FortiGate Unit. l IPv6 – IPv6 on both sides of the FortiGate Unit. l NAT46 – Going from an IPv4 Network to an IPv6 Network.
NAT64 – Going from an IPv6 Network to an IPv4 Network.

In the Name field, input a unique identifier for the Virtual IP.
Input any additional information in the Comments
The Color of the icons that represent the object in the GUI can be changed by clicking on the [Change] link and choosing from the 32 colors.

Because the configuration differs slightly for each type the next steps will be under a separate heading based on the type of the VIP

Configuring a VIP for IPv4

In the Network section:

If an IPv4 type of Virtual IP, select the Interface

Using the drop down menu for the Interface Field, choose the incoming interface for the traffic.

The IPv4 VIP Type is the only one that uses this field. This is a legacy function from previous versions so that they can be upgraded without complicated reconfiguration. The External IP address, which is a required field, tells the unit which interface to use so it is perfectly acceptable to choose “any” as the interface. In some configurations, if the Interface field is not set to “any” the Virtual IP object will not one of the displayed options when choosing a destination address.

Configure the External IP Address/Range.

There are two fields. If there is a single IP address, use that address in both fields. This will be the address on the outside of the network that is usually the public address of the server. The format of the address will depend on the VIP Type option that was selected.

Configure the Mapped IP Address/Range. This will be the address that the traffic is being directed to.

There are two fields. If there is a single IP address, use that address in both fields. The format of the address will depend on the VIP Type option that was selected. In the Optional Filters

Disable/Enable the Optional Filters.

If only specific IP addresses and/or services are allowed to be the source for traffic using the VIP, enable the Optional Filters.

To specify an allowed address enter the value in the field labeled Source Address. The value can be formatted in three different ways.

l Source IP – Use the standard format for a single IP address l Range – Enter the first and last members of the range l Subnet – Enter the IP address of the broadcast address for the subnet.

To add additional addresses, click on the “+” below the last field with an address. To subtract an address, click on the “X” next to the field you wish to delete.

To specify an allowed Service, toggle the Services option to enabled. Set the Services parameter by selecting the field with the “+” in the field. This will slide a window out from the right. Single or multiple options can be selected by highlighting the services wanted, unless the ALL option is chosen, in which case it will be the only option. For more information on services, check the Firewall Objects section called Services and TCP ports.
Disable/Enable Port Forwarding. If only the traffic for a specific port or port range is being forwarded, enable this setting.
Select the Protocol from l TCP l UDP l SCTP l ICMP
Configure the External Service Port. This is the port(s) on the external interface of the FortiGate (the destination port in the header of the packets). The first field is for the first port in the range the second is for the last port in the range. As you enter a value in the first field, the second field will auto populate with the same number, working on the premise that a single port is common. Just edit the second field to extend the range.
Configure the setting Map to Port.This will be the listening port on the device located on the internal side of the network. It does not have to be the same as the External Service Port. The first field is for the first port in the range the second is for the last port in the range. As you enter a value in the first field, the second field will auto populate with the same number, working on the premise that a single port is common. Just edit the second field to extend the range.
Press

Example

This example is for a VIP that is being used to direct traffic from the external IP address to a web server on the internal network. The web server is for company use only. The company’s public facing web server already used port 80 and there is only one IP external IP address so the traffic for this server is being listened for on port 8080 of the external interface and being sent to port 80 on the internal host.

Field	Value
VIP Type	IPv4
Name	Internal_Webserver
Comments	Web server with Collaboration tools for Corporate employees
Interface	Any
External IP Address/Range	172.13.100.27 <this would normally be a public IP address>
Mapped IP Address/Range	192.168.34.150
Optional Filters	enabled
Source Address Filter	<list of IP addresses of remote users>
Services	enabled with HTTP in the list
Port Forwarding	enabled
Map to Port	80 – 80

Configuring a VIP for IPv6

In the Network section:

Configure the External IP Address/Range.

Configure the Mapped IP Address/Range. This will be the address that the traffic is being directed to.

There are two fields. If there is a single IP address, use that address in both fields. Enter the address in the standard IPv6 format.

In the Optional Filters

Disable/Enable the Optional Filters.

If only specific IP addresses and/or services are allowed to be the source for traffic using the VIP, enable the Optional Filters.

To specify an allowed address enter the value in the field labeled Source Address. The value can be formatted in three different ways.

To add additional addresses, click on the “+” below the last field with an address. To subtract an address, click on the “X” next to the field you wish to delete.

Disable/Enable Port Forwarding. If only the traffic for a specific port or port range is being forwarded, enable this setting.
Select the Protocol from l TCP l UDP l SCTP
Configure the External Service Port. This is the port(s) on the external interface of the FortiGate (the destination port in the header of the packets). The first field is for the first port in the range the second is for the last port in the range. As you enter a value in the first field, the second field will auto populate with the same number, working on the premise that a single port is common. Just edit the second field to extend the range.
Configure the setting Map to Port.This will be the listening port on the device located on the internal side of the network. It does not have to be the same as the External Service Port. The first field is for the first port in the range the second is for the last port in the range. As you enter a value in the first field, the second field will auto populate with the same number, working on the premise that a single port is common. Just edit the second field to extend the range.
Press

Configuring a VIP for NAT46

In the Network section:

Configure the External IP Address/Range.

Configure the Mapped IP Address/Range. This will be the address that the traffic is being directed to.

There are two fields. If there is a single IP address, use that address in both fields. Enter the address in the standard IPv6 format.

In the Optional Filters

Disable/Enable the Optional Filters.

If only specific IP addresses and/or services are allowed to be the source for traffic using the VIP, enable the Optional Filters.

To specify an allowed address enter the value in the field labeled Source Address. The value can be formatted in three different ways.

To add additional addresses, click on the “+” below the last field with an address. To subtract an address, click on the “X” next to the field you wish to delete.

Disable/Enable Port Forwarding. If only the traffic for a specific port or port range is being forwarded, enable this setting.
Select the Protocol from l TCP l UDP
Configure the External Service Port. This is the port(s) on the external interface of the FortiGate (the destination port in the header of the packets). The first field is for the first port in the range the second is for the last port in the range. As you enter a value in the first field, the second field will auto populate with the same number, working on the premise that a single port is common. Just edit the second field to extend the range.
Configure the setting Map to Port.This will be the listening port on the device located on the internal side of the network. It does not have to be the same as the External Service Port. The first field is for the first port in the range the second is for the last port in the range. As you enter a value in the first field, the second field will auto populate with the same number, working on the premise that a single port is common. Just edit the second field to extend the range.

Configuring a VIP for NAT64

In the Network section:

Configure the External IP Address/Range.

Configure the Mapped IP Address/Range. This will be the address that the traffic is being directed to.

There are two fields. If there is a single IP address, use that address in both fields. Enter the address in the standard IPv4 format.

In the Optional Filters

Disable/Enable the Optional Filters.

If only specific IP addresses and/or services are allowed to be the source for traffic using the VIP, enable the Optional Filters.

To specify an allowed address enter the value in the field labeled Source Address. The value can be formatted in three different ways.

To add additional addresses, click on the “+” below the last field with an address. To subtract an address, click on the “X” next to the field you wish to delete.

Disable/Enable Port Forwarding. If only the traffic for a specific port or port range is being forwarded, enable this setting.
Select the Protocol from l TCP l UDP
Configure the External Service Port. This is the port(s) on the external interface of the FortiGate (the destination port in the header of the packets). The first field is for the first port in the range the second is for the last port in the range. As you enter a value in the first field, the second field will auto populate with the same number, working on the premise that a single port is common. Just edit the second field to extend the range.
Configure the setting Map to Port.This will be the listening port on the device located on the internal side of the network. It does not have to be the same as the External Service Port. The first field is for the first port in the range the second is for the last port in the range. As you enter a value in the first field, the second field will auto populate with the same number, working on the premise that a single port is common. Just edit the second field to extend the range.
Press

Virtual IPs

Leave a reply

Virtual IPs

The mapping of a specific IP address to another specific IP address is usually referred to as Destination NAT.

When the Central NAT Table is not being used, FortiOS calls this a Virtual IP Address, sometimes referred to as a

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 will only refer to the specific ports configured. Because, the Central NAT table is disabled by default the term Virtual IP address or VIP will be used predominantly.

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 2 internal Interfaces made up of Private IP addresses is possible but there is rarely a reason to do so as the 2 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.

Something that needs to be considered when there are multiple Public IP addresses on the external interface(s) is that when a Virtual IP address is used without Port Forwarding enabled there is a reciprocal effect as far as traffic flow is concerned. Normally, on a firewall policy where NAT is enabled, for outgoing traffic the internal address is translated to the Public address that is assigned to the FortiGate, but if there is a Virtual IP address with no port forwarding enabled, then the Internal IP address in the Mapped field would be translated to the IP address configured as the External Address in the VIP settings.

Example

The assigned External address (WAN1) of the FortiGate unit is 172.12.96.3 with a subnet mask of 255.255.255.128 l There is a Virtual IP address set up to map the external address 172.12.96.127 on WAN1 to the internal IP address of 192.168.1.127
Port Forwarding is not enabled because you want all allowed traffic going to the external IP address to go to this server.

In this case any outbound traffic from 192.168.1.127 will go out on WAN1 with the IP address of 172.12.96.127 as the source IP address.

In terms of actually using the Virtual IP address, they would be using in the security policies in the same places that other addresses would be used, usually as a Destination Address.

UUID support for VIP

UUID is now supported in for virtual IPs and virtual IP groups. This includes virtual IPs for IPv4, IPv6, NAT46, and NAT64. To view the UUID for these objects in a FortiGate unit’s logs, log-uuid must be set to extended mode, rather than policy-only (which only shows the policy UUID in a traffic log). UUID can only be configured through the CLI

Syntax

config sys global set log-uuid {disable | policy-only | extended}

end

There is another type of address that the term “virtual IP address” commonly refers to which is used in load balancing and other similar configurations. In those cases, a number of devices share a separately created virtual IP address that can be sent to multiple possible devices. In FortiOS these are referred to as Virtual Servers and are configured in the “Load Balance” section.

If Central-NAT is enabled in the CLI the GUI will be different.

Instead of VIP Type, the field label will be DNAT & VIP Type

Instead of IPv4 the option will be IPv4 DNAT

There will also be the addition setting of Source Interface Filter.

Commands to set central-nat:

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

Creating an address group

Leave a reply

Creating an address group

Go to Policy & Objects > Addresses.
Select the down arrow next to Create New, select Address Group.
Choose the Category, that is applicable to the proposed selection of addresses.
Input a Group Name for the address object.

Depending on which Category has been chosen the configurations will differ slightly

IPv4 group

Select the “+” in the Members You can select members of the group from the window that slides out from the left of the screen. It is possible to select more than 1 entry. Select the “X” icon in the field to remove an entry.
Select the desired on/off toggle setting for Show in Address List.
Select the desired on/off toggle setting for Static Route Configuration .

IPv6 group

Select the “+” in the Members You can select members of the group from the window that slides out from the left of the screen. It is possible to select more than 1 entry. Select the “X” icon in the field to remove an entry.
Select the desired on/off toggle setting for Show in Address List.

Proxy group

Select which Type, either Source Group or Destination Group.
Select the “+” in the Members You can select members of the group from the window that slides out from the left of the screen. It is possible to select more than 1 entry. Select the “X” icon in the field to remove an entry.
Select the desired on/off toggle setting for Show in Address List.

Irrespective of the Category the groups all have the same final configuration options:

Input any additional information in the Comments field.

2. Press OK. UUID support

Syntax:

config firewall {address|addres6|addgrp|addgrp6} edit 1 set uuid <example uuid: 8289ef80-f879-51e2-20dd-fa62c5c51f44> next end

Address groups

Leave a reply

Address groups

Address groups are designed for ease of use in the administration of the device. If you have a number of addresses or address ranges that will commonly be treated the same or require the same security policies, you can put them into address groups, rather than entering multiple individual addresses in each policy refers to them.

The use of groups is not required. If you have a number of different addresses you could add them individually to a policy and the FortiGate firewall will process them just as quickly and efficiently as if they were in a group, but the chances are that if you have used a group once you could need to use it again and depending on the number of addresses involved entering them individually for each policy can become tedious and the likelihood of an address being missed becomes greater. If you have a number of policies using that combination of addresses it is much easier to add or subtract addresses from the group than to try and remember all of the firewall policies that combination of addresses was used in. With the group, you only have to make the one edit and it is used by any firewall policy using that address group.

Because security policies require addresses with homogenous network interfaces, address groups should contain only addresses bound to the same network interface, or to Any.

For example, if address 1.1.1.1 is associated with port1, and address 2.2.2.2 is associated with port2, they cannot be in the same group. However, if 1.1.1.1 and 2.2.2.2 are configured with an interface of Any, they can be grouped, even if the addresses involve different networks. There are 3 Categories of Address groups to choose from:

l IPv4 Group l IPv6 Group l Proxy Group

You cannot mix different categories of addresses within a group, so whether or not it makes sense from an administrative purpose to group certain addresses together, if some are IPv4 and some are IPv6, it cannot be done.