We are going to explore how to use a single IP address to provide connectivity to multiple servers. Before we get into the how,  it is useful to understand why, aside from it just being kind of cool to be able to do it. 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. 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.

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.

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
  • ongoing in a pattern of 2(previous number in pattern) +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, 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 additional IP addresses, but seeing as the price of something is often related to its 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 to 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.

Consider the analogy that when we mail a letter and use the street number, street name, city, state or province and country, it gets to the intended destination, but we still put a person’s name on the envelope to make sure it gets to the correct person. 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 web page with text and pictures on it. This could be a big site like Wikipedia or something smaller like a personal blog. Nonetheless, both these sites use the HTTP or HTTPS protocol to reach the content. There are other site 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 are also DNS, NNTP, NTP, SSH, Telnet, Kerberos and hundreds of other protocols. Each of these different protocols is sent to a TCP/IP port on the server that is listening for communications using those protocols. In an effort to make things consistent and simplified, there are standard ports for systems to listen on for the traffic of 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 website 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. However, 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 along with 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: http://cookbook.fortinet.com/hair-pinning/
• 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: Whichever 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.

If in FortiOS 5.0, 5.2, and 5.4, there are several AntiVirus (AV) scanning inspection modes available. FortiOS 5.0 includes proxy and flow-based virus scanning. FortiOS 5.2 also uses proxy-based and flow-based scanning, but the flow-based mode in FortiOS 5.2 uses a new approach to flow-based scanning (that is sometimes called deepflow or deep flow scanning). FortiOS 5.4 adds another flow-based mode, quick mode, to inspect traffic efficiently.

AV Scanning 101

AntiVirus scanning examines files in HTTP, HTTPS, email, and FTP traffic for threats as they pass through your FortiGate unit. If the AV scanner finds a threat such as a virus or some other malware, FortiOS protects your network by blocking the file.

FortiOS includes a number of AntiVirus features that make virus scanning more user-friendly. One of these features, called replacement messages, sends a customizable message to anyone whose file is blocked by AV scanning, to explain what happened and why. Other features make communication between the client and the server more seamless. The availability of these changes depending on the inspection mode.

Proxy-based AV scanning

Proxy-based AV scanning is the more feature-rich AV scanning mode.  This mode uses a proxy to manage the communication between client and server. The proxy extracts content packets from the data stream as they arrive and buffers the content until the complete file is assembled. Once the file is whole, the AV scanner examines the file for threats. If no threats are found, the file is sent to its destination. If a threat is found, the file is blocked.

Because proxy-based scanning is applied to complete files it provides very effective threat detection. Proxy-based scanning also supports the a full range of features, including replacement messages and client comforting, making proxy-based scanning the most user-friendly inspection mode. In addition the proxy manages the communication between the client and the server, so communication is cleaner.

Proxy-based scanning inspects all files under the oversized threshold. This threshold is 10 MB by default but can be reconfigured. Any files larger than the threshold are considered oversized and not inspected. 

Flow-based AV scanning

Although the name “flow-based scanning” is used in both FortiOS 5.0 and 5.2, the two different versions handle this mode in very different ways.

Flow AV in FortiOS 5.0

In FortiOS 5.0, flow-based AV scanning scans the content of individual data packets as they pass through the FortiGate. There is no proxy involved so packets are not changed by the proxy and files are not buffered for analysis. Potentially less memory and CPU resources are used, resulting in a potential performance increase compared to using proxy-based mode. FortiOS 5.0 flow-based AV scanning is also not limited by file size.

Flow AV uses the IPS engine and the AV database and is effective at many kinds of threat detection; however, because it can only analyze what is in an individual packet rather than a complete file, flow-based scanning cannot detect some types of malware, including polymorphic code. Malware in documents, compressed files, and some archives are also less likely to be detected.

Flow AV does not actually block files, it stops delivering the rest of the file once a threat has been detected. This means that parts of the file may already have been delivered when the threat has been detected and the recipient application is responsible for dealing with the partially complete content.

In addition flow AV can be less user-friendly. Replacement messages are not supported and clients may have to wait for sessions to time out without knowing why content has been blocked.

Flow AV in FortiOS 5.2 (deepflow or deep flow)

FortiOS 5.2 introduced a new type of flow-based AV scanning, that is sometimes called deepflow or deep flow, and that takes a hybrid approach where content packets are buffered while simultaneously being sent to their destination. When all of the files packets have been collected and buffered, but before the final packet is delivered, the buffered file is scanned. If a threat is found, the last packet is blocked and the client application has to deal with not getting the completed file. If no threat is found the final packet is sent and the user gets their file.

Deepflow AV scanning is as good as proxy-based AV scanning at detecting threats. There may be a small performance advantage over proxy-based AV as files get larger based on the difference between sending the whole file after analysis and just sending the last packet.  Deepflow’s most notable limitation is that, just like the flow-based AV in 5.0, it does not support many of the user-friendly features provided by proxy-based AV.

Flow AV in FortiOS 5.4 and later

