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 this chapter:
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.
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? The direction. The first example uses outbound NAT and the second one uses inbound NAT, also known as port forwarding. There is a third supported type of NAT in OPNsense – one-to-one. This kind of NAT can be used in both directions. A special term used when talking about one-to-one NAT is when you have networks of the same size and need to apply NAT in both directions. We call this BINAT in OPNsense. We will explore all these three types of NAT in the following sections.
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 – 192.168.100.1 on port 80 in this case. As OPNsense is a stateful firewall, the reply from the web server will follow the same path back to the internet client, leaving the internal network with the translated address 200.200.200.1, instead of 192.168.100.1. Otherwise, the packet will not be routable to the internet since its internal IP address is an RFC1918 private IP address and couldn't be routed on the internet. Using port forwarding allows us to assign thousands of ports to internal services/ports with just one public IP address.
Notes
A common issue related to port forwarding NAT is when the internal host has a default gateway set to another router/host rather than the firewall that is forwarding the inbound NAT rules. This will break the connection and will not work, since the outgoing packets (replies) are leaving the internal network from another gateway.
For more about RFC1918 address allocation for private internets please refer to http://www.faqs.org/rfcs/rfc1918.html.
Let's now look at caveats, which is another important NAT concept.
Port forwarding will not always save the day. Some situations will require more sophisticated solutions, such as reverse proxies. An example is when you have just one public IP address available and multiple web servers that require serving on port 443 (HTTPS), which will not be possible with only one IP address available. While using NAT, you must configure a different port for each server. In this case, a reverse proxy could help. OPNsense has some plugins that may help in this case, such as HAProxy and NGINX, but for logging the real client's IP addresses, they may demand that the application supports reverse proxy protocols to work as expected.
Note
If you have some trouble while using proxy protocols with reverse proxies, check out this awesome project that could help you: https://github.com/cloudflare/mmproxy. Thanks to Fabian Franz for this tip!
Now that we have learned about the port forwarding basics, let's look at how to create a rule of this type.
OPNsense WebGUI simplifies a lot of how to create a NAT port forwarding rule. Let's see the steps we will need to create our first port forwarding rule:
Figure 6.2 – NAT Port Forward rules page
A new page will be opened, with the following options:
Now that we have explored the port forwarding rules page, let's practice a little bit.
To see a working port forwarding rule, we can redirect a new port to WebGUI. To follow these steps, we'll need a working OPNsense installation. In this exercise, we will assume that you are using the virtual machine we set up earlier in this book.
Create a new port forwarding rule that will forward the TCP port 8443 of our LAN network interface address to the loopback address at port 443, the WebGUI default port (the options not mentioned keep the default values):
After creation, your rule will look like this:
Figure 6.3 – Example port forwarding rule
Now try to access OPNsense WebGUI using the LAN IP address but using port 8443, for example, https://<OPNsense_LAN_IP_Address>:8443.
If your rule is correct, WebGUI will load using port 8443. It's done! Your first port forwarding rule is working!
If you want to check that the rule just added is working, go to Firewall | Diagnostics | States Dump, and you should see the translated connection states as in the following screenshot:
Figure 6.4 – Translated connection states example
As we can see, the IP address inside the parentheses (192.168.168.3:8443) is the destination address and port set in the rule, and the address after the <- is the redirect target IP. As you can see, even with this unusual example, port forwarding works very well!
Note
I tried to use a simple example that does not demand an entire network lab setup, but feel free to add some virtual machines in your laboratory to practice other port forwarding examples.
Now that we have learned about port forwarding basics and created our first rule, let's move on with 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, the client for the web server is the OPNsense public IP. In this way, all the internal clients can access different internet hosts at the same time, sharing the same public IP address, and as we can observe in the preceding table, the mapping is based on the internal source IP and public IP source port. Cool, huh?
Note
I have used a translation from an internal to a public IP address in this example, but it is common to use outbound NAT in scenarios that demand a translation from an internal to another internal IP address. An example of doing that is while using VPN tunnels.
Let's go to OPNsense WebGUI and see how to create NAT outbound rules.
To create a new rule, we need to first set OPNsense to the correct NAT outbound mode. There are four possible modes, and you can set them by going to Firewall | NAT | Outbound:
To create a new outbound rule, I'll suggest you set the Hybrid outbound NAT rule generation mode to on. To do that, you will need to do the following:
Figure 6.6 – Firewall: NAT: Outbound page
Let's now look at how to add an outbound NAT rule.
To add a new outbound NAT rule, first, select a compatible mode – Hybrid outbound NAT rule generation or Manual outbound NAT rule generation – then click on the Save button. As I said before, I suggest using the hybrid mode.
Figure 6.7 – Firewall: NAT: Outbound page
As you can see in the preceding screenshot, Manual rules is displayed before Automatic rules, following the processing rules order.
After selecting a compatible mode, next click on the + Add button to create a new rule. The following options will be shown:
Manually created outbound NAT rules are usually used in multi-WAN scenarios and while using high availability. We will explore both features later in this book, and we will have the opportunity to create outbound NAT rules when the right time arrives. Usually, the automatic mode will fit most small networks that need to share an internet connection with the internal network hosts.
Let's now move on to the last type of NAT available in OPNsense WebGUI — one-to-one.
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.
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:
Note
To permit traffic, you need to also add a firewall rule once. One-to-one rules don't automatically add rules in the firewall ruleset.
To illustrate a scenario using BINAT, let's consider a network with a Linux host using the Secure Shell (SSH) protocol for remote connections (incoming traffic NAT), and the same host using OPNsense as the default gateway to access the internet (outgoing traffic NAT):
Figure 6.8 – BINAT example
The created one-to-one BINAT rule for the preceding scenario will look like this:
Figure 6.9 – BINAT example rule
Another example using BINAT is using it with IPSec tunnels. We will explore VPN tunnels in the next chapter, but if you are curious about this BINAT implementation using IPSec, you can take a look at https://docs.opnsense.org/manual/how-tos/ipsec-s2s-binat.html.
Note
I just used the SSH protocol as an example; it is not a good idea to allow SSH access to the public internet. Instead, always prefer accessing it through VPN tunnels.
To allow both incoming and outgoing traffic, you must create the proper firewall rules in the respective network interface.
As you can see, one-to-one NAT rules are an option in some specific situations that NAT port forwarding and NAT outbound rules will also fit, but the way you set it is, in most cases, simpler than other NAT-type rules.
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!
3.149.240.75