diff options
Diffstat (limited to 'docs/nat.rst')
| -rw-r--r-- | docs/nat.rst | 324 |
1 files changed, 324 insertions, 0 deletions
diff --git a/docs/nat.rst b/docs/nat.rst new file mode 100644 index 00000000..a69cffbe --- /dev/null +++ b/docs/nat.rst @@ -0,0 +1,324 @@ +.. _nat: + +NAT +=== + +Source NAT +---------- + +Source NAT is typically referred to simply as NAT. To be more correct, what +most people refer to as NAT is actually the process of **Port Address +Translation (PAT)**, or **NAT Overload**. The process of having many internal +host systems communicate to the Internet using a single or subset of IP +addresses. + +To setup SNAT, we need to know: +* The internal IP addresses we want to translate +* The outgoing interface to perform the translation on +* The external IP address to translate to + +In the example used for the Quick Start configuration above, we demonstrate +the following configuration: + + set nat source rule 100 outbound-interface 'eth0' + set nat source rule 100 source address '192.168.0.0/24' + set nat source rule 100 translation address 'masquerade' + +Which generates the following configuration: + +.. code-block:: sh + + rule 100 { + outbound-interface eth0 + source { + address 192.168.0.0/24 + } + translation { + address masquerade + } + } + +In this example, we use **masquerade** as the translation address instead of +an IP address. The **masquerade** target is effectively an alias to say "use +whatever IP address is on the outgoing interface", rather than a statically +configured IP address. This is useful if you use DHCP for your outgoing +interface and do not know what the external address will be. + +When using NAT for a large number of host systems it recommended that a +minimum of 1 IP address is used to NAT every 256 host systems. This is due to +the limit of 65,000 port numbers available for unique translations and a +reserving an average of 200-300 sessions per host system. + +Example: For an ~8,000 host network a source NAT pool of 32 IP addresses is +recommended. + +A pool of addresses can be defined by using a **-** in the `set nat source +rule [n] translation address` statement. + +.. code-block:: sh + + set nat source rule 100 translation address '203.0.113.32-203.0.113.63' + +.. note:: Avoiding "leaky" NAT + +Linux netfilter will not NAT traffic marked as INVALID. This often confuses +people into thinking that Linux (or specifically VyOS) has a broken NAT +implementation because non-NATed traffic is seen leaving an external interface. +This is actually working as intended, and a packet capture of the "leaky" +traffic should reveal that the traffic is either an additional TCP "RST", +"FIN,ACK", or "RST,ACK" sent by client systems after Linux netfilter considers +the connection closed. The most common is the additional TCP RST some host +implementations send after terminating a connection (which is implementation- +specific). + +In other words, connection tracking has already observed the connection be +closed and has transition the flow to INVALID to prevent attacks from +attempting to reuse the connection. + +You can avoid the "leaky" behavior by using a firewall policy that drops +"invalid" state packets. + +Having control over the matching of INVALID state traffic, e.g. the ability to +selectively log, is an important troubleshooting tool for observing broken +protocol behavior. For this reason, VyOS does not globally drop invalid state +traffic, instead allowing the operator to make the determination on how the +traffic is handled. + +.. note:: Avoiding NAT breakage in the absence of split-DNS + +A typical problem with using NAT and hosting public servers is the ability for +internal systems to reach an internal server using it's external IP address. +The solution to this is usually the use of split-DNS to correctly point host +systems to the internal address when requests are made internally. Because +many smaller networks lack DNS infrastructure, a work-around is commonly +deployed to facilitate the traffic by NATing the request from internal hosts +to the source address of the internal interface on the firewall. This technique +is commonly reffered to as **NAT Reflection**, or **Hairpin NAT**. + +In this example, we will be using the example Quick Start configuration above +as a starting point. + +To setup a NAT reflection rule, we need to create a rule to NAT connections +from the internal network to the same internal network to use the source +address of the internal interface. + +.. code-block:: sh + + set nat source rule 110 description 'NAT Reflection: INSIDE' + set nat source rule 110 destination address '192.168.0.0/24' + set nat source rule 110 outbound-interface 'eth1' + set nat source rule 110 source address '192.168.0.0/24' + set nat source rule 110 translation address 'masquerade' + +Which results in a configuration of: + +.. code-block:: sh + + rule 110 { + description "NAT Reflection: INSIDE" + destination { + address 192.168.0.0/24 + } + outbound-interface eth1 + source { + address 192.168.0.0/24 + } + translation { + address masquerade + } + } + +Destination NAT +--------------- + +DNAT is typically referred to as a **Port Forward**. When using VyOS as a NAT +router and firewall, a common configuration task is to redirect incoming +traffic to a system behind the firewall. + +In this example, we will be using the example Quick Start configuration above +as a starting point. + +To setup a destination NAT rule we need to gather: +* The interface traffic will be coming in on +* The protocol and port we wish to forward +* The IP address of the internal system we wish to forward traffic to + +In our example, we will be forwarding web server traffic to an internal web +server on 192.168.0.100. HTTP traffic makes use of the TCP protocol on port 80. +For other common port numbers, see: http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers + +Our configuration commands would be: + +.. code-block:: sh + + set nat destination rule 10 description 'Port Forward: HTTP to 192.168.0.100' + set nat destination rule 10 destination port '80' + set nat destination rule 10 inbound-interface 'eth0' + set nat destination rule 10 protocol 'tcp' + set nat destination rule 10 translation address '192.168.0.100' + +Which would generate the following NAT destination configuration: + +.. code-block:: sh + + nat { + destination { + rule 10 { + description "Port Forward: HTTP to 192.168.0.100" + destination { + port 80 + } + inbound-interface eth0 + protocol tcp + translation { + address 192.168.0.100 + } + } + } + } + +.. note:: If forwarding traffic to a different port than it is arriving on, + you may also configure the translation port using `set nat destination rule + [n] translation port`. + +This establishes our Port Forward rule, but if we created a firewall policy it +will likely block the traffic. + +It is important to note that when creating firewall rules that the DNAT +translation occurs **before** traffic traverses the firewall. In other words, +the destination address has already been translated to 192.168.0.100. + +So in our firewall policy, we want to allow traffic coming in on the outside +interface, destined for TCP port 80 and the IP address of 192.168.0.100. + +.. code-block:: sh + + set firewall name OUTSIDE-IN rule 20 action 'accept' + set firewall name OUTSIDE-IN rule 20 destination address '192.168.0.100' + set firewall name OUTSIDE-IN rule 20 destination port '80' + set firewall name OUTSIDE-IN rule 20 protocol 'tcp' + set firewall name OUTSIDE-IN rule 20 state new 'enable' + +This would generate the following configuration: + +.. code-block:: sh + + rule 20 { + action accept + destination { + address 192.168.0.100 + port 80 + } + protocol tcp + state { + new enable + } + } + +.. note:: + + If you have configured the `INSIDE-OUT` policy, you will need to add + additional rules to permit inbound NAT traffic. + +1-to-1 NAT +---------- + +Another term often used for DNAT is **1-to-1 NAT**. For a 1-to-1 NAT +configuration, both DNAT and SNAT are used to NAT all traffic from an external +IP address to an internal IP address and vice-versa. + +Typically, a 1-to-1 NAT rule omits the destination port (all ports) and +replaces the protocol with either **all** or **ip**. + +Then a corresponding SNAT rule is created to NAT outgoing traffic for the +internal IP to a reserved external IP. This dedicates an external IP address +to an internal IP address and is useful for protocols which don't have the +notion of ports, such as GRE. + +1-to-1 NAT example +------------------ + +Here's an extract of a simple 1-to-1 NAT configuration with one internal and +one external interface: + +.. code-block:: sh + + set interfaces ethernet eth0 address '192.168.1.1/24' + set interfaces ethernet eth0 description 'Inside interface' + set interfaces ethernet eth1 address '1.2.3.4/24' + set interfaces ethernet eth1 description 'Outside interface' + set nat destination rule 2000 description '1-to-1 NAT example' + set nat destination rule 2000 destination address '1.2.3.4' + set nat destination rule 2000 inbound-interface 'eth1' + set nat destination rule 2000 translation address '192.168.1.10' + set nat source rule 2000 description '1-to-1 NAT example' + set nat source rule 2000 outbound-interface 'eth1' + set nat source rule 2000 source address '192.168.1.10' + set nat source rule 2000 translation address '1.2.3.4' + +Firewall rules are written as normal, using the internal IP address as the +source of outbound rules and the destination of inbound rules. + +NPTv6 (RFC6296) +--------------- + +NPTv6 stands for Network Prefix Translation. It's a form of NAT for IPv6. It's +described in RFC6296_. NPTv6 is supported in linux kernel since version 3.13. + +Usage +----- + +NPTv6 is very useful for IPv6 multihoming. Let's assume the following network +configuration: + +* eth0 : LAN +* eth1 : WAN1, with 2001:db8:e1::/48 routed towards it +* eth2 : WAN2, with 2001:db8:e2::/48 routed towards it + +Regarding LAN hosts addressing, why would you choose 2001:db8:e1::/48 over +2001:db8:e2::/48? What happens when you get a new provider with a different +routed IPv6 subnet? + +The solution here is to assign to your hosts ULAs_ and to prefix-translate +their address to the right subnet when going through your router. + +* LAN Subnet : fc00:dead:beef::/48 +* WAN 1 Subnet : 2001:db8:e1::/48 +* WAN 2 Subnet : 2001:db8:e2::/48 + +* eth0 addr : fc00:dead:beef::1/48 +* eth1 addr : 2001:db8:e1::1/48 +* eth2 addr : 2001:db8:e2::1/48 + +VyOS Support +------------ + +NPTv6 support has been added in VyOS 1.2 (Crux) and is available through +`nat nptv6` configuration nodes. + +.. code-block:: sh + + set rule 10 inside-prefix 'fc00:dead:beef::/48' + set rule 10 outside-interface 'eth1' + set rule 10 outside-prefix '2001:db8:e1::/48' + set rule 20 inside-prefix 'fc00:dead:beef::/48' + set rule 20 outside-interface 'eth2' + set rule 20 outside-prefix '2001:db8:e2::/48' + +Resulting in the following ip6tables rules: + +.. code-block:: sh + + Chain VYOS_DNPT_HOOK (1 references) + pkts bytes target prot opt in out source destination + 0 0 DNPT all eth1 any anywhere 2001:db8:e1::/48 src-pfx 2001:db8:e1::/48 dst-pfx fc00:dead:beef::/48 + 0 0 DNPT all eth2 any anywhere 2001:db8:e2::/48 src-pfx 2001:db8:e2::/48 dst-pfx fc00:dead:beef::/48 + 0 0 RETURN all any any anywhere anywhere + Chain VYOS_SNPT_HOOK (1 references) + pkts bytes target prot opt in out source destination + 0 0 SNPT all any eth1 fc00:dead:beef::/48 anywhere src-pfx fc00:dead:beef::/48 dst-pfx 2001:db8:e1::/48 + 0 0 SNPT all any eth2 fc00:dead:beef::/48 anywhere src-pfx fc00:dead:beef::/48 dst-pfx 2001:db8:e2::/48 + 0 0 RETURN all any any anywhere anywhere + +.. _RFC6296: https://tools.ietf.org/html/rfc6296 +.. _ULAs: http://en.wikipedia.org/wiki/Unique_local_address |