Chapter 6: Network Address Translation (NAT)

Following the last chapter, where we explored firewalling, Network Address Translation (NAT) is a simple way to have an entire local network using a single public IP address. Since NAT is an IPv4-exclusive method, we will not explore IPv6 and its equivalent NPTv6 (also known as NAT66). This book aims to provide valuable and practical information. Unfortunately, these days, IPv6 and NPTv6 aren't the predominantly used technology in local networks.

IPv6 Adoption

According to Google's IPv6 statistics page (in July 2021), IPv6 adoption was 35% globally (https://www.google.com/intl/en/ipv6/statistics.html).

Coming back to our chapter's topic, we will learn about NAT concepts, which types OPNsense supports, and how to create NAT rules on WebGUI. By the end of this chapter, you will be able to manage NAT rules on OPNsense and will understand how the NAT method works.

The following are the topics we'll explore in...

Technical requirements

This chapter requires that you have a clear understanding of firewall concepts and the TCP/IP network stack, and feel comfortable running commands on the CLI. You will need OPNsense running to follow some of this chapter's steps. I suggest you use the virtual machine we set up earlier in this book, in Chapter 2, Installing OPNsense.

NAT concepts

Before we start to talk about NAT concepts, let's understand what kind of problems it solves. Let's think of a small company with a network of 10 devices and all of them need to be connected directly to the internet. We are talking about a small company with a limited budget, so the available WAN connection has only one public Internet Protocol (IP) address and there is no possibility to get an upgrade to a service that provides an entire IP network range. Sound familiar? In Brazil and Portugal, this scenario is very common. So, how do we connect all those devices using a single public IP address? If you answered using NAT, you're right! This is one of the most common scenarios for using NAT. Another one is when you need to provide, let's say, web services, but you have more web servers than available public IP addresses. In this case, NAT can help too, by using different ports of the same IP address. But what is the difference between these two examples...

Port forwarding

Using our previous example, let's consider a small company with three web servers but with just one public IP address and a lot of users needing to access them from the internet. How can we solve this problem using just firewall features? By creating an inbound NAT rule! We will refer to this type of NAT in this book in the same way as OPNsense: port forwarding. It will forward a port or a port range from the public interface to an internal host such as, for example, a web server. At the same time, the port number/range can be changed.

Using the preceding example, let's take a look at the following topology:

Figure 6.1 – Port forwarding example

In the preceding figure, you can see a client requesting access from the internet to the public IP 200.200.200.1 on port 8080. When this request arrives in our firewall, it will look for a NAT entry that forwards port 8080 in its public IP address to an internal address and port...

Outbound NAT

Back to our examples, as we discussed at the beginning of this chapter, let's use the example of a small company with 10 computers and just a single public IP address in its WAN connection. Moving on in this scenario, we have the goal to connect all those computers to the internet just using firewall capabilities. How do we achieve that? By creating an outbound NAT! Let's see how things work. The following is an example topology of outbound NAT traffic:

Figure 6.5 – Outbound NAT example

As we can see in the preceding figure, three clients are each accessing a website. Let's pick the host 192.168.10.11: it is accessing the https://cloudfence.eu website, but to the CloudFence web server, the source IP address is the public IP of OPNsense firewall 200.200.200.1 with source port 10200. So what is happening here? The outbound NAT rule is translating from the internal source IP to a public IP address, so from a TCP perspective...

One-to-one NAT

So far, we have learned about NAT types that allow us to map one-to-many IP addresses, so the main difference of this type of NAT is that it will map one IP to another one in a one-to-one manner. Every port will be forwarded to the internal IP or network, and if all traffic is permitted by the filter rule, this can mean an internal IP is exposed to the internet, so be careful using this type of NAT.

In my personal experience, I have seen a few instances of OPNsense using NAT one to one in corporate networks. A common situation I will mention is when you need to connect two remote sites using an IPsec tunnel and the internal networks overlap between those sites. In this case, one-to-one BINAT usually helps a lot!

Next, we'll see how to add a one-to-one rule.

Adding a one-to-one NAT rule

To add a rule, go to Firewall | NAT | One-to-One and click on the + Add button. A new page will be opened with the following options:

• Disabled: Check this option...

Summary

In this chapter, we learned about the types of NAT OPNsense supports, how they work, and when to use each one. Of course, not all possible examples can fit in just one chapter, or maybe even one book, but I tried to cover the most common usages. Now you can understand and create port forwarding, outbound, and one-to-one rules using OPNsense WebGUI.

In the next chapter, we'll learn about traffic shaping and how to use OPNsense to create rules using it. See you there!