In FortiOS 5.4 and later, there are two modes available for flow-based inspection: full and quick. Full mode is the same as flow-based scanning in FortiOS 5.2. Quick mode uses a compact antivirus database and advanced techniques to improve performance.

The post FortiOS AntiVirus inspection modes appeared first on Fortinet Cookbook.

Avoiding certificate errors when SSL inspection is applied to traffic is an in-demand topic. There are a number of methods that you can use to prevent these warnings: installing self-signed certificates on client devices, using a certificate signed by a trusted CA, or using the certificate-inspection profile for SSL inspection. However, for all of these methods, certificate errors can still occur when you’ve blocked access to a page using web filtering and the FortiGate attempts to display a replacement message for that site using HTTPS.

This error occurs because, by default, the FortiGate does not use the same certificate for SSL inspection and the encryption of the replacement messages. To avoid these errors, you should first determine which certificate your FortiGate uses for replacement messages using the CLI. The command differs depending on which version of FortiOS you are using:

FortiOS 5.2 and earlier:

config webfilter fortiguard
# get 
cache-mode : ttl 
cache-prefix-match : enable 
cache-mem-percent : 2 
ovrd-auth-port-http : 8008 
ovrd-auth-port-https: 8010 
ovrd-auth-port-warning: 8020 
ovrd-auth-https : enable 
warn-auth-https : enable 
close-ports : disable 
request-packet-size-limit: 0 
ovrd-auth-hostname : 
ovrd-auth-cert : Fortinet_Firmware

The certificate Fortinet_Firmware is used by default. To avoid errors, you can either change this certificate to the certificate used for SSL inspection or you can install this certificate on all client devices. Which solution you choose depends on your own environment and what certificates you are already using.

FortiOS 5.4 and later:

config user setting 
# get
auth-type : http https ftp telnet 
auth-cert : Fortinet_Factory 
auth-ca-cert : 
auth-secure-http : disable 
auth-http-basic : disable 
auth-timeout : 5 
auth-timeout-type : idle-timeout 
auth-portal-timeout : 3 
radius-ses-timeout-act: hard-timeout 
auth-blackout-time : 0 
auth-invalid-max : 5 
auth-lockout-threshold: 3 
auth-lockout-duration: 0 
auth-ports:

The certificate Fortinet_Factory is used by default. To avoid errors, you can either change this certificate to the certificate used for SSL inspection or you can install this certificate on all client devices. Which solution you choose depends on your own environment and what certificates you are already using.

For more information about SSL inspection and certificate errors, see the following resources:

• Preventing certificate warnings (5.2 | 5.4)
• Why you should use SSL inspection

The post Certificate errors for blocked websites appeared first on Fortinet Cookbook.

The following is, if not common, a plausible scenario: You have a FortiGate unit that you have upgraded from version 4.3.10 to 5.0.1. You want to make it part of an HA cluster so you bring in a new unit of the exact same model and install a fresh copy of the exact same 5.0.1...

The post Potential HA upgrade error due to changes in FortiOS appeared first on Fortinet Cookbook.

Periodically a situation arises where the FortiGate needs to be accessed or the admin account’s password needs to be changed but no one with the existing password is available. If you have physical access to the device and a few other tools the password can be reset. Warning: This procedure will require the reboot of...

The post Resetting a lost Admin password appeared first on Fortinet Cookbook.

There are certain pieces of documentation that you hope you will never have to find because it means that if you need to find them, then something has gone seriously wrong. One of those documents is the instructions for using the HQIP test. If you haven’t heard of it, HQIP stands for Hardware Quick Inspection...

The post HQIP test documentation appeared first on Fortinet Cookbook.

This article examines how to increase your encryption level. What does strong encryption do? Enabling the use of strong encryption will only allow strong ciphers such as: AES 3DES and digest SHA1 for HTTPS/SSH admin access. When strong encryption is enabled, HTTPS is supported by the following web browsers: Netscape 7.2 -8.0 Firefox Microsoft Internet...

The post Increasing the encryption level appeared first on Fortinet Cookbook.

See the Hardware Acceleration Guide.  

The post NP4 and NP6 diagnose commands appeared first on Fortinet Cookbook.

Before proceeding, it should be made clear that  moving a configuration file from one model to another is not officially supported by Fortinet. That being said, there are a few gray areas where circumstances can force the issue. This article is intended to color in those gray areas with some information you may find useful....

The post Transferring a configuration file from one model to another appeared first on Fortinet Cookbook.

If you appear to have configured your HA settings correctly but after trying to implement the HA cluster everything is still in stand-alone mode the issue could be with the interfaces. When setting up an HA cluster it is important to make sure that none of the interfaces are configured to get their IP addresses...

The post Check addressing mode if HA cluster not setting up properly appeared first on Fortinet Cookbook.

The following is, if not common, a plausible scenario: You have a FortiGate unit that you have upgraded from version 4.3.10 to 5.0.1. You want to make it part of an HA cluster so you bring in a new unit of the exact same model and install a fresh copy of the exact same 5.0.1...

The post Potential HA upgrade error due to changes in FortiOS appeared first on Fortinet Cookbook.