In this example, you will learn how to connect and configure a new FortiGate unit in NAT/Route mode to securely connect a private network to the Internet.

In NAT/Route mode, a FortiGate unit is installed as a gateway or router between two networks. In most cases, it is used between a private network and the Internet. This allows the FortiGate to hide the IP addresses of the private network using network address translation (NAT).

_{Find this recipe for other FortiOS versions
5.2 | 5.4 | 5.6}

1. Connecting the network devices and logging onto the FortiGate
Connect the FortiGate’s Internet-facing interface (typically WAN or WAN1, depending on your model) to your ISP-supplied equipment and connect a PC to the FortiGate using an internal port (typically port 1). Power on the ISP’s equipment, the FortiGate unit, and the PC on the internal network.
Using a PC on the internal network, connect to the FortiGate’s GUI using either FortiExplorer or an Internet browser (for information about connecting to the GUI, see your model’s QuickStart Guide). Login using an admin account (the default admin account has the username admin and no password).
2. Configuring the FortiGate’s interfaces
Go to Network > Interfaces and edit the Internet-facing interface (in the example, wan1). Set Role to WAN and set your Estimated Bandwidth (make sure to use Kbps, rather than Mbps).
If your FortiGate is directly connecting to your ISP, set Addressing Mode to Manual and set the IP/Netmask to the public IP address your ISP has provided you with. If you have ISP equipment between your FortiGate and the Internet (for example, a router), then the wan1 IP will also use a private IP assigned by the ISP equipment. If this equipment uses DHCP, set Addressing Mode to DHCP to get an IP assigned to the interface. If the ISP equipment does not use DHCP, your ISP can provide you with the correct private IP to use for the interface.
Edit the lan interface (called internal on some FortiGate models). Set Role to LAN. Set Addressing Mode to Manual and set the IP/Netmask to the private IP address you wish to use for the FortiGate. If you need your FortiGate to provide IP addresses to devices that connect to it, enable DHCP Server.
3. Adding a default route
Go to Network > Static Routes and create a new default route. Set Destination to Subnet, Destination IP/Mask to 0.0.0.0/0.0.0.0, the Device to the Internet-facing interface, and the Gateway to the gateway (or default route) provided by your ISP or to the next hop router, depending on your network requirements.
4. (Optional) Setting the FortiGate’s DNS servers
The FortiGate unit’s DNS Settings are set to use FortiGuard DNS servers by default, which is sufficient for most networks. However, they can be changed if necessary.
To change the DNS servers, go to Network > DNS, select Specify, and add Primary and Secondary servers.
5. Creating a policy to allow traffic from the internal network to the Internet
Go to Policy & Objects > IPv4 Policy and create a new policy. Give the policy a Name that indicates that the policy will be for traffic to the Internet (in the example, Internet).
Set the Incoming Interface to the lan interface and the Outgoing Interface to the Internet-facing interface. Set Source, Destination Address, Schedule, and Services as required. Make sure the Action is set to ACCEPT. Turn on NAT and make sure Use Outgoing Interface Address is selected.
Scroll down to view the Logging Options. In order to view the results later, enable Log Allowed Traffic and select All Sessions.
5. Results
Browse the Internet using the PC that connects to the FortiGate’s internal interface.
You can view information about the traffic being processed by your FortiGate by going to FortiView. Under Traffic from LAN/DMZ, select Sources. A listing is shown for the computer you are browsing with.
Right-click on the listing for your computer and select Drill Down to Details to view realtime information about traffic from this computer. If your FortiGate model has a hard drive, a dropdown menu in the top corner will allow you to view historical logging information (5 minutes, 1 hour, and 24 hours).

The post Installing a FortiGate in NAT/Route mode appeared first on Fortinet Cookbook.

In this example, you will configure a security fabric that consists of four FortiGates and a FortiAnalyzer. One of the FortiGates will be the root (or upstream) FortiGate in the Security Fabric, while the others function as Internal Segmentation Firewalls (ISFWs). OSPF routing will be used for communication between devices.

Once the Fabric has been configured, a Security Fabric Audit is run, to make any necessary improvements to the configuration.

In the example, the following FortiGate aliases/models are used:

• External (root FortiGate): a FortiGate 600D
• Accounting: a FortiGate 140D
• Marketing: a FortiGate 90D
• Sales: a FortiGate 51E

_{Find this recipe for other FortiOS versions
5.4 | 5.6}

1. Configuring the External FortiGate
In the Security Fabric, the External FortiGate is the root, or upstream, FortiGate. All the ISFW FortiGates will link to External in order to connect to other devices in the fabric, as well as the Internet. In this example, the following interfaces on the External FortiGate are used to connect to other network devices: Port 9 connects to the Internet (this interface has already been configured) Port 10 connects to Accounting (IP address: 192.168.10.2) Port 11 connects to Marketing (IP address: 192.168.200.2) Port 12 connects to Sales (IP address: 192.168.35.2) Port 16 connects to the FortiAnalyzer (IP address: 192.168.55.2)
On External, go to Network > Interfaces and edit port 10. Set an IP/Network Mask for the interface (in the example, 192.168.10.2).
Configure Administrative Access to allow FortiTelemetry, required for communication between FortiGates in the Security Fabric. Configure other services as required.
Repeat this step to configure the other interfaces, setting the appropriate IP addresses.
Go to Policy & Objects > IPv4 Policy and create a policy for traffic from Accounting to the Internet. Enable NAT.
Repeat this step to create similar policies for Marketing and Sales.
On the External FortiGate, go to System > Feature Select. Under Additional Features, select Multiple Interface Policies.
Go to Policy & Objects > IPv4 Policy and create a policy allowing the ISFW FortiGates to access the FortiAnalyzer. Do not enable NAT.
To enable Security Fabric and configure the connection to the FortiAnalyzer, go to System > Security Fabric and enable Security Fabric. Set a Group Name and Password. FortiAnalyzer logging is now enabled by default. Set IP Address to the FortiAnalyzer port 2’s IP (in the example, 192.168.55.10).
Select Test Connectivity. An error appears because the FortiGate is not authorized on the FortiAnalyzer.
2. Installing the Accounting FortiGate
On Accounting, go to Network > Interfaces and edit wan1. Set an IP/Network Mask for the interface that is on the same subnet as the External FortiGate’s port 10 (in the example, 192.168.10.10). Configure Administrative Access to allow FortiTelemetry.
Edit the lan interface. Set Addressing Mode to Manual and set the IP/Netmask to a private IP address (in the example, 10.10.10.1). Configure Administrative Access to allow FortiTelemetry. If you require the FortiGate to provide IP addresses using DHCP to devices that connect to this interface, enable DHCP Server. Under Networked Devices, enable Device Detection.
Go to Policy & Objects > IPv4 Policy and create a policy to allow users on the Accounting network to access the Internet. Because OSPF routing will be used, make sure NAT is not enabled.
Go to System > Security Fabric to add Accounting to the fabric. Enable Security Fabric, then enter the Group name and Group password set previously. Enable Connect to upstream FortiGate and enter the IP of External’s port 10. FortiAnalyzer logging is enabled by default. Settings for the FortiAnalyzer will be retrieved when Accounting connects to External.
If you have not already done so, connect Accounting’s wan1 port to External’s port 10.
3. Installing the Marketing and Sales FortiGates
Connect and configure Marketing using the same method as Accounting. Make sure to include the following: Configure wan1 to connect to the External FortiGate (example IP: 192.168.200.10) Configure the lan interface for the Marketing network (example IP: 10.10.200.1) Create a policy to allow users on the Marketing network to access the Internet Add the FortiGate to the Security Fabric
Connect and configure Sales, making sure to include the following: Configure wan1 to connect to the External FortiGate (example IP: 192.168.35.10) Configure the lan interface for the Sales network (example IP: 10.10.35.1) Create a policy to allow users on the Sales network to access the Internet Add the FortiGate to the Security Fabric
4. Configuring OSPF routing between the FortiGates
On External, go to Network > OSPF. Set Router ID to 0.0.0.1 and select Apply. Expand the Advanced Options and set Default Information to Always, to make sure the default route is broadcast from External to the ISFW FortiGates.
In Areas, select Create New. Set Area to 0.0.0.0, Type to Regular, and Authentication to None.
In Networks, select Create New. Set IP/Netmask to 192.168.10.0/255.255.255.0 (the subnet that includes Accounting’s wan1) and Area to 0.0.0.0. Create three additional entries, using the following IP addresses: 192.168.200.0/255.255.255.0 (Marketing) 192.168.35.0/255.255.255.0 (Sales) 192.168.55.0/255.255.255.0 (FortiAnalyzer)
On the Accounting FortiGate, configure OSPF routing as shown. The Router ID is incremental, with this FortiGate using 0.0.0.2. The Networks in this configuration are the subnet that includes Accounting’s wan1 and the subnet for the Accounting Network.
Some FortiGate models, including the 90D and 51E used in this example, do not support configuring OSPF routing from the GUI. To add OSPF routing, use the following CLI command: config router ospf set router-id 0.0.0.x config area edit 0.0.0.0 next end config network edit 1 set prefix x.x.x.0/255.255.255.0 next edit 2 set prefix x.x.x.0/255.255.255.0 next end end
5. Configuring the FortiAnalyzer
In order to use the FortiAnalyzer in the Security Fabric, make sure that the firmware is compatible the version of FortiOS on the FortiGates. To check for compatibility, please refer to the FortiAnalyzer Release Notes.
On the FortiAnalyzer, go to System Settings > Network, select All Interfaces, and edit port2. Set IP/Netmask to an internal IP (in the example, 192.168.55.10/255.255.255.0).
Select Network again. Port 2 is now shown as the management interface. Add a Default Gateway, using the IP address of the External FortiGate’s port 16.
Go to Device Manager. The FortiGates are listed as Unregistered.
Select the FortiGates, then select +Add.
The FortiGates now appear as Registered.
On External, go to System > Security Fabric. FortiAnalyzer Logging now shows Storage Usage information.
6. Running a Security Fabric Audit
The Security Fabric Audit is used to analyze your Security Fabric deployment to identify potential vulnerabilities and highlight best practices. Using the Audit helps you tune your network’s configuration, deploy new hardware and/or software, and gain more visibility and control of your network. Also, by checking your Security Score, which is determined based on how many checks your network passes/fails during the Audit, you can have confidence that your network is getting more secure over time. The Security Fabric Audit must be run on the root FortiGate in the Security Fabric (in this example, External).
On External, go to Log & Report > Security Fabric Audit. All the FortiGates in the Fabric are shown. Select Next.
At the top of the page, you can see your Security Score, as well as the overall count of how many checks were passed or failed, with the failed checks divided by severity. Further down, information is shown about each failed check, including which FortiGate failed the check, the effect on your score, and the recommendation to fix the issue. Some recommendations may be listed as Easy Apply. To apply these changes, select Next.
By using Easy Apply, you can change the configuration of any FortiGate in the fabric, not just the root FortiGate. Select all the changes you wish to make, then select Apply Recommendations.
7. Results
On External, go to Dashboard > Main. The Security Fabric widget displays all devices in the fabric.
Also located on the Dashboard is the Security Fabric Score widget, which displays your current score. If either of these widgets do not appear on your dashboard, they can be added using the Options button in the bottom right corner.
Go to FortiView > Physical Topology. This page shows a visualization of all access layer devices in the Security Fabric. Security Fabric Audit recommendations are also shown in the topology, by the icon for the device the recommendations apply to.
Go to FortiView > Logical Topology. This dashboard displays information about the interface (logical or physical) that each device in the CSF is connected to.
Go to Monitor > Routing Monitor. You will see both ISFW FortiGates listed, using OSPF routing.
8. (Optional) Adding security profiles to the fabric
A Security Fabric configurations allow you to distribute security functions to different FortiGates in the fabric. For example, you may want to implement virus scanning on the External FortiGate but add application control and web filtering to the ISFW FortiGates. This results in distributed processing between the FortiGates in the Security Fabric; reducing the load on each one. It also allows you to customize the web filtering and application control for the specific needs of the Accounting network as other internal networks may have different application control and web filtering requirements. This configuration may result in threats getting through the External FortiGate which means you should very closely limit access to the network connections between the FortiGates in the fabric.
On External, go to Policy & Objects > IPv4 Policy and edit the policy allowing traffic from Accounting to the Internet. Under Security Profiles, enable AntiVirus and select the default profile. Do the same for the policies allowing traffic from the Marketing and Sales to the Internet.
On Accounting, go to Policy & Objects > IPv4 Policy and edit the policy allowing traffic from the Accounting Network to the Internet. Under Security Profiles, enable Web Filter and Application Control. Select the default profiles for both. Do the same on Marketing and Sales.

