One IP address serving multiple servers

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.