The post Security fabric installation appeared first on Fortinet Cookbook.

In this example, you will allow remote users to access the corporate network using an SSL VPN, connecting either by web mode using a web browser or tunnel mode using FortiClient.

Web mode allows users to access network resources, such as the Internal Segmentation Firewall (ISFW) used in this example.

For users connecting via tunnel mode, traffic to the Internet will also flow through the FortiGate, to apply security scanning to this traffic. During the connecting phase, the FortiGate will also verify that the remote user’s antivirus software is installed and up-to-date.

_{Find this recipe for other FortiOS versions
5.2 | 5.4 | 5.6}​

1. Creating a user and a user group
Go to User & Device > User Definition to create a local user account for a SSL VPN user.
Go to User & Device > User Groups to create a user group for SSL VPN users and add the new user account.
2. Editing the SSL VPN portal for remote users
Go to VPN > SSL-VPN Portals to edit the full-access portal. The full-access portal allows the use of tunnel mode and/or web mode. Make sure Enable Split Tunneling is not selected, so that all Internet traffic will go through the FortiGate. Set Source IP Pools to use the default IP range SSLVPN_TUNNEL-ADDR1.
Under Predefined Bookmarks, click Create New to add a new bookmark. Bookmarks are used as links to internal network resources. In the example, a bookmark is added to connect to a FortiGate being used as an ISFW, which can be accessed at https://192.168.100.1
3. Configuring the SSL VPN tunnel
Go to VPN > SSL-VPN Settings and set Listen on Interface(s) to wan1. To avoid port conflicts, set Listen on Port to 10443. Set Restrict Access to Allow access from any host. In the example, the Fortinet_Factory certificate is used as the Server Certificate. It is, however, recommended that you purchase a certificate for your domain and upload it for use with an SSL VPN. Under Tunnel Mode Client Settings, set IP Ranges to use the default IP range SSLVPN_TUNNEL-ADDR1.
Under Authentication/Portal Mapping, click Create New to add the SSL VPN user group and map it to the full-access portal. If necessary, map a portal for All Other Users/Groups.
4. Adding an address for the local network
Go to Policy & Objects > Addresses to add the address for the local network. Set Type to IP/Netmask, Subnet/IP Range to the local subnet, and Interface to an internal port.
5. Adding security policies for access to the internal network and Internet
Go to Policy & Objects > IPv4 Policy. Add a security policy allowing access to the internal network through the VPN tunnel interface. Set a policy name that will identify what this policy is used for (in the example, SSL-VPN-internal) Set Incoming Interface to ssl.root and Outgoing Interface to the local network interface. Select Source and set Address to all and User to the SSL-VPN user group. Set Destination Address to the local network address, Service to ALL, and enable NAT. Configure any remaining firewall and security options as desired.
Add a second security policy allowing SSL VPN access to the Internet. For this policy, Incoming Interface is set to ssl.root, Outgoing Interface is set to wan1, and Destination is set to all.
6. Verifying users have current AntiVirus software
Open the CLI Console located at the top right corner of the screen. Enter the following commands to enable the host to check for compliant AntiVirus software on the remote user’s computer: config vpn ssl web portal edit full-access set host-check av end
7. Results
The steps for connecting to the SSL VPN differ depending on whether you are using a web browser or FortiClient.
Web browsers: Using a supported Internet browser, connect to the SSL VPN web portal using the remote gateway configured in the SSL VPN settings (in the example, 172.20.121.26:10443) Use the SSL VPN user’s credentials.
The web portal appears.
In this example, selecting the ISFW Bookmark allows you to connect to the ISFW FortiGate using HTTPS.
To connect to the Internet, select Quick Connection. Select HTTP/HTTPS, then enter the URL and select Launch.
The website loads.
You can also use the Quick Connection for other allowed types of traffic, such as SSH. An SSH connection will open in your browser, connecting to the requested Host. Java is required for an SSH connection.
On the FortiGate, go to Monitor > SSL-VPN Monitor. The user is connected to the VPN.
FortiClient: If you have not done so already, download FortiClient from www.forticlient.com. Open the FortiClient Console and go to Remote Access. Add a new connection. Set VPN Type to SSL VPN, set Remote Gateway to the IP of the listening FortiGate interface (in the example, 172.20.121.26). Select Customize Port and set it to 10443. Select Add.
Connect to the VPN using the SSL VPN user’s credentials.
You are able to connect to the VPN tunnel.
On the FortiGate, go to Monitor > SSL-VPN Monitor. The user is connected to the VPN.

The post SSL VPN using web and tunnel mode appeared first on Fortinet Cookbook.

You can operate your FortiGate or individual VDOMs on your FortiGate in Next Generation Firewall (NGFW) mode when you select flow-based inspection. In the new FortiOS 5.6 NGFW policy-based mode, you 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 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 will have to create one.

This recipe demonstrates a basic configuration of blocking Facebook using the new NGFW policy-based mode.

1. Configuring your FortiGate for NGFW policy-based mode
Go to the System > Settings page and scroll down to Operations Settings. Select Flow-based Inspection Mode. Select Policy-based as the NGFW mode. Select an SSL/SSH Inspection certificate.
2. Creating a Central SNAT Policy
Under Policy & Objects, go to Central SNAT and select Create New. Set Incoming Interface to the local network interface. Set Outgoing Interface to your Internet-facing interface. Set IP Pool Configuration to Use Outgoing Interface Address and Protocol to ANY.
3. Creating an IPv4 policy to block Facebook
Go to Policy & Objects > IPv4 and create a new policy. Set Incoming Interface to the local network interface. Set Outgoing Interface to your Internet-facing interface.
Under Application, click on the plus sign. Type Facebook in the search field.
Add all the Facebook applications to the policy. Set the Action to DENY.  Enable Log Violation Traffic to see results later. You can disable this feature later to conserve network resources.
4. Ordering the policy table
Go to Policy & Objects > IPv4 Policy to view the policy table. In order to have the correct traffic flowing through each policy, they must be arranged so that the more specific policies are located at the top.
To rearrange the policies, select the column on the far left (in the example, Seq.#) and drag the policy to the desired position.
5. Results
Browse to www.facebook.com. Your connection will time out.
Go to FortiView >  Threats. You can see the traffic blocked by the firewall policy.

For further reading, check out the What’s New in FortiOS 5.6 and the Central SNAT section in the Firewall chapter of the FortiOS 5.6 Handbook.

The post Introducing NGFW policy-based mode appeared first on Fortinet Cookbook.

What do hair pins have to do with networking?

Hair-pinning, in a networking context, is the method where a packet travels to an interface, goes out towards the Internet but instead of continuing on, makes a “hair pin turn”, and comes back in on the same interface. Initially, it may seem unnecessary or pointless even but it does serve a purpose.

These days, due to the shortage of IPv4 addresses, most networks behind a firewall, use private IP addresses. Private IPv4 addresses are not routable so a virtual IP needs to be configured to allow users from the Internet to access any private IP addresses on the internal side of the FortiGate. For more information on private IPv4 addresses, you can check out RFC 1918. 

For instance, on the Internet you could use the address of the external IP, where the traffic would then be forwarded to the internal address of the server. You could then use the internal IP address to access the server if you are on the internal LAN. There is also the option to allow everyone to use a consistent address by setting up a Fully Qualified Domain Name (FQDN). This simplifies access seeing as words are easier to remember than IP addresses.  

In recent years, system administrators focused on finding ways to strengthen their systems to prevent outside threats from intruding their networks. Unfortunately, they did not always take the time to protect their networks from internal threats, a situation where an internal resource became compromised. Hackers, crackers and other malicious actors took advantage of this weakness and invented “spoofing”. The bad guys used the spoofing method to alter packets to appear as if they were coming from the internal network, kind of like buzzing at the door of an apartment building and when someone answers, saying “let me back in, please”. 

It took some time for the devices and programmers of network protocols to catch up. Networking and protocols were originally designed to work where everybody was on the same side. The security aspect was added later on as some people began exploiting the system.

It was not long before the good guys developed techniques to harden their systems to prevent packets coming in from what appear as internal IP addresses, when in reality, the packets are coming in from the Internet. 

In order to use a common FQDN in combination with the VIP, the traffic has to come in to through the external interface to access the server. This is where the VIP accepts traffic. 

System administrators put a lot of effort into preventing packets with internal IP addresses from coming in through the external interface. Humans have the ability of understanding the context of what is going on and use their judgment accordingly, but computers have no judgment and do only what you tell them to; nothing more. A computer has no basis for setting apart malicious attacks and safe traffic based only on the source address of the traffic. However, it is safe to assume that something coming in from the outside with an internal address raises some red flags. This is the reason why it is important to specify the source IPs of which traffic can be forwarded to the internal IP through the VIP.

A properly configured FortiGate is aware of the criteria to determine which source IP addresses will allow a packet to be forwarded to the internal IP address. If the incoming packets are from an allowed IP address, along with the other allowed parameters, they are forwarded to the appropriate internal address. If they are not explicitly approved, they are explicitly denied. 

In the growing battle and evolution of those building a mousetrap and those trying to build an even better mousetrap, adapting to those changes becomes necessary. System administrators need to acclimate to the evolution on both sides all the while ensuring the user’s needs are met and the security on the network is maintained. Right now, one of the adaptations we make is to use a hair-pinning technique. This means working around the protections put in place to prevent malicious attacks and at the same time, accommodating users on a network. This technique provides users with the convenience of a continuous method of access and the security of preventing a commonly used attack technique.

The post Using Hair-pinning in a Network appeared first on Fortinet Cookbook.

In this example, you will learn how to change the IPMI Password in FortiManager and FortiAnalyzer.

Some devices include an unused IPMI port, such as the FAZ-1000E. You cannot use the operating system running on the device to access the IPMI port. For example, you cannot use FortiAnalyzer software to access the IPMI port on the FAZ-1000E.

Although the IPMI port is not used, in some cases the port is enabled, and you can access it by connecting a cable to the port. If there is a DHCP server in the network, the port will automatically obtain an IP address. You can use a web browser, the IP address, and the default password (ADMIN/ADMIN) to access the port.

To prevent misuse, you should change the default password.

1. Obtain the IPMI Port IP Address

1. Connect a cable to the IPMI Port.
2. Obtain the IP address for the IPMI Port. 

2. Sign in

1. In a browser, type http://<ip address>.
2. Press Enter. The Please Login dialog box is displayed.
3. In the Username field, type ADMIN.
4. In the Password field, type ADMIN. 
5. Click Login. The home page is displayed.

3. Modify User

1. Go to Configuration > Users.
2. Select the row with the ADMIN username.
3. Click Modify User.
   
4. Select the Change Password Checkbox.
5. Complete the Password and Confirm Password fields
6. Click Modify.

The post Changing the IPMI Password appeared first on Fortinet Cookbook.

Hair-pinning, also known as NAT loopback, is the technique where a machine accesses another machine on the LAN via an external network. The way it works, is that a packet travel through an internal interface and out towards the Internet. The packet then “hair-pins” back on the same interface, connecting to its external IP. It is then forwarded by the FortiGate through a virtual IP to the intended destination. 

As a convenience, if a VIP is being used simultaneously with hair-pinning, the same address can be used whether you are on the inside or the outside of the firewall. A VIP, also known as port forwarding, is set up to allow external users to access an internal server. The VIP will take traffic sent to a public IP address and forward it to an internal IP address, such as the server’s private IP.  

The following hair-pinning scenario uses the situation where the VIP is associated to “any” interface.

Scenario:

• A company has a server on its internal LAN at IP address 192.168.1.98/24.
• The Fully Qualified Domain Name for the website is test1.fortidoc.info, which resolves to 172.20.121.41.
• SSH is running on the server and it will be used for testing purposes. The server listens for SSH traffic on port 22 but because there are multiple servers using SSH and only a few external IP address; port forwarding will be set up from port 12345.
• Seeing as words are easier to remember than numbers, most people bookmark this connection rather than try to remember it. To avoid confusion, the IT department has been asked to make sure the same bookmark works whether the user’s computer is connected to the internal LAN or anywhere on the Internet.
• As a test, the packets will try and connect to the server from an IP on the same subnet, 172.20.121.41.

Here is what you need to do to configure hair-pinning on your FortiGate:

1. Create a VIP

Before creating a policy for the hair-pinning, ensure that there is a policy managing traffic from the external to internal through the VIP.

Go to Policy & Objects > Virtual IPs > Create New > Virtual IP. Enter a name for the VIP in the name box. Set Interface to any. Enter the External IP Address/Range and the Mapped IP Address/Range. Enable Port Forwarding and specify the External Service Port and the Map to Port.

Verifying the situation

In order to propose a solution, there must first be a problem. Let’s verify if there is an issue:

Testing the connection externally

You can try to connect to the external server via the external IP and VIP from a computer on the external side of the firewall. The connection is successful.

Testing the connection internally

You can try to connect to the internal server via the external IP and VIP from a computer on the internal side of the firewall. The connection is unsuccessful.

2. Create a policy

When creating a policy for hair-pinning, it is important to use the internal interface as the Incoming Interface even though the traffic will be hitting the external interface of the VIP. In this case, the Incoming Interface and Outgoing Interface will be the same interface.

Go to Policy & Objects > IPv4 Policy > Create New. Enter a name for the policy in the name box. Use the settings displayed in the graphic to create the policy. Ensure that NAT is disabled.
In the CLI, enable the match-vip setting.

3. Results

Testing the connection internally:

Try to make an SSH connection to the internal server from the internal side of the FortiGate.
Here you can see that the hair-pinning technique was successful.

The post Configuring Hair-pinning on a FortiGate appeared first on Fortinet Cookbook.

The following example demonstrates how to configure redundant Internet using the new SD-WAN feature in FortiOS 5.6. 

The goal of SD-WAN is to seamlessly manage traffic at the Layer 2 level of the OSI model without the need to manage hardware-based switches or WAN controllers.

The example includes volume-based weighted load balancing so that 75% of your Internet traffic is handled by the ISP connected to WAN1, with the remaining 25% handled by the ISP connected to WAN2.

This configuration also means that in the event of a failure connecting to one ISP, all traffic will divert to the other WAN interface (this is commonly referred to as ‘failover’).

1. Connecting your ISPs to the FortiGate
Connect your ISP devices to your FortiGate so that the ISP you wish to use for most traffic is connected to WAN1 and the other connects to WAN2.
2. Modifying existing policies
You will not be able to add any interface to the SD-WAN interface that is already used in the FortiGate’s configuration. So, in this scenario, you must delete any security policies that use either WAN1 or WAN2, such as the default Internet access policy. Traffic will not be able to reach WAN1 or WAN2 through the FortiGate after you delete the existing policies. It is also advisable to check for any other references to WAN1 or WAN2 and make the necessary modifications. If you have many policies that reference WAN1 and/or WAN2, a simple method is to redirect those policies to unused ports, rather than delete them, to avoid having to recreate each policy from scratch. Obviously, you should redirect those same policies back to the SD-WAN interface once it is created.
Go to Policy & Objects > IPv4 Policy and delete any policies that use WAN1 or WAN2.
3. Creating the SD-WAN interface
Go to Network > SD-WAN. Set the Interface State to Enable. Under SD-WAN, add the two WAN interfaces.
Under Load Balancing Algorithm, select Volume and prioritize the WAN1 interface to serve more traffic. In the example, the ISP connected to WAN1 is a 40Mb link, and the ISP connected to WAN2 is a 10Mb link, so we balanced the weight 75% to 25% in favor of WAN1.
To help visualize the effectiveness of the algorithm selected, the WAN Links Usage graph shows you the Bandwidth and Volume usage.
4. Configuring SD-WAN Status Check
You can optionally configure SD-WAN Status Check to verify the health and status of the links that make up the virtual WAN link. This configuration uses the Ping protocol to verify the status of the SD-WAN. Go to Network > SD-WAN Status Check and (if you wish to use Google) enter the values shown here.
5. Allowing traffic from the internal network to the SD-WAN interface
Go to Policy & Objects > IPv4 and create a new policy. Set Incoming Interface to your internal network’s interface and set Outgoing Interface to the SD-WAN interface. Enable NAT and apply Security Profiles as required. Enable Log Allowed Traffic for All Sessions to allow you to verify the results later. At this point, you should recover any policies that may have been redirected or deleted in Step 2 and point them to the SD-WAN interface.
6. Results
Browse the Internet using a computer on the internal network and then go to Network > SD-WAN > SD-WAN Usage. You can see the bandwidth and volume of traffic traversing the SD-WAN interfaces.
Verify that Status Check is working by viewing the table at Network > SD-WAN > SD-WAN Status Check.
Go to Monitor > SD-WAN Monitor to view the number of sessions for each interface, bit rate, and more.
7. Testing failover
To test failover of the redundant Internet configuration, you must simulate a failed Internet connection to one of the ports. Do so by physically disconnecting the Ethernet cable connected to WAN1.
Verify that users still have Internet access by navigating to Monitor > SD-WAN Monitor. Note the Upload/Download of each WAN interface.
Furthermore, go to Network > SD-WAN > SD-WAN Usage to see that bandwidth and volume have diverted entirely through WAN2.
Users on the internal network should have no knowledge of the WAN1 failure. Likewise, if you are using the WAN1 gateway IP to connect to the admin dashboard, nothing should change from your perspective. It will appear as though you are still connecting through WAN1. Reconnect the WAN1 Ethernet cable when you have verified successful failover.

The post Redundant Internet with SD-WAN appeared first on Fortinet Cookbook.

The trouble with RJ-45 physical ports is that just from looking at them it’s hard to see any difference between them. Compare two Ethernet ports on any network device. Without knowing the specs of the device and of each interface in particular, can you tell which ones can handle 40GB of traffic and which ones top out at 10 MB? Chances are that not all of the Ethernet ports, despite their appearance, will have the same capabilities. Different ports can have different roles and therefore different requirements. Some may be designed for high levels of bandwidth, and be capable of transferring Gigabytes of traffic in a second. Others are designed for more limited traffic as they are only expected to communicate with one or two computers at a time. The Console and Management ports are examples of this.

It’s a practical reality of business that when building a device of any kind a company will not spend the extra expense of installing a high performance component where that performance isn’t needed. This is why you don’t by a Ferrari to use as a golf cart.

I will admit that there are some dedicated System Administrators that don’t use a device until they have practically memorized the hardware manual that comes with them, and these people can tell you all sorts of minutia about every aspect of any device in their network. I’m not quite that dedicated to that particular aspect of the profession. Once I’m sure that the device is the applicable one for the task, I work on the assumption that the label associated with any given port will indicate its best use. It’s also easier to figure out which cables go where.

Whether you call it a rule of thumb or best practices, I find I’m usually safe if I make the following assumptions:

• Numbered ports are for high traffic connections. If the other end of the Ethernet cable is going to a network device or server these are the ports to use.
• DMZ ports are similar to numbered ports. The label is really there to differentiate between the inside of your network where the servers that are accessible from the Internet go as opposed the LAN where the Internet should not be accessing.
• WAN ports may or may not be as suitable for high levels of traffic as the ISP may be a limiting factor on how much traffic is likely to be going through. You may or may not have noticed that the bigger enterprise class FortiGates, that are likely to be used where the ISP connections are capable of large amounts of bandwidth, tend not to have ports labeled as WAN1 and WAN2, just numbered ports. It’s the smaller devices that are designed for small and midsize offices, and lower bandwidth ISPs that have labels indicating which ports to use for the WAN connection.
• Ports labelled MGMT are for administrative connections. These ports are intended to be dedicated for use by System administrators. Even if you have a configuration that changes a lot, this is not going to require a lot of bandwidth. In fact, these ports are designed as endpoint nodes where there is normally no need for traffic coming into this port to go out another port. The only reason that they even show up in the Interface configuration is because the same security measures that are used to control pass through traffic can be used to limit access to just the System Administrators.
• CONSOLE ports are a whole different thing entirely and can’t be used for anything other than a console cable with an Ethernet connector, so don’t even try.

It’s the old story of using the right tool for the right job. Use the different Ethernet ports in their intended roles and everything should run smoothly.

The post Not all Ethernet interfaces are equal appeared first on Fortinet Cookbook.

In this video, you will learn how to create schedules that restrict Internet access based on whether users are full-time or part-time employees. You will also deny access to staff members using mobile phones. Scheduling access will allow you to control how much bandwidth is used.

This example involves a full-time employee who will have unlimited access, a part-time employee who will have limited access, and mobile phone users who will not have any access. A WiFi network has already been configured for the mobile part of this example.

The recipe for this video is available here.

Watch more videos

The post User and Device Authentication appeared first on Fortinet Cookbook.

Take our FortiCast feedback survey to help us improve the show!

Learn all about FortiDDoS in this episode, featuring a discussion between Steve Robinson and Hemant Jain.

FortiDDoS resources

• DDoS Protection – FortiDDoS
• Solution Brief: FortiDDoS and Verisign DDoS Protection Service 
• Technical Training: FortiDDoS

Subscribe to FortiCast

The post Episode 10: FortiDDoS appeared first on Fortinet Cookbook.

FortiVoice Enterprise features conference calling, which allows multiple clients to join a live group discussion.

The following video details how to create both an ongoing conference call and a one-time conference call.

The post Configuring Conference Calls in FortiVoice Enterprise (Video) appeared first on Fortinet Cookbook.

The following video guides you through the process of configuring call recording and archiving recorded calls in FortiVoice Enterprise.

The post Recording Calls in ForitVoice Enterprise (Video) appeared first on Fortinet Cookbook.

In this recipe, you will add a FortiSandbox to your Security Fabric and configure each FortiGate in the fabric to send suspicious files to FortiSandbox for Sandbox Inspection. These files will be scanned and tested in isolation from your network on the FortiSandbox .

This example uses the Security Fabric configuration created in the recipe Security Fabric installation. The FortiSandbox will connect to the root FortiGate in the fabric, known as External. There will be two connections between the devices:

• FortiSandbox port 1 (administration port) connects to External port 16
• FortiSandbox port 3 (VM outgoing port) connects to External port 13

_{Find this recipe for other FortiOS versions
5.4 | 5.6}

1. Running a Security Fabric Audit without using FortiSandbox
On External (the root FortiGate of the Security Fabric), go to Log & Report > Security Fabric Audit. Run an Audit for your Security Fabric.
Since you are not using FortiSandbox, your Security Fabric will fail the Advanced Threat Protection check and you Security Score will decrease by 30 points for each FortiGate in the Fabric.
2. Connecting the FortiSandbox and External
On the FortiSandbox, go to Network > Interfaces and configure port 1. This port will be used for communication between the FortiSandbox and your security fabric. Set the IP/Network Mask to an internal IP address. In this example, the FortiSandbox will connect to the same subnet as a previously installed FortiAnalyzer, using the IP address 192.168.55.20.
Go to Network > Interfaces and configure port 3. This port will be used for outgoing communication by the FortiSandbox’s Virtual Machines (VMs). It is recommended to connect this port to a dedicated interface on your FortiGate to protect the rest of the network from threats currently being investigated by the FortiSandbox. Set the IP/Network Mask to an internal IP address (in the example, 192.168.179.10/255.255.255.0).
On the FortiSandbox, go to Network > System Routing and add a static route for port 1. Set Gateway to the IP of the FortiGate interface that port 1 connects to (in the example, 192.168.55.2).
On External, go to Network > Interfaces and port 13. Set IP/Network Mask to an address on the same subnet as port 3 (in the example, 192.168.179.2/255.255.255.0)
FortiSandbox port 3 must be able to connect to the Internet. On the FortiGate, go to Policy & Objects > IPv4 Policy and create a policy allowing connections from the FortiSandbox to the Internet.
If you haven’t already done so, connect the FortiSandbox to your security fabric as shown in the diagram.
3. Activating the FortiSandbox VMs
On the FortiSandbox, go to Scan Policy > General. Enable Allow Virtual Machines to access external network through outgoing port3 and set Gateway to the IP address of the FortiGate port 13.
Wait for the FortiSandbox to confirm that it has access to the Internet. Once this occurs, it will start to activate and initialize the Microsoft Windows VM and the Microsoft Office VM. Go to the Dashboard and locate the System Information widget. When the VMs are ready to go, green checkmarks will appear beside them.
4. Adding the FortiSandbox to the Security Fabric
On External, go to System > Security Fabric. Enable Sandbox Inspection. Make sure FortiSandbox Appliance is selected and set Server to the IP address of the FortiSandbox’s port 1.
Select Test Connectivity. An error message appears because External has not been authorized on the FortiSandbox.
On the FortiSandbox, go to Scan Input > Device. External is listed but shown as unauthorized.
Select the Edit button located beside External’s name. Under Permissions and Policies, select Authorized.
On External, go to System > Security Fabric and test the Sandbox Inspection connectivity again. External is now connected to the FortiSandbox.
Repeat these steps for the other FortiGates in the Security Fabric.
5. Adding Sandbox Inspection to AntiVirus, Web Filter, and FortiClient Profiles
Sandbox Inspection can be applied to three security profiles: AntiVirus, Web Filter, and FortiClient Profiles. In this step, Sandbox Inspection should be added on all FortiGates in the fabric individually, using the profiles that each FortiGate applies to traffic.
Go to Security Profiles > AntiVirus and edit the default profile. Under Inspection Options, set Send Files to FortiSandbox Application for Inspection to All Supported Files.
Enable Use FortiSandbox Database, so that if FortiSandbox discovers a threat, a signature for that file is added to the FortiGate’s AntiVirus signature database.
Go to Security Profiles > Web Filter and edit the default profile. Under Static URL Filter, enable Block malicious URLS discovered by FortiSandbox.
If the FortiSandbox discovers a threat, the URL that threat came from will be added to the list of URLs that will be blocked by the FortiGate.
Go to Security Profiles > FortiClient Profiles and edit the default profile. Enable Security Posture Check.  Enable Realtime Protection and Scan with FortiSandbox.
6. Results
If your FortiGate discovers a suspicious file, it will now be sent to the FortiSandbox. To view information about the files that have been sent on the FortiGate, go to the Dashboard and locate the Advanced Thread Protection Statistics widget, which shows files scanned by both the FortiGate and FortiSandbox.
You can also view results on the FortiSandbox by going to System > Status and viewing the Scanning Statistics widget.
On External, go to Log & Report > Security Fabric Audit and run an Audit. When it is finished, select the All Results view.
Your Fabric has passed the Advanced Threat Protection check and your Security Score has improved.

The post FortiSandbox in the Security Fabric appeared first on Fortinet Cookbook.

Upgrading to 5.6

The tables below show the upgrade paths from earlier versions of the supported firmware to the latest version of FortiAP and FortiAP-S.

To make it easier to find the correct row for your upgrade, enter the current firmware version running on your device in the Search field. Only rows with the contents of the Search field will be shown.

Supported Upgrade Path to Latest FortiAP Version 5.6

Supported Upgrade Path to Latest FortiAP-S Version 5.4

A comprehensive post of all supported FortiOS versions, build numbers, and their supported upgrade pathways can be found here:

Supported Upgrade Paths – FortiOS

The post Supported Upgrade Paths – FortiAP appeared first on Fortinet Cookbook.

The Fortinet Cookbook site and the Fortinet Documentation site are two excellent sources of information on Fortinet Products and anyone that manages a Fortinet product should have these sites bookmarked in their browser, but there is another site filled with useful information that may be getting overlooked; The Fortinet Knowledge Base found at http://kb.fortinet.com. The site may be fairly basic and utilitarian in layout, but it more than makes up for any perceived lack of polish in the breadth and depth of information that it contains.

Types of content

There are two types of content in the Knowledge Base. They are Product documentation, that is found in the docs site and other product specific webpages, and Knowledge articles that are only found in the Knowledge Base.

Product documentation

It may seem a little redundant to have what could be described as the entire contents of docs.fortinet.com also on this website, but that is not quite what is going on. The documents are only stored in the one location, the Knowledge Base only really keeps links to the documents, that way they don’t have to be updated in both places when changes are make, but the Knowledge Base site is able to search the contents of the documents for specific search strings. On the Docs site you would browse to the title that you were looking for and then open it to search through it.

The downloading of the larger PDF documents may be a little faster on the Docs site because that is where they are located.

Knowledge Articles

Knowledge articles – These are the number 1 reason for visiting this site. These articles are written primarily by either Customer Service people or Technical Support members. Whether it’s the Customer Service people writing about registration, contracts, licensing and the Support Portal or members of the Technical Assistance Center writing about the issues that have arisen out of customer support issues that they have solved there is a very important thing to remember. The people writing this articles are the people with real world experience and practical knowledge on the subjects that they are writing about.

That being said, the second thing you have to remember is that they get all that experience and practical knowledge because they spend most of their day working with the products and systems solving issues. This means that some of the articles my not be as polished and as eloquent as some of the other product documentation, but what were you looking for, elegant prose or a good solid answer to your question?

The topics can range in complexity and difficulty. Some of them will be as simple and straight forward as how to find your system ID or a change that has occurred in the GUI or CLI. Other topics can be highly technical descriptions of what is going on at the code level to explain an aspect of how the device approaches a security concern. Chances are that if you see a Knowledge article on the site it is because it was an issue that came up in a support case. Customers calling in, come in a wide range of  technical levels and so the solutions they require span a wide range as well.

Searching for information

The biggest problem when you have a lot of information to search through is how to zero in on the information that you need. If the search parameter you’re using is fairly unique or if you’re looking for everything on a subject you can use the basic search.

If you want to narrow it down to a specific product, you can click on the “Select” button next to “Products:”  or use the Browse: Products panel at the start of your search to narrow down your search to just those documentation entries that have been tagged as relating to the product you chose. Depending upon the product, you might also want to select the version level of the firmware. 

If what you’re looking for is an even more narrowly targeted piece of information you may want to focus on information contained in Knowledge Articles. These are often more practical and less general in nature. You can filter the search to include only Knowledge article documents by clicking on “Advanced Search and selecting  only ‘Knowledge Article’ as document type.

The ‘Advanced search’ also permits specifying a particular range of publication dates if you only want the most recent.

If you are looking for the results of an exact search phrase, put your search terms in double quotes so that you will get exact matches, for example “system ID on Infrastructure Controllers”

The site’s search engine stops searching after 300 results have been found. If you search result give you the message“Search Results: 1 – 10 of 300 ”, unless there were exactly 300 items that fit the search parameters, your search terms may have been too vague. This means two important things:

1. The most relevant document to your search may not be included in the search results. The search could have stopped before it got to the needed document.
2. Even if there aren’t more documents that would have turned up in your search you still have to go through 300 documents looking for what you want. Try to reword you search to narrow down the search results a little more manageable number to save yourself some effort.

The information migration and evolution

As mentioned earlier, a lot of the information in the Knowledge Articles started off as a response to a support or technical query. The basic premise being that if one person needed that information someone else might as well and documenting it saves replicating the effort of researching the issue the hard way.

The Knowledge Article will probably be a little more fleshed out than the original notes in the trouble ticket because the writer now has more time to organize their thoughts and wants to make it easier to read. This is not necessarily the last stop for this information. Sometimes Knowledge Articles can become the seed or a component of sections of product documentation. As this information migrates from one place to the next, additional details and context gets added to improve the content.

Don’t be surprised if you see something in one of the Administration handbooks that you once looked up in the Knowledge Base.

Version Relevance

There is always some concern with documentation databases made up of individual entries that the information can get out of date and that there may be some difficulty in determining its relevance. There are efforts to take this into account.

You may come across articles that are for versions of the firmware that a lot of people think is well past the “best by: ” date, but not everybody upgrades their devices with the same diligence to having the latest and greatest as others. For whatever reasons, there are some users still running older versions and we want to make sure that they have the information they need as well. Articles don’t get deleted when a firmware version reaches “End of Support”. In fact, the Knowledge Base still has a few articles that were written more than 10 years ago.

The first step in helping determine relevance is to flag an article with the firmware version to which it applied at the time of writing the article. This means that if an article is written for an issue regarding FortiGate 5.0 it gets flagged as being related to FortiGate 5.0. However, this doesn’t necessarily mean that the information has no validity for 5.4. The most frequently accessed articles are reviewed periodically and additional firmware versions added or disclaimers to mention when they are no longer applicable. 

If you’re the sort of person that likes to keep track of such things, there is an article index and RSS feed available on the home page. These are updated weekly and show the articles that have been added or updated.

Article URL’s

Occasionally, you will find that an article will include links to other articles or documents. Some of these URL’s can be a little imposing:

http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&docType=kc&externalId=FD40346&sliceId=1&docTypeID=DT_KCARTICLE_1_1

If you don’t want to copy the entire URL, they can be shortened by cutting just after the document ID

http://kb.fortinet.com/kb/microsites/microsite.do?cmd=displayKC&docType=kc&externalId=FD40346

Feedback

Just like the other documentation teams at Fortinet, the Knowledge Base writers welcome feedback. There’s even a nice “Feedback” button in the upper right-hand corner to use to make sure that it’s as easy as possible. This is the best way if your feedback relates to a specific article. All feedback submissions are anonymous.

The Feedback form contains 4 sections.

1. Star rating system: This allows you to rate an article on a scale of 1 to 5 stars. Not only does this help other readers, because the ratings are displayed on the articles, but it shows the administrators of the site which articles are presenting the information in a way that readers appreciate and which one could use some additional work.
2. Reason for Change:. While, no one will object if the feedback is to tell the author that the article is perfect, there is usually the assumption that there is something you feel could be improved. This section is just to simplify which category of improvement the feedback falls into.
3. Subject:.  Which subject within the article is the feedback about.
4. Comments. Getting a good rating always makes the day seem a little better, but the best feedback is the constructive feedback that can help make the site and the content better. Try to be as specific as possible such as:

• If something is wrong, why is it wrong or what is the correct information?
• If something is missing, what is missing?
• If something is unclear, where did you lose clarity and why?

If your feedback is more general in some way like you have a way to make the site itself better or you want to request someone write an article on a particular topic you can send an email to kb@fortinet.com. This is not the place to submit troubleshooting questions about a technical issue that you may be having (that’s what TAC is for), but a trouble shooting situation can lead to inspiration for a KB article that can be researched and written, potentially helping someone down the line that comes across a similar issue.

 The Knowledge Base is a great resource that is searchable and filled with practical information that has been written by people who work with the products they’re writing about on a daily basis. What we have done, is asked the most experienced people to dump out all of the little bits and pieces of knowledge that they gained in their expertise with Fortinet products and collected it together for the use of other users of the products. There is more information here than is in any one person’s brain. If you have any questions about a Fortinet product it is worth looking here to see is someone has already written down the answer for you.

The post The Fortinet Knowledge Base appeared first on Fortinet Cookbook.

Overview

This modem configuration document is a reference for system engineers who need help configuring USB modems with the FortiGate. It will also provide specific examples to help you custom configure an unsupported USB modem. There is a lot of confusion on this subject since the configuration of each USB modem varies greatly, and this guide will walk you through modem concepts, troubleshooting tips, and further steps.

The following concepts will be covered:

• How these commands really work: config system modem, config system 3g-modem custom, and config system lte-modem.
• Modem modeswitch
• The differences between modem and lte-modem
• Standard procedures for deploying new modems on the FortiGate
• Troubleshooting tips

This document will help you classify all modem related issues and make sure that when you escalate to the development team that you have something only they are able to resolve.

Note: A USB modem doesn’t only mean the USB sticks plugged into the USB port on FortiGates. Some newer FortiGate models, like the 30E-3G4G/ 60E-3G4G, include a built-in modem module installed on an internal USB port, and they are also considered USB modems.

The information in this article is based on Julian Zhong’s “A Guide for Modem Configuration On FortiGate” based on commonly asked questions about modem configuration.

Modem, 3G Modem and LTE Modem

There are three modes that look like they are related to USB modem configuration, but in actual fact these modes — Modem, 3G Modem and LTE Modem — are often not understood correctly.

Misconceptions about the terms

There are several misconceptions surrounding these three modes: Modem, 3G-Modem, and LTE-Modem. Modem appears to be configuration for all USB modems, but it is not. Similarly, 3g-modem is not limited to 3G modems. LTE-modem can also connect to a 3G network. Although these commands may cause some confusion, they are legacy terms in FortiOS, and by defining them clearly, there’s no need to change the terms. 

It’s important to understand what’s going on inside a USB modem. There are two parts of hardware: front-end and back-end. The front-end runs UMTS, HRPD, LTE or similar languages. The backend runs PPP or an Ethernet-like protocol to talk to the host. During the 3G modem era, the mainstream technology used in the backend was PPP protocol.  Later 4G and LTE technology came into play and modem companies added LTE capable hardware in the front-end, but often the newer LTE modems still inherited the same PPP backend.

Now LTE has dominated the wireless network, a PPP backend for the modems has become a bottleneck. It is not efficient enough and it’s not sophisticated either. Some USB communication specs similar to Ethernet that have been developed in recent years, like EEM, ECM, NCM, MBIM are mostly paired with LTE technology to make the current generation of LTE modems.

Config System Modem

In fact, the mode system modem should be called PPP modem to be more accurate, as it has nothing to do with 3G or LTE.

Config system lte-modem

Configurations under this mode are sent to modems with Ethernet-like backend interfaces. Sometimes we will need the 3g-modem settings to do modeswitch for us. 

Preliminary Knowledge

USB Modems

Wireless modems up until now have mostly been USB modems, but why USB modems? Because wireless modems are complex, and they are not born as part of the standard computer hardware. The USB interface is simple, powerful, and flexible. It has been a standard PC interface for so long that when we pair a wireless modem with a USB interface, it becomes a peripheral which can be easily used on all PCs with a USB interface. Besides this, many communication protocols based on CDC 1.2 (Communication Device class) have been developed, which provide industrial standards for wireless communication devices, which is why we only need to talk about USB modems here.

Modem Ports

Almost all the USB modems have a modem port. As we’ve observed, only some of the CDC Ethernet or rndis_host modems don’t have it. To identify a modem port, send an AT command ati, which all the modem ports support, to it. If it echoes back the modem information, then you know it’s a modem port.

Mode Switch

The most popular PC operating system is Windows, and in order for a USB modem to work on a Windows PC, the device driver and modem utilities have to be installed first. Since some of the modem users might not have a preexisting Internet connection (otherwise why would they want a USB modem?), and they might not be able to download the drivers and utilities. This renders the USB modems useless. Luckily, mode switch provided a solution to this problem. It is implemented on many USB modems, but not all.

When a USB modem with mode switch implemented is plugged into a PC’s USB port, it appears to be a USB storage device first, the device driver and modem utilities can be installed from the storage device. After installation, when we run the modem utility, it first sends USB messages to the modem, which causes the storage device to switch into a USB modem device, and the switch is called mode switch. Different modems have different mode switch messages, and it is impossible to have all the mode switch messages stored in a FortiOS image, so if the mode switch message can’t be found, you can manually configure it using the config system 3g-modem custom command. You can also find a configuration example later on in the Configuring Mode Switching section.

Modem Protocols

For PPP modems, standard PPP is the way to go, and we won’t be expanding on this topic here.

For modems using Ethernet-like protocols, FortiOS now supports the following:

• CDCEther
• cdc_ether
  • They are in fact the same, in our kernal 2.4 products the driver’s name is CDCEther, in kernal 3.2 products it is cdc_ether.
• sierra_net
  • Drivers for some of the older Sierra wireless models, like 313U, 320U and etc. They were all sold to Netgear later, and almost all the Netgear branded modems run the sierra_net driver.
• cdc_ncm
• huawei_cdc_ncm
  • NCM protocol is widely adopted by Huawei modems, and some modems from other vendors might also run the cdc_ncm protocol. huawei_cdc_ncm is a customized NCM protocol by Huawei, and we only support it in kernel 3.2 products.
• GobiNet
• GobiNet driver is a Qualcomm protocol, for now and I have only met with Netgear (Sierra Wireless) 341U modem, which uses this protocol.
• qmi_wwan
  • This is a mature and widely used protocol on the current market, as the main stream qualcomm wireless chips are quipped with software stack for this protocol.
• rndis_host
  • This is a protocol similar as cdc_ether, and it is supported in the 5.4.4, the 5.6 beta and the 5.8 releases support rndis_host devices on both kernel 2.4 and kernel 3.2 products.

Single Instance

If we are running modems with the protocol listed in the previous section, keep in mind that we only support a single instance of these modems. It is limited by the software, and this may be improved upon in the future.

We can still have multiple USB modems running at the same time, as long as only one modem running the protocols is present, and the other modems are PPP modems.

Configuring a USB Modem

Check Devfs

USB devfs are disabled by default in the latest Linux kernel releases, and instead the information is put into sysfs. At least it is a compact form of USB device.

From the output, we can see there’s a Sierra Wireless EM7355 modem on Bus 4, under the root hub, the device number is 5, and it is on the USB 3.0 bus but running at USB 2.0 speed.

There are some important parameters we need to pay attention to:

After checking devfs, we find out that we have a Sierra Wireless EM7355 modem attached to our device, and it seems our kernel fully understands how this modem works.

Now on to another example:

After we insert a Dlink DWR-910 modem into the same device, we found an additional USB descriptor. The vendor ID is 0x2001, the Product ID is 0xa40d, it shows up as a storage device. As we have mentioned in the previous chapter, it seems to be a device which needs a mode switch, we will now show you how we can do a mode switch.

Configuring Mode Switching

What does mode switch do?

Now that we’ve found a USB modem that shows up in the system as a storage device, we need to do a mode switch to turn it into a USB modem. There’s a famous website that lists all the mode switch utilities and all current popular Linux releases are from the website: www.drasberghof.de/usb_modeswitch/. If you want to dig deeper on this topic it’s definitely worth spending some time on this site.

A handy way to find out how to mode switch a modem is to install the usb_modeswitch utility from the website on your LInux PC, and try it first. I won’t go into the full details of how to do this in this article, but here’s a brief screenshot of how to find the message you’ll need to send into the modem to get it to mode switch.

Note: Fedora 20 and mode switch v 2.4 were used in this example.

The database of the mode switch messages can be found here:

The two parts of hex strings are the Vendor ID and Product ID of the USB storage devices. Let’s look at an example:

It is a Huawei modem, the original Product ID is 1031, after the switch it should become 1035, and the USB message we should send to the modem is the value of “MessageContent”, which is a long hex string.

For the Dlink-DWR-910 modem, we get a slightly different response:

We should get a a final Product ID of 7e38, but it is asking us to perform a “standard eject” instead of giving us a string (like in the previous example). Now we’ll look at the source code of usb_modeswitch. We’ll leave out the procedures, but just provide the result below. A standard eject equals to send two messages into the modem, and these messages are: 

• 5553424312345678000000000001061e000000000000000000000000000000
• 5553424312345679000000000001061b000000020000000000000000000000

Now, it is time to switch this modem on our device.

Mode Switch a Modem in FortiOS

Mode Switch is done in mode system 3g-modem custom. For example:

One thing it’s important to remember is that you need to either enable the modem daemon or LTE modem daemon to make the mode switch work. You need to enter the following:

Or enter:

After the mode switch we’ll find a new USB device:

Now the DWR-910 modem is switched into a device running the rndis_host driver. Furthermore, we can see this device has two configurations, the first is an rndis_host device, and the second configuration is not active, thus the interfaces are not identified by the Linux kernel. An advanced USB developer can identify that it’s a cdc_ether device, because the interface 0 of configuration 2 has class=2, subclass=6, and protocol=0, also the interface 1 has class=a, subclass=0 and protocol=0.

Does Our Kernel Fully Recognize the Modem?

Before doing anything else, we need to confirm that our kernel knows what kind of device it is dealing with, otherwise it is impossible to make the modem work. Let’s take a look at a few different modems that we have on hand as samples.

Dlink DWR-910

As we can see the active configuration has two interfaces forming a rndis_host interface union. (We won’t be expanding on this here, as you can easily find more resources online about rndis_host).

Sierra Wireless EM7355

As you’ve seen in previous configurations, the EM7355 has has 3 qcserial interfaces as serial ports, and a qmi_wwan interface. We believe our kernel knows this modem, too.

ZTE MF823

After applying the same mode switch settings, the modem switches to from an unknown storage device, to a cdc_ether device.

Sierra Wireless 340U

Take a good look at the interface driver sierra, a proprietary serial protocol by Sierra Wireless:

Notice that this device doesn’t have any Ethernet-like interfaces, like we’ve talked about in earlier sections. It’s a PPP modem, and so we should set the modem configuration in mode system modem but not system lte-modem.

The modem port is /dev/ttyusb1, and in modem configuration we should set the wireless port to 2, because the modem daemon counts from 1, port 1 means ttyusb0. In mode system lte-modem if we want to set the modem port, we set the port index to 1, because we count from 0.

Sierra Wireless 313U

Take a look at the Sierra Wireless 313U below.

The first 5 interfaces are identified as serial interfaces which use the sierra driver, the last interface is a sierra_net interface, and it is an Ethernet-like interface, supported by our LTE daemon.

Novatel U551L

Now let’s take a look at the Novatel U551L:

It is a cdc_ether device, the last two interfaces form a cdc_ether union, and it is supported by our LTE daemon too. The first 4 interfaces are identified as serial ports which use the option driver.

Identify the Modem Port

After we make sure that our kernel supports our USB modem, the next thing to do is to find out whether this modem has a modem port, or what the index of the modem port is.

The easiest and most reliable way to find out the modem port is to use the command: diagnose sys modem com /dev/ttyusbX.

Unlike the official Linux kernel, we don’t name the USB serial ports /dev/ttyUSBX, instead we use all lowercase. It should look like the example below:

It’s clear that the modem port here is /dev/ttyusb1.

Now, if you find out that the modem you are trying to deploy is a PPP modem, then just stop reading here, and go find an older modem configuration manual for help. If the modem is not a PPP modem then continue to follow the instructions below.

Is the LTE Modem Interface identified?

An easy way to test this is to use ifconfig.

Before checking this, you need to remove configurations in mode “system modem”, and if you are aware that we entered those lines hoping to make this particular modem work, then you need to enable the LTE modem daemon, as well.

On a modem with an internal LTE modem module, it doesn’t show this line because enable is the default value.

Now it’s time to run ifconfig. 

You can modify the Linux kernel source code, to rename the non-PPP modem network interface to wwan, and in old FortiOS versions, usb-wan. You’ll only allow one interface like this for now, and if you plug two non-PPP modems into one FortiGate at the same time, we don’t guarantee what happens.

From the screenshot, we can see the interface exists, and it seems to be working properly, although it hasn’t received an IP address yet because we don’t have a SIM card in it.

Further Debugging

Now enter get system interface to check if you can get an IP on the LTE modem interface:

If your result is similar to the image above, and you aren’t having any luck in getting an IP address try the following:

1. Make sure your device has a modem port
2. Enter the following commands:

3. Next, set debug mask to 31, which enables debug levels 0, 1, 2, 4, 8, 16.

4. Enter diagnose test application lted 1 to check the modem info.

If you see the error message “failed to read_modem_device” then the modem port may not be set correctly. It’s possible that you might have other USB devices plugged into the USB port, and there’s also a USB serial port on the external USB devices, which disrupts the default USB serial port order. This may cause the modem to fail.

Check the LTE modem configuration again, to see if the FortiGate is now using the new modem port that you switched it to, Port 3, instead of the default Port 0. 

Change it back and you should see the result below:

Now the modem port is working, as you can see below:

It’s still not connected, so what can we do?

First, you can run these diagnose tests:

Oh, we get a “SIM ERROR” and that means we should check the SIM card slot to make sure a SIM card is plugged in.

Still not working?

If you have reached this far, and it still doesn’t work, please open up a Mantis for help.

List of the Current Supported LTE Modems

Resources

You may be interested in checking out the following resources:

• Viewing the FortiGate or FortiExtender Supported List
• FortiOS Modem Chapter
• FortiOS FortiExtender Chapter

The post Configuring Modems on the FortiGate appeared first on Fortinet Cookbook.

This collection of related recipes shows how to configure a Security Fabric throughout your network, using a range of Fortinet products. This security fabric will link different security sensors and tools together to collect, coordinate, and respond to malicious behavior anywhere it occurs on your network in real time.

Below, you will find links to a number of Cookbook recipes. By using these recipes in the listed order, you can create a network similar to the one shown above.

This collection is a work-in-progress. Check back to see what new recipes have been added.

Between most steps are screenshots showing the FortiView Topology dashboards, which can be seen in the video above. These dashboards display the devices that make up your cooperative security fabric. The Physical Topology dashboard shows all access layer devices, while the Logical Topology dashboard displays information about the interface (logical or physical) that each device is connected to.

This collection is supported for the following Fortinet firmware:

• FortiOS 5.6.0+
• FortiAnalyzer 5.6.0+
• FortiSandbox 2.4.0+

1. Installing a FortiGate in NAT/Route mode

In this recipe, you install the initial FortiGate, which will later be used as the root FortiGate (also known as the upstream FortiGate) in the security fabric.

Because the Security Fabric has not yet been enabled, the FortiView topology dashboards are not yet available.

2. Security Fabric installation

In this recipe, three additional FortiGates are added to the network as Internal Segmentation Firewalls (ISFWs). A FortiAnalyzer is also added to the network to collect and view logs. Once the devices are installed, a security fabric is set up between them and the root FortiGate which was installed in the network previously.

In the example network, the Internet-facing FortiGate is called External, with three additional FortiGates, called Accounting, Marketing, and Sales. The FortiGates all appear in the FortiView topology on the External FortiGate, along with the FortiAnalyzer.

Physical topology:

Logical topology:

3. FortiSandbox in the Security Fabric

In this recipe, a FortiSandbox is added to the Security Fabric, so that any suspicious files discovered by the FortiGates can be be scanned and tested in isolation from the rest of the network.

The FortiSandbox now appears in the FortiView topology.

Physical topology:

Logical topology:

The post Security Fabric appeared first on Fortinet Cookbook.

In this recipe, you’ll learn how to create a basic transparent web proxy setup. You can use the transparent proxy to apply web authentication to HTTP traffic accepted by a firewall policy.

In previous versions of FortiOS, web authentication required using the Explicit Proxy. Now in addition to the Explicit Web Proxy, FortiOS now supports a Transparent Web Proxy. With the transparent web proxy, you can forward your use’s web traffic to the proxy without requiring your users to reconfigure their browsers or without needing to publish a proxy auto-configuration (PAC) file.

Note: This is just a basic setup, and authentication will be covered in a future recipe.

1. Configuring System and Network settings
Go to System > Settings, scroll to Operations Settings and set the inspection mode to Proxy.
Go to System > Feature Select and enable Explicit Proxy.
Go to Network > Explicit Proxy and enable Explicit Web Proxy. You can also change the HTTP port that the proxy listens on (default is 8080) or specify different ports for HTTPS, FTP, PAC, and other options.
2. Adding Proxy Options to your policy
Go to Security Profiles > Proxy Options. Create or edit a proxy options profile. Under Web Options, enable HTTP Policy Redirect.
Go to Policy & Objects > IPv4 Policy and create or edit a policy controlling the traffic that you want to apply authentication to. Select a security profile (in the example, AntiVirus) and then enable the Proxy Options edited in the previous step and enable SSL/SSH inspection.
3. Creating a Proxy Policy
Go to Policy & Objects > Proxy Policy and create a transparent policy to accept the traffic that you want to apply authentication to. Set the Proxy Type to Transparent Web. The Incoming Interface, Outgoing Interface, Destination Address, and Schedule should either match or be a subset of the source addresses defined in the IPv4 policy. Addresses added to the Source must match or be a subset of the source addresses added to the IPv4 policy. You can also add the users to be authenticated by the transparent policy to the Source Field.
4. Results
Open a browser and generate traffic for a few minutes. Then go to FortiView > Policies.
Right-click on a row in the table to drill down for details.  You will see that traffic is flowing through the proxy policy.
Traffic is flowing through the IPv4 policy configured with the proxy security profile.

For more information, read about Transparent Web Proxy in What’s New for FortiOS 5.6.

The post Transparent Web Proxy appeared first on Fortinet Cookbook.

We are going to explore how to use a single IP address to provide connectivity to multiple servers. Before we get into the how, aside from it just being kind of cool to be able to do it,  it is useful to understand why. This is one of those topics that can require a little context and background before it makes complete sense as to why we’re doing what we’re doing.  If you’ve been involved in networking for a while, you may already have this background and a lot of this could be redundant.

In order for all of this to make sense, you have to know about the following things:

1. The reason why you need to have a small number of public IP addresses be the connection point for multiple servers.
2. There is more to an Internet address than the IP address.
3. NAT (Network Address Translation) works both ways through a networking device.

The irony is that larger enterprises that have people experienced and knowledgeable on the ins and outs of networking are probably more likely to have more public IP addresses to work with. It’s the small and medium sized organizations that only have one or two IP addresses that need this information and they are the ones that may not have a full time networking person that already knows all of this stuff. So, if you’re already up to speed on the basics, please bear with me. I’ll even try to throw in a tidbit or two that you might not already know.

The Numbers Game

IPv6 is not yet in mainstream use, so Public IP addresses are still a resource that is in short supply as compared to the demand. If you’re unsure as to why IPv6 would increase the amount of IP addresses, imagine an addressing system that would allow every bacteria on the planet to have it’s own IP address with plenty to spare. In 1991 there was 1 website; it’s address was http://info.cern.ch. It’s still up if you want to take a look. The number of websites has grown phenomenally since then.

The actual number is in a constant state of flux, as some come online, others are removed and some are just plain inactive, so it is hard to get an exact number at any given point in time. One estimate puts the number of websites on the Internet at over 1 billion. If you’re curious, you can go to http://www.internetlivestats.com/total-number-of-websites/ and see the number scrolling up at a rather rapid rate. By time I typed out the number it would be out of date.

Theoretical numbers

Now, some of you IPv4 aficionados, or people that are just really good at calculating in binary, have probably figured out that 1 billion is not as much as 4,294,976,296 which is 2 to the power of 32 and the number of possible IPv4 addresses. This is the theoretical upper limit to the number of possible usable addresses.

Practical numbers

The practical number is reduced by a number of factors:

• Every time a block of IP addresses is separated into a subnet the addresses on each end of the subnet are lost as usable IP addresses, one for the subnet address and one for the subnet broadcast address.
• Because of the way subnetting is done, IP addresses are assigned in blocks of specific sizes not by how many a user needs. These blocks of usable IP addresses are:
  • 2
  • 6
  • 14
  • 30
  • 62
  • 126
  • 254
  • on going in a pattern of 2x +2 until you reach 16777214

  So if a user needs 32 addresses, they have to take 62 addresses, which means they can’t be used by someone else.

• When the Internet was first set up there were 5 classes of addresses; A,B,C,D,E. Many are aware of the A, B, and C classes of addresses but forget about the D and E classes.
  • D class has 268,435,456 addresses from 224.0.0.0 to 239.255.255.255 and is set aside for multicast addressing.
  • E class has 268,435,456 addresses from 240.0.0.0 to 255.255.255.255 and is reserved for research and classified use. Remember, the Internet started out as ARPANET, which was part of the military.
• The ‘over 1 billion’ value mentioned earlier, is based on the number of unique host names that can be resolved. This means there are DNS entries for them. This does not take into account IP addresses that are in use, but don’t use Fully Qualified Domain Names.

Not as many as we thought

This is all a rather verbose way of explaining that there aren’t as many available IP addresses in reality as there are in theory, and that in order to keep up with the number of websites that are being created, we sometimes have to get those IP addresses to perform multiple tasks at once. 

Sometimes, there is also the even simpler reason that some organizations or people don’t want to spend the extra money to get addition IP addresses, but seeing as the price of something is often related to it supply, we’ll allow that there is a connection between the two reasons.

Connecting is more than the IP address

Now that we can see the challenge, we can approach the solution. The trick is configure a single IP address to serve as the address for multiple servers. The first thing that allows us to perform this seemingly counter-intuitive task is that more than the IP address is used when connecting to a website.

The analogy would that when we mail a letter and use the street number, street name, city, state or province and country, and it gets to the destination that we intend, but we still put a person’s name on the envelope to make sure it gets to the correct person with the building. The analogy doesn’t hold up with how we are going to take advantage of it, but it helps with the idea of how things were originally intended to work.

The protocol is part of the address

When most people hear about websites they immediately think of a webpage with text and pictures on it. This could be a big site like Wikipedia or something smaller like a personal blog. But both of these sites use the HTTP or HTTPS protocol to reach the content. There are other sites types as well that use different protocols. FTP sites will use the FTP protocol. Mail servers will use the POP3, IMAP4 and SMTP protocols as well as a few others. There is also DNS, NNTP, NTP, SSH, Telnet, Kerberos and hundreds of others. Each of these different protocols is sent to a TCP/IP port on the server that is listening for communications using those protocols. To make life as consistent and therefore as simpler as possible, there are standard ports for systems listen on for most of these protocols. To make life even simpler, a number of these port numbers are assumed to be used by the client software that is made for them.

Some standard ports are:

In a browser’s address field, the proper way to address a web site is to have the protocol, followed by a colon and 2 slashes, the address (IP or FQDN), followed by a colon and the port number. So the proper addressing for the website example.com would be:

http://example.com:80

Most current browsers, unless told otherwise, assume that an address in the address field is HTTP and unless told differently, that it should connect to port 80 at the destination server.

But it doesn’t have to be that way. You can actually assign any port number to the address, regardless of which protocol is being used. Instead of 80 for HTTP, you could assign 8080; any of the TCP or UDP port numbers from 1 to 65,536. The trick is that you can only make a successful connection if the device at the other end of the connection is listening for that protocol on that port. If you want to use the address http://172.12.1.25:8080 to connect to a web page, you can, but the server at 172.12.1.25 has to be using port 8080 to listen for incoming HTTP traffic. This is why the ports from 1 to 1024 are standardized as well-known ports for some of the more commonly used protocols. If this standardization wasn’t in place you would have to know which port was being used for each website you visited. These standardized ports are commonly used but it is not a requirement of the protocol so we can use this feature of addressing in combination with NATing to accomplish our goal of using a single IP address for multiple servers.

NATing works both ways

Many people are aware that they can have multiple computers in their home or business that can all use the Internet. They may not know how Network Address Translation works or even that it’s the name for the function that allows this to occur but they are aware of the multiple systems through one address concept. This multiple to one concept uses TCP and UDP ports to keep track of and differentiate between the devices connecting to the Internet. The Translation aspect of the function means that communications from a specific address and specific port can be directed or redirected to a specific address and specific port. These ports and addresses can even be changed or translated so that something coming in on address/port A can be redirected to address/port B.

The second important aspect of NATing for our purposes is that the management of the translation is not limited to one attribute of the address;instead, it is based on a combination of them. 172.12.1.25:8080 is treated independently from 172.12.1.25:8081. 

NATing is a fundamental aspect of networking and entire books have been written on the subject. To find out more about how NATing works on a FortiGate, you can check out the FortiOS Firewall Handbook.

Making IP addresses do Multiple duty

Now that we’ve covered the basic concepts, we are going to put them together with the mechanics of FortiOS configuration to make it work. To make it a little less abstract, I’m going to present a fairly straightforward scenario and then we are going to go over the configuration steps to make it work. 

A few caveats. 

1. Most firewalls have similar capabilities, and work on similar principles, but there are differences in configuration and terminology. 
2. With a very few exceptions for specialty or niche models, all FortiGate devices and FortiOS versions are able to perform this function, however, this post is not intended to be version specific. There may be some slight differences in terms of configuration between versions and any screenshot or instructions may differ slightly from your version but these should be minor and the principles should hold across versions. 
3. What follows was not written in the standard Fortinet Cookbook recipe format found on the site. For this topic I wanted to go a bit beyond the straightforward step by step instructions and add more understanding as to the “why” of something being done and some of the possible options.

To  demonstrate that there are differences between Fortinet and some other companies, at least in terms of terminology, I will point out that the basic feature that we use to do this is called a Virtual IP address or VIP. Some companies refer to this feature as Port Forwarding, while we consider port forwarding as a setting within a VIP.

The scenario

There is a small organization that has:

• 1 web server for public use running HTTP and HTTPS.
• 1 web server for use by employees and select clients using only HTTPS.
• 1 mail server running SMTP and IMAP4.
• 1 Linux server used by the System Administrator to remotely run commands to manage the Internal Network.
• A single Static Public IP address assigned to them by their ISP.

Setting up the VIPs

The location of the configuration window for new Virtual IPs can change from version to version but the one that I’m using has it located at: Policy & Objects > Virtual IPs. To create a new VIP click on the Create New button in the menu bar at the top. You should get a drop down menu that allows you to choose to create either a new Virtual IP or Virtual IP Group.

The first VIP will be for the Public Web Server for the HTTP Traffic. This can be used as a template for the rest.

The configuration settings will be as follows:

• VIP type: IPv4
• Name: Web Server 1 – HTTP
  • You can choose whatever name you want but it helps if it intuitively descriptive.
  • Invalid characters are < > ( ) # ' "
• Interface: WAN1
  • The two options are the specific interface that the incoming traffic will connect to, such as WAN1 or the general purpose any interface. The WAN1 interface is more intuitive, and by using it the VIP will not appear as an option when configuring policies that are associated with other interfaces, but the any option can make configuration simpler if you intend to use hair-pinning to access the web server from the internal network. We won’t be discussing hair-pinning is this post so we’re going to go with the WAN1 option. Information on hair-pinning can be found at: 
• External IP Address/Range   172.12.1.25 – 172.12.1.25
  • These fields are for the incoming IP address. In this case, 172.12.1.25. It is possible when creating a VIP to have it apply to a range of IP addresses, explaining why there is a field for the first address in the range and a field for the last address in the range, but because the point of this scenario is to use just one IP address, that address gets entered in both fields.
• Mapped IP Address/Range: 192.168.1.50
  • This is the address that the traffic is being directed to. The IP address of the internal server in this case is 192.168.1.50.
  • The second field in the line is grayed out. This is because the range is calculated based on what was entered for the External IP Address/Range. 
• Port Forwarding:  turned on
  • If this is not turned on, the following options are not available
  • The other effect of not turning Port Forwarding on is that all ports are redirected to the Mapped IP Address/Range. That sort of defeats the objective of getting one external IP address to connect to multiple internal servers.
• Protocol: TCP
  • HTTP is a TCP protocol as are all of the others that we are using in this scenario.
• External Service Port:  80
  • Because this is for the public web server we don’t want to have them know which specific port to map to so we are going to use the standard one.
• Map to Port: 80
  • When ever possible, the servers should be left at the standard listening port. Even if the client software is configured to send to port 8080 because another server is already using 80, the FortiGate can map that 8080 to 80 easier than the server can be changed to listen on 8080 instead of 80. Besides, if the network configuration changes you would have to remember which services are mapped to which ports on which servers.

Once we click on the OK button the first VIP is created and we can see it in the VIP listing.

Depending on the complexity of the of a given scenario and how comfortable you are with VIPs and port forwarding you may or may not want to draw out a plan. 

You don’t need a computer to draw out the diagram like the one below. A scrap piece of paper or a white board will do, but it helps to be able to visualize what the end result should be. It also gives you a checklist of sorts so that you don’t forget any of the VIPs that you need to create.

As you can see from the diagram, we need to create 6 VIPs in total and the mappings are nicely laid our for use.  You will probably notice a few things from the diagram.

• There are 6 different VIPs but only 4 different internal servers.
  • I wanted to make sure that it was understood that the number of address & port combinations was what determined the number of VIPs needed not the number of internal servers.
• All of the VIPs are coming in on a single interface and leaving on a single interface.
  • This isn’t important for the creation of the VIPs but it comes into play in the creation of VIP groups, which we will discuss once we’ve finished creating all of the VIPs.
• We’ve used HTTPS(443) and SSH(22) which are secure protocols but we have used SMTP(25) and IMAP(143) for the mail server instead of the secure versions of the protocols.
  • The HTTP and HTTPS are there to confirm that two different VIPs can point at the same web server site.
  • The second HTTPS is there because I wanted a duplicate of an already used protocol and I didn’t think you would find a web server for employees and selected customers that wasn’t using HTTPS believable.
  • For the mail server, I was primarily concerned with the demonstration of the concepts rather than on showing how to secure the services, and the use of the secure versions can sometimes require configuration settings that are beyond the scope of this post.
• Even though there is no duplicate use of the SSH port, the incoming port is not the standard one.
  • I wanted to demonstrate that if you feel so inclined, you can change things up even if there isn’t a resource requirement to do so. The Sysadmin should be the only one using the SSH VIP so no customers will be inconvenienced. Security through obscurity is not a good level of protection, but that doesn’t mean we have to make it easier than we have to for malicious actors running scans against our network.

Differences in the pattern

I will not show the configurations of each of the next 5 VIPs because they tend to follow the pattern set in the first one however I will point out the differences in the pattern. 

Web Server 2 – HTTPS 

• The External Service Port number is 4443 instead of the usual 443. The Map to Port is still 443. To make it easier to remember, it simplest to just add a number to the standard number.
• The Mapped IP Address/Range is 192.168.1.51

Mail Server (both VIPs)

• The Mapped IP Address/Range is 192.168.1.52

Linux Server – SSH

• The External Service Port number is 5622 instead of the usual 22. The Map to Port is still 22.
• The Mapped IP Address/Range is 192.168.1.53

Now we should have 6 VIPs in the list:

Using VIP groups for ease of management

Before we start adding the VIPs to policies it can be useful to arrange them in a group or groups depending on how we want to treat the traffic. There are a few possible ways to do it.

• By internal server:
  • Web Server 1 Group: Web Server 1 – HTTP & Web Server 1 – HTTPS
  • Mail Server:Mail Server – SMTP & Mail Server – IMAP4
  • The rest left as individual VIPs
• By type of servers:
  • Web Server Group: 
    • Web Server 1 – HTTP, Web Server 1 – HTTPS & Web Server 2 – HTTPS
  • Mail Server:
    • Mail Server – SMTP & Mail Server – IMAP4
  • Linux Server – SSH left as an individual VIP
• All of the VIPs in one group

Because all six of them have the same Incoming Interface and Outgoing Interface, you can arrange these 6 VIPs any way you want that will make it easy for you to add to the policy or policies that you want. For simplicity’s sake, in this case we are going to assume that the scanning can be the same for all of the traffic and put them all in one group.

Go to Policy & Objects > Virtual IPs. When you use the Create New button in the menu bar at the top, select Virtual IP Group.

Clicking on the OK button creates the group and it is now visible along with the VIPs. 

The VIPs have been created that provide the functionality that we want and the group has been created to ease administration. Now all we need to do is implement them into action.

The next step is to add the VIPs, or in this case the VIP group to a policy.

Go to Policy & Objects > IPv4 Policy and select Create New.

When creating the configuration for the new policy the settings should be:

• Incoming Interface: WAN1
• Outgoing Interface: DMZ
• Source: all
• Destination: Internal Servers Group
  • This is the VIP group that we created. We could have added each of the VIPs individually, but adding just the single group is simpler.
• Schedule: always
• Service: HTTP, HTTPS, IMAP, SMTP, and SSH
  • The VIP consists of only these 5 protocols. We could have selected all as the service and still only these 5 protocols would have been allowed through the policy, but configuring the policy only for these 5 saves CPU cycles by not processing other traffic before it is blocked by the destination setting.
• Action: ACCEPT
• NAT: turned on
  • The NAT feature is what makes the splitting of the traffic possible so it must be enabled.
• Security Profiles: Which ever are appropriate for the traffic according to your IT policies.

Traffic for 4 different internal servers is now being managed through a single IP address. Not only is it an efficient use of resources, you just have to admire the technology that enables it to take place. 

The post One IP address serving multiple servers appeared first on Fortinet Cookbook.