vyos/vyos-documentation
1
0
Fork 0
mirror of https://github.com/vyos/vyos-documentation.git synced 2025-10-26 08:41:46 +01:00
Code Issues Packages Projects Releases Wiki Activity

nptv6: T2518: Add document support for nat66

Browse Source
This commit is contained in:
JACK 2021-01-25 02:39:47 +08:00 committed by Christian Poessinger
parent f7749b67c6
commit a1297a53f7
5 changed files with 862 additions and 798 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
docs/_static/images/vyos_1_4_nat66_simple.png vendored Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 20 KiB

731
docs/configuration/nat/index.rst
View File

@ -8,732 +8,5 @@ NAT
:maxdepth: 1 :maxdepth: 1
:includehidden: :includehidden:
nptv6 nat44
nat66
:abbr:`NAT (Network Address Translation)` is a common method of
remapping one IP address space into another by modifying network address
information in the IP header of packets while they are in transit across
a traffic routing device. The technique was originally used as a
shortcut to avoid the need to readdress every host when a network was
moved. It has become a popular and essential tool in conserving global
address space in the face of IPv4 address exhaustion. One
Internet-routable IP address of a NAT gateway can be used for an entire
private network.
IP masquerading is a technique that hides an entire IP address space,
usually consisting of private IP addresses, behind a single IP address
in another, usually public address space. The hidden addresses are
changed into a single (public) IP address as the source address of the
outgoing IP packets so they appear as originating not from the hidden
host but from the routing device itself. Because of the popularity of
this technique to conserve IPv4 address space, the term NAT has become
virtually synonymous with IP masquerading.
As network address translation modifies the IP address information in
packets, NAT implementations may vary in their specific behavior in
various addressing cases and their effect on network traffic. The
specifics of NAT behavior are not commonly documented by vendors of
equipment containing NAT implementations.
The computers on an internal network can use any of the addresses set
aside by the :abbr:`IANA (Internet Assigned Numbers Authority)` for
private addressing (see :rfc:`1918`). These reserved IP addresses are
not in use on the Internet, so an external machine will not directly
route to them. The following addresses are reserved for private use:
* 10.0.0.0 to 10.255.255.255 (CIDR: 10.0.0.0/8)
* 172.16.0.0 to 172.31.255.255 (CIDR: 172.16.0.0/12)
* 192.168.0.0 to 192.168.255.255 (CIDR: 192.168.0.0/16)
If an ISP deploys a :abbr:`CGN (Carrier-grade NAT)`, and uses
:rfc:`1918` address space to number customer gateways, the risk of
address collision, and therefore routing failures, arises when the
customer network already uses an :rfc:`1918` address space.
This prompted some ISPs to develop a policy within the :abbr:`ARIN
(American Registry for Internet Numbers)` to allocate new private
address space for CGNs, but ARIN deferred to the IETF before
implementing the policy indicating that the matter was not a typical
allocation issue but a reservation of addresses for technical purposes
(per :rfc:`2860`).
IETF published :rfc:`6598`, detailing a shared address space for use in
ISP CGN deployments that can handle the same network prefixes occurring
both on inbound and outbound interfaces. ARIN returned address space to
the :abbr:`IANA (Internet Assigned Numbers Authority)` for this
allocation.
The allocated address block is 100.64.0.0/10.
Devices evaluating whether an IPv4 address is public must be updated to
recognize the new address space. Allocating more private IPv4 address
space for NAT devices might prolong the transition to IPv6.
Overview
========
Different NAT Types
-------------------
.. _source-nat:
SNAT
^^^^
:abbr:`SNAT (Source Network Address Translation)` is the most common
form of :abbr:`NAT (Network Address Translation)` and is typically
referred to simply as NAT. To be more correct, what most people refer
to as :abbr:`NAT (Network Address Translation)` is actually the process
of :abbr:`PAT (Port Address Translation)`, or NAT overload. SNAT is
typically used by internal users/private hosts to access the Internet
- the source address is translated and thus kept private.
.. _destination-nat:
DNAT
^^^^
:abbr:`DNAT (Destination Network Address Translation)` changes the
destination address of packets passing through the router, while
:ref:`source-nat` changes the source address of packets. DNAT is
typically used when an external (public) host needs to initiate a
session with an internal (private) host. A customer needs to access a
private service behind the routers public IP. A connection is
established with the routers public IP address on a well known port and
thus all traffic for this port is rewritten to address the internal
(private) host.
.. _bidirectional-nat:
Bidirectional NAT
^^^^^^^^^^^^^^^^^
This is a common scenario where both :ref:`source-nat` and
:ref:`destination-nat` are configured at the same time. It's commonly
used then internal (private) hosts need to establish a connection with
external resources and external systems need to access internal
(private) resources.
NAT, Routing, Firewall Interaction
----------------------------------
There is a very nice picture/explanation in the Vyatta documentation
which should be rewritten here.
NAT Ruleset
-----------
:abbr:`NAT (Network Address Translation)` is configured entirely on a
series of so called `rules`. Rules are numbered and evaluated by the
underlying OS in numerical order! The rule numbers can be changes by
utilizing the :cfgcmd:`rename` and :cfgcmd:`copy` commands.
.. note:: Changes to the NAT system only affect newly established
connections. Already established connections are not affected.
.. hint:: When designing your NAT ruleset leave some space between
consecutive rules for later extension. Your ruleset could start with
numbers 10, 20, 30. You thus can later extend the ruleset and place
new rules between existing ones.
Rules will be created for both :ref:`source-nat` and
:ref:`destination-nat`.
For :ref:`bidirectional-nat` a rule for both :ref:`source-nat` and
:ref:`destination-nat` needs to be created.
.. _traffic-filters:
Traffic Filters
---------------
Traffic Filters are used to control which packets will have the defined
NAT rules applied. Five different filters can be applied within a NAT
rule.
* **outbound-interface** - applicable only to :ref:`source-nat`. It
configures the interface which is used for the outside traffic that
this translation rule applies to.
Example:
.. code-block:: none
set nat source rule 20 outbound-interface eth0
* **inbound-interface** - applicable only to :ref:`destination-nat`. It
configures the interface which is used for the inside traffic the
translation rule applies to.
Example:
.. code-block:: none
set nat destination rule 20 inbound-interface eth1
* **protocol** - specify which types of protocols this translation rule
applies to. Only packets matching the specified protocol are NATed.
By default this applies to `all` protocols.
Example:
* Set SNAT rule 20 to only NAT TCP and UDP packets
* Set DNAT rule 20 to only NAT UDP packets
.. code-block:: none
set nat source rule 20 protocol tcp_udp
set nat destination rule 20 protocol udp
* **source** - specifies which packets the NAT translation rule applies
to based on the packets source IP address and/or source port. Only
matching packets are considered for NAT.
Example:
* Set SNAT rule 20 to only NAT packets arriving from the 192.0.2.0/24
network
* Set SNAT rule 30 to only NAT packets arriving from the 203.0.113.0/24
network with a source port of 80 and 443
.. code-block:: none
set nat source rule 20 source address 192.0.2.0/24
set nat source rule 30 source address 203.0.113.0/24
set nat source rule 30 source port 80,443
* **destination** - specify which packets the translation will be
applied to, only based on the destination address and/or port number
configured.
.. note:: If no destination is specified the rule will match on any
destination address and port.
Example:
* Configure SNAT rule (40) to only NAT packets with a destination
address of 192.0.2.1.
.. code-block:: none
set nat source rule 40 destination address 192.0.2.1
Address Conversion
------------------
Every NAT rule has a translation command defined. The address defined
for the translation is the address used when the address information in
a packet is replaced.
Source Address
^^^^^^^^^^^^^^
For :ref:`source-nat` rules the packets source address will be replaced
with the address specified in the translation command. A port
translation can also be specified and is part of the translation
address.
.. note:: The translation address must be set to one of the available
addresses on the configured `outbound-interface` or it must be set to
`masquerade` which will use the primary IP address of the
`outbound-interface` as its translation address.
.. note:: 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
private 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:
* Define a discrete source IP address of 100.64.0.1 for SNAT rule 20
* Use address `masquerade` (the interfaces primary address) on rule 30
* For a large amount of private machines behind the NAT your address
pool might to be bigger. Use any address in the range 100.64.0.10 -
100.64.0.20 on SNAT rule 40 when doing the translation
.. code-block:: none
set nat source rule 20 translation address 100.64.0.1
set nat source rule 30 translation address 'masquerade'
set nat source rule 40 translation address 100.64.0.10-100.64.0.20
Destination Address
^^^^^^^^^^^^^^^^^^^
For :ref:`destination-nat` rules the packets destination address will be
replaced by the specified address in the `translation address` command.
Example:
* DNAT rule 10 replaces the destination address of an inbound packet
with 192.0.2.10
.. code-block:: none
set nat destination rule 10 translation address 192.0.2.10
Configuration Examples
======================
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:
.. code-block:: none
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:: none
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 hyphen between two IP
addresses:
.. code-block:: none
set nat source rule 100 translation address '203.0.113.32-203.0.113.63'
.. _avoidng_leaky_nat:
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.
.. _hairpin_nat_reflection:
Hairpin NAT/NAT Reflection
--------------------------
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 referred to as NAT Reflection or Hairpin NAT.
Example:
* Redirect Microsoft RDP traffic from the outside (WAN, external) world
via :ref:`destination-nat` in rule 100 to the internal, private host
192.0.2.40.
* Redirect Microsoft RDP traffic from the internal (LAN, private)
network via :ref:`destination-nat` in rule 110 to the internal,
private host 192.0.2.40. We also need a :ref:`source-nat` rule 110 for
the reverse path of the traffic. The internal network 192.0.2.0/24 is
reachable via interface `eth0.10`.
.. code-block:: none
set nat destination rule 100 description 'Regular destination NAT from external'
set nat destination rule 100 destination port '3389'
set nat destination rule 100 inbound-interface 'pppoe0'
set nat destination rule 100 protocol 'tcp'
set nat destination rule 100 translation address '192.0.2.40'
set nat destination rule 110 description 'NAT Reflection: INSIDE'
set nat destination rule 110 destination port '3389'
set nat destination rule 110 inbound-interface 'eth0.10'
set nat destination rule 110 protocol 'tcp'
set nat destination rule 110 translation address '192.0.2.40'
set nat source rule 110 description 'NAT Reflection: INSIDE'
set nat source rule 110 destination address '192.0.2.0/24'
set nat source rule 110 outbound-interface 'eth0.10'
set nat source rule 110 protocol 'tcp'
set nat source rule 110 source address '192.0.2.0/24'
set nat source rule 110 translation address 'masquerade'
Which results in a configuration of:
.. code-block:: none
vyos@vyos# show nat
destination {
rule 100 {
description "Regular destination NAT from external"
destination {
port 3389
}
inbound-interface pppoe0
protocol tcp
translation {
address 192.0.2.40
}
}
rule 110 {
description "NAT Reflection: INSIDE"
destination {
port 3389
}
inbound-interface eth0.10
protocol tcp
translation {
address 192.0.2.40
}
}
}
source {
rule 110 {
description "NAT Reflection: INSIDE"
destination {
address 192.0.2.0/24
}
outbound-interface eth0.10
protocol tcp
source {
address 192.0.2.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:
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
Our configuration commands would be:
.. code-block:: none
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:: none
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:: none
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:: none
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.
Here's an extract of a simple 1-to-1 NAT configuration with one internal
and one external interface:
.. code-block:: none
set interfaces ethernet eth0 address '192.168.1.1/24'
set interfaces ethernet eth0 description 'Inside interface'
set interfaces ethernet eth1 address '192.0.2.30/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 '192.0.2.30'
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 '192.0.2.30'
Firewall rules are written as normal, using the internal IP address as
the source of outbound rules and the destination of inbound rules.
NAT before VPN
--------------
Some application service providers (ASPs) operate a VPN gateway to
provide access to their internal resources, and require that a
connecting organisation translate all traffic to the service provider
network to a source address provided by the ASP.
Example Network
^^^^^^^^^^^^^^^
Here's one example of a network environment for an ASP.
The ASP requests that all connections from this company should come from
172.29.41.89 - an address that is assigned by the ASP and not in use at
the customer site.
.. figure:: /_static/images/nat_before_vpn_topology.png
:scale: 100 %
:alt: NAT before VPN Topology
NAT before VPN Topology
Configuration
^^^^^^^^^^^^^
The required configuration can be broken down into 4 major pieces:
* A dummy interface for the provider-assigned IP;
* NAT (specifically, Source NAT);
* IPSec IKE and ESP Groups;
* IPSec VPN tunnels.
Dummy interface
"""""""""""""""
The dummy interface allows us to have an equivalent of the Cisco IOS
Loopback interface - a router-internal interface we can use for IP
addresses the router must know about, but which are not actually
assigned to a real network.
We only need a single step for this interface:
.. code-block:: none
set interfaces dummy dum0 address '172.29.41.89/32'
NAT Configuration
"""""""""""""""""
.. code-block:: none
set nat source rule 110 description 'Internal to ASP'
set nat source rule 110 destination address '172.27.1.0/24'
set nat source rule 110 outbound-interface 'any'
set nat source rule 110 source address '192.168.43.0/24'
set nat source rule 110 translation address '172.29.41.89'
set nat source rule 120 description 'Internal to ASP'
set nat source rule 120 destination address '10.125.0.0/16'
set nat source rule 120 outbound-interface 'any'
set nat source rule 120 source address '192.168.43.0/24'
set nat source rule 120 translation address '172.29.41.89'
IPSec IKE and ESP
"""""""""""""""""
The ASP has documented their IPSec requirements:
* IKE Phase:
* aes256 Encryption
* sha256 Hashes
* ESP Phase:
* aes256 Encryption
* sha256 Hashes
* DH Group 14
Additionally, we want to use VPNs only on our eth1 interface (the
external interface in the image above)
.. code-block:: none
set vpn ipsec ike-group my-ike ikev2-reauth 'no'
set vpn ipsec ike-group my-ike key-exchange 'ikev1'
set vpn ipsec ike-group my-ike lifetime '7800'
set vpn ipsec ike-group my-ike proposal 1 dh-group '14'
set vpn ipsec ike-group my-ike proposal 1 encryption 'aes256'
set vpn ipsec ike-group my-ike proposal 1 hash 'sha256'
set vpn ipsec esp-group my-esp compression 'disable'
set vpn ipsec esp-group my-esp lifetime '3600'
set vpn ipsec esp-group my-esp mode 'tunnel'
set vpn ipsec esp-group my-esp pfs 'disable'
set vpn ipsec esp-group my-esp proposal 1 encryption 'aes256'
set vpn ipsec esp-group my-esp proposal 1 hash 'sha256'
set vpn ipsec ipsec-interfaces interface 'eth1'
IPSec VPN Tunnels
"""""""""""""""""
We'll use the IKE and ESP groups created above for this VPN. Because we
need access to 2 different subnets on the far side, we will need two
different tunnels. If you changed the names of the ESP group and IKE
group in the previous step, make sure you use the correct names here
too.
.. code-block:: none
set vpn ipsec site-to-site peer 198.51.100.243 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer 198.51.100.243 authentication pre-shared-secret 'PASSWORD IS HERE'
set vpn ipsec site-to-site peer 198.51.100.243 connection-type 'initiate'
set vpn ipsec site-to-site peer 198.51.100.243 default-esp-group 'my-esp'
set vpn ipsec site-to-site peer 198.51.100.243 ike-group 'my-ike'
set vpn ipsec site-to-site peer 198.51.100.243 ikev2-reauth 'inherit'
set vpn ipsec site-to-site peer 198.51.100.243 local-address '203.0.113.46'
set vpn ipsec site-to-site peer 198.51.100.243 tunnel 0 local prefix '172.29.41.89/32'
set vpn ipsec site-to-site peer 198.51.100.243 tunnel 0 remote prefix '172.27.1.0/24'
set vpn ipsec site-to-site peer 198.51.100.243 tunnel 1 local prefix '172.29.41.89/32'
set vpn ipsec site-to-site peer 198.51.100.243 tunnel 1 remote prefix '10.125.0.0/16'
Testing and Validation
""""""""""""""""""""""
If you've completed all the above steps you no doubt want to see if it's
all working.
Start by checking for IPSec SAs (Security Associations) with:
.. code-block:: none
$ show vpn ipsec sa
Peer ID / IP Local ID / IP
------------ -------------
198.51.100.243 203.0.113.46
Tunnel State Bytes Out/In Encrypt Hash NAT-T A-Time L-Time Proto
------ ----- ------------- ------- ---- ----- ------ ------ -----
0 up 0.0/0.0 aes256 sha256 no 1647 3600 all
1 up 0.0/0.0 aes256 sha256 no 865 3600 all
That looks good - we defined 2 tunnels and they're both up and running.

733
docs/configuration/nat/nat44.rst Normal file
View File

@ -0,0 +1,733 @@
.. _nat44:
#####
NAT44
#####
:abbr:`NAT (Network Address Translation)` is a common method of
remapping one IP address space into another by modifying network address
information in the IP header of packets while they are in transit across
a traffic routing device. The technique was originally used as a
shortcut to avoid the need to readdress every host when a network was
moved. It has become a popular and essential tool in conserving global
address space in the face of IPv4 address exhaustion. One
Internet-routable IP address of a NAT gateway can be used for an entire
private network.
IP masquerading is a technique that hides an entire IP address space,
usually consisting of private IP addresses, behind a single IP address
in another, usually public address space. The hidden addresses are
changed into a single (public) IP address as the source address of the
outgoing IP packets so they appear as originating not from the hidden
host but from the routing device itself. Because of the popularity of
this technique to conserve IPv4 address space, the term NAT has become
virtually synonymous with IP masquerading.
As network address translation modifies the IP address information in
packets, NAT implementations may vary in their specific behavior in
various addressing cases and their effect on network traffic. The
specifics of NAT behavior are not commonly documented by vendors of
equipment containing NAT implementations.
The computers on an internal network can use any of the addresses set
aside by the :abbr:`IANA (Internet Assigned Numbers Authority)` for
private addressing (see :rfc:`1918`). These reserved IP addresses are
not in use on the Internet, so an external machine will not directly
route to them. The following addresses are reserved for private use:
* 10.0.0.0 to 10.255.255.255 (CIDR: 10.0.0.0/8)
* 172.16.0.0 to 172.31.255.255 (CIDR: 172.16.0.0/12)
* 192.168.0.0 to 192.168.255.255 (CIDR: 192.168.0.0/16)
If an ISP deploys a :abbr:`CGN (Carrier-grade NAT)`, and uses
:rfc:`1918` address space to number customer gateways, the risk of
address collision, and therefore routing failures, arises when the
customer network already uses an :rfc:`1918` address space.
This prompted some ISPs to develop a policy within the :abbr:`ARIN
(American Registry for Internet Numbers)` to allocate new private
address space for CGNs, but ARIN deferred to the IETF before
implementing the policy indicating that the matter was not a typical
allocation issue but a reservation of addresses for technical purposes
(per :rfc:`2860`).
IETF published :rfc:`6598`, detailing a shared address space for use in
ISP CGN deployments that can handle the same network prefixes occurring
both on inbound and outbound interfaces. ARIN returned address space to
the :abbr:`IANA (Internet Assigned Numbers Authority)` for this
allocation.
The allocated address block is 100.64.0.0/10.
Devices evaluating whether an IPv4 address is public must be updated to
recognize the new address space. Allocating more private IPv4 address
space for NAT devices might prolong the transition to IPv6.
Overview
========
Different NAT Types
-------------------
.. _source-nat:
SNAT
^^^^
:abbr:`SNAT (Source Network Address Translation)` is the most common
form of :abbr:`NAT (Network Address Translation)` and is typically
referred to simply as NAT. To be more correct, what most people refer
to as :abbr:`NAT (Network Address Translation)` is actually the process
of :abbr:`PAT (Port Address Translation)`, or NAT overload. SNAT is
typically used by internal users/private hosts to access the Internet
- the source address is translated and thus kept private.
.. _destination-nat:
DNAT
^^^^
:abbr:`DNAT (Destination Network Address Translation)` changes the
destination address of packets passing through the router, while
:ref:`source-nat` changes the source address of packets. DNAT is
typically used when an external (public) host needs to initiate a
session with an internal (private) host. A customer needs to access a
private service behind the routers public IP. A connection is
established with the routers public IP address on a well known port and
thus all traffic for this port is rewritten to address the internal
(private) host.
.. _bidirectional-nat:
Bidirectional NAT
^^^^^^^^^^^^^^^^^
This is a common scenario where both :ref:`source-nat` and
:ref:`destination-nat` are configured at the same time. It's commonly
used then internal (private) hosts need to establish a connection with
external resources and external systems need to access internal
(private) resources.
NAT, Routing, Firewall Interaction
----------------------------------
There is a very nice picture/explanation in the Vyatta documentation
which should be rewritten here.
NAT Ruleset
-----------
:abbr:`NAT (Network Address Translation)` is configured entirely on a
series of so called `rules`. Rules are numbered and evaluated by the
underlying OS in numerical order! The rule numbers can be changes by
utilizing the :cfgcmd:`rename` and :cfgcmd:`copy` commands.
.. note:: Changes to the NAT system only affect newly established
connections. Already established connections are not affected.
.. hint:: When designing your NAT ruleset leave some space between
consecutive rules for later extension. Your ruleset could start with
numbers 10, 20, 30. You thus can later extend the ruleset and place
new rules between existing ones.
Rules will be created for both :ref:`source-nat` and
:ref:`destination-nat`.
For :ref:`bidirectional-nat` a rule for both :ref:`source-nat` and
:ref:`destination-nat` needs to be created.
.. _traffic-filters:
Traffic Filters
---------------
Traffic Filters are used to control which packets will have the defined
NAT rules applied. Five different filters can be applied within a NAT
rule.
* **outbound-interface** - applicable only to :ref:`source-nat`. It
configures the interface which is used for the outside traffic that
this translation rule applies to.
Example:
.. code-block:: none
set nat source rule 20 outbound-interface eth0
* **inbound-interface** - applicable only to :ref:`destination-nat`. It
configures the interface which is used for the inside traffic the
translation rule applies to.
Example:
.. code-block:: none
set nat destination rule 20 inbound-interface eth1
* **protocol** - specify which types of protocols this translation rule
applies to. Only packets matching the specified protocol are NATed.
By default this applies to `all` protocols.
Example:
* Set SNAT rule 20 to only NAT TCP and UDP packets
* Set DNAT rule 20 to only NAT UDP packets
.. code-block:: none
set nat source rule 20 protocol tcp_udp
set nat destination rule 20 protocol udp
* **source** - specifies which packets the NAT translation rule applies
to based on the packets source IP address and/or source port. Only
matching packets are considered for NAT.
Example:
* Set SNAT rule 20 to only NAT packets arriving from the 192.0.2.0/24
network
* Set SNAT rule 30 to only NAT packets arriving from the 203.0.113.0/24
network with a source port of 80 and 443
.. code-block:: none
set nat source rule 20 source address 192.0.2.0/24
set nat source rule 30 source address 203.0.113.0/24
set nat source rule 30 source port 80,443
* **destination** - specify which packets the translation will be
applied to, only based on the destination address and/or port number
configured.
.. note:: If no destination is specified the rule will match on any
destination address and port.
Example:
* Configure SNAT rule (40) to only NAT packets with a destination
address of 192.0.2.1.
.. code-block:: none
set nat source rule 40 destination address 192.0.2.1
Address Conversion
------------------
Every NAT rule has a translation command defined. The address defined
for the translation is the address used when the address information in
a packet is replaced.
Source Address
^^^^^^^^^^^^^^
For :ref:`source-nat` rules the packets source address will be replaced
with the address specified in the translation command. A port
translation can also be specified and is part of the translation
address.
.. note:: The translation address must be set to one of the available
addresses on the configured `outbound-interface` or it must be set to
`masquerade` which will use the primary IP address of the
`outbound-interface` as its translation address.
.. note:: 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
private 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:
* Define a discrete source IP address of 100.64.0.1 for SNAT rule 20
* Use address `masquerade` (the interfaces primary address) on rule 30
* For a large amount of private machines behind the NAT your address
pool might to be bigger. Use any address in the range 100.64.0.10 -
100.64.0.20 on SNAT rule 40 when doing the translation
.. code-block:: none
set nat source rule 20 translation address 100.64.0.1
set nat source rule 30 translation address 'masquerade'
set nat source rule 40 translation address 100.64.0.10-100.64.0.20
Destination Address
^^^^^^^^^^^^^^^^^^^
For :ref:`destination-nat` rules the packets destination address will be
replaced by the specified address in the `translation address` command.
Example:
* DNAT rule 10 replaces the destination address of an inbound packet
with 192.0.2.10
.. code-block:: none
set nat destination rule 10 translation address 192.0.2.10
Configuration Examples
======================
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:
.. code-block:: none
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:: none
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 hyphen between two IP
addresses:
.. code-block:: none
set nat source rule 100 translation address '203.0.113.32-203.0.113.63'
.. _avoidng_leaky_nat:
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.
.. _hairpin_nat_reflection:
Hairpin NAT/NAT Reflection
--------------------------
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 referred to as NAT Reflection or Hairpin NAT.
Example:
* Redirect Microsoft RDP traffic from the outside (WAN, external) world
via :ref:`destination-nat` in rule 100 to the internal, private host
192.0.2.40.
* Redirect Microsoft RDP traffic from the internal (LAN, private)
network via :ref:`destination-nat` in rule 110 to the internal,
private host 192.0.2.40. We also need a :ref:`source-nat` rule 110 for
the reverse path of the traffic. The internal network 192.0.2.0/24 is
reachable via interface `eth0.10`.
.. code-block:: none
set nat destination rule 100 description 'Regular destination NAT from external'
set nat destination rule 100 destination port '3389'
set nat destination rule 100 inbound-interface 'pppoe0'
set nat destination rule 100 protocol 'tcp'
set nat destination rule 100 translation address '192.0.2.40'
set nat destination rule 110 description 'NAT Reflection: INSIDE'
set nat destination rule 110 destination port '3389'
set nat destination rule 110 inbound-interface 'eth0.10'
set nat destination rule 110 protocol 'tcp'
set nat destination rule 110 translation address '192.0.2.40'
set nat source rule 110 description 'NAT Reflection: INSIDE'
set nat source rule 110 destination address '192.0.2.0/24'
set nat source rule 110 outbound-interface 'eth0.10'
set nat source rule 110 protocol 'tcp'
set nat source rule 110 source address '192.0.2.0/24'
set nat source rule 110 translation address 'masquerade'
Which results in a configuration of:
.. code-block:: none
vyos@vyos# show nat
destination {
rule 100 {
description "Regular destination NAT from external"
destination {
port 3389
}
inbound-interface pppoe0
protocol tcp
translation {
address 192.0.2.40
}
}
rule 110 {
description "NAT Reflection: INSIDE"
destination {
port 3389
}
inbound-interface eth0.10
protocol tcp
translation {
address 192.0.2.40
}
}
}
source {
rule 110 {
description "NAT Reflection: INSIDE"
destination {
address 192.0.2.0/24
}
outbound-interface eth0.10
protocol tcp
source {
address 192.0.2.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:
https://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers
Our configuration commands would be:
.. code-block:: none
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:: none
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:: none
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:: none
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.
Here's an extract of a simple 1-to-1 NAT configuration with one internal
and one external interface:
.. code-block:: none
set interfaces ethernet eth0 address '192.168.1.1/24'
set interfaces ethernet eth0 description 'Inside interface'
set interfaces ethernet eth1 address '192.0.2.30/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 '192.0.2.30'
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 '192.0.2.30'
Firewall rules are written as normal, using the internal IP address as
the source of outbound rules and the destination of inbound rules.
NAT before VPN
--------------
Some application service providers (ASPs) operate a VPN gateway to
provide access to their internal resources, and require that a
connecting organisation translate all traffic to the service provider
network to a source address provided by the ASP.
Example Network
^^^^^^^^^^^^^^^
Here's one example of a network environment for an ASP.
The ASP requests that all connections from this company should come from
172.29.41.89 - an address that is assigned by the ASP and not in use at
the customer site.
.. figure:: /_static/images/nat_before_vpn_topology.png
:scale: 100 %
:alt: NAT before VPN Topology
NAT before VPN Topology
Configuration
^^^^^^^^^^^^^
The required configuration can be broken down into 4 major pieces:
* A dummy interface for the provider-assigned IP;
* NAT (specifically, Source NAT);
* IPSec IKE and ESP Groups;
* IPSec VPN tunnels.
Dummy interface
"""""""""""""""
The dummy interface allows us to have an equivalent of the Cisco IOS
Loopback interface - a router-internal interface we can use for IP
addresses the router must know about, but which are not actually
assigned to a real network.
We only need a single step for this interface:
.. code-block:: none
set interfaces dummy dum0 address '172.29.41.89/32'
NAT Configuration
"""""""""""""""""
.. code-block:: none
set nat source rule 110 description 'Internal to ASP'
set nat source rule 110 destination address '172.27.1.0/24'
set nat source rule 110 outbound-interface 'any'
set nat source rule 110 source address '192.168.43.0/24'
set nat source rule 110 translation address '172.29.41.89'
set nat source rule 120 description 'Internal to ASP'
set nat source rule 120 destination address '10.125.0.0/16'
set nat source rule 120 outbound-interface 'any'
set nat source rule 120 source address '192.168.43.0/24'
set nat source rule 120 translation address '172.29.41.89'
IPSec IKE and ESP
"""""""""""""""""
The ASP has documented their IPSec requirements:
* IKE Phase:
* aes256 Encryption
* sha256 Hashes
* ESP Phase:
* aes256 Encryption
* sha256 Hashes
* DH Group 14
Additionally, we want to use VPNs only on our eth1 interface (the
external interface in the image above)
.. code-block:: none
set vpn ipsec ike-group my-ike ikev2-reauth 'no'
set vpn ipsec ike-group my-ike key-exchange 'ikev1'
set vpn ipsec ike-group my-ike lifetime '7800'
set vpn ipsec ike-group my-ike proposal 1 dh-group '14'
set vpn ipsec ike-group my-ike proposal 1 encryption 'aes256'
set vpn ipsec ike-group my-ike proposal 1 hash 'sha256'
set vpn ipsec esp-group my-esp compression 'disable'
set vpn ipsec esp-group my-esp lifetime '3600'
set vpn ipsec esp-group my-esp mode 'tunnel'
set vpn ipsec esp-group my-esp pfs 'disable'
set vpn ipsec esp-group my-esp proposal 1 encryption 'aes256'
set vpn ipsec esp-group my-esp proposal 1 hash 'sha256'
set vpn ipsec ipsec-interfaces interface 'eth1'
IPSec VPN Tunnels
"""""""""""""""""
We'll use the IKE and ESP groups created above for this VPN. Because we
need access to 2 different subnets on the far side, we will need two
different tunnels. If you changed the names of the ESP group and IKE
group in the previous step, make sure you use the correct names here
too.
.. code-block:: none
set vpn ipsec site-to-site peer 198.51.100.243 authentication mode 'pre-shared-secret'
set vpn ipsec site-to-site peer 198.51.100.243 authentication pre-shared-secret 'PASSWORD IS HERE'
set vpn ipsec site-to-site peer 198.51.100.243 connection-type 'initiate'
set vpn ipsec site-to-site peer 198.51.100.243 default-esp-group 'my-esp'
set vpn ipsec site-to-site peer 198.51.100.243 ike-group 'my-ike'
set vpn ipsec site-to-site peer 198.51.100.243 ikev2-reauth 'inherit'
set vpn ipsec site-to-site peer 198.51.100.243 local-address '203.0.113.46'
set vpn ipsec site-to-site peer 198.51.100.243 tunnel 0 local prefix '172.29.41.89/32'
set vpn ipsec site-to-site peer 198.51.100.243 tunnel 0 remote prefix '172.27.1.0/24'
set vpn ipsec site-to-site peer 198.51.100.243 tunnel 1 local prefix '172.29.41.89/32'
set vpn ipsec site-to-site peer 198.51.100.243 tunnel 1 remote prefix '10.125.0.0/16'
Testing and Validation
""""""""""""""""""""""
If you've completed all the above steps you no doubt want to see if it's
all working.
Start by checking for IPSec SAs (Security Associations) with:
.. code-block:: none
$ show vpn ipsec sa
Peer ID / IP Local ID / IP
------------ -------------
198.51.100.243 203.0.113.46
Tunnel State Bytes Out/In Encrypt Hash NAT-T A-Time L-Time Proto
------ ----- ------------- ------- ---- ----- ------ ------ -----
0 up 0.0/0.0 aes256 sha256 no 1647 3600 all
1 up 0.0/0.0 aes256 sha256 no 865 3600 all
That looks good - we defined 2 tunnels and they're both up and running.

127
docs/configuration/nat/nat66.rst Normal file
View File

@ -0,0 +1,127 @@
.. _nat66:
############
NAT66(NPTv6)
############
:abbr:`NPTv6 (IPv6-to-IPv6 Network Prefix Translation)` is an address translation technology based
on IPv6 networks, used to convert an IPv6 address prefix in an IPv6 message into another IPv6
address prefix. We call this address translation method NAT66. Devices that support the NAT66
function are called NAT66 devices, which can provide NAT66 source and destination address
translation functions.
Overview
========
Different NAT Types
-------------------
.. _source-nat66:
SNAT66
^^^^^^
:abbr:`SNPTv6 (Source IPv6-to-IPv6 Network Prefix Translation)` The conversion function is mainly used in
the following scenarios:
* A single internal network and external network. Use the NAT66 device to connect a single internal
network and public network, and the hosts in the internal network use IPv6 address prefixes that
only support routing within the local range. When a host in the internal network accesses the
external network, the source IPv6 address prefix in the message will be converted into a
global unicast IPv6 address prefix by the NAT66 device.
* Redundancy and load sharing. There are multiple NAT66 devices at the edge of an IPv6 network
to another IPv6 network. The path through the NAT66 device to another IPv6 network forms an
equivalent route, and traffic can be load-shared on these NAT66 devices. In this case, you
can configure the same source address translation rules on these NAT66 devices, so that any
NAT66 device can handle IPv6 traffic between different sites.
* Multi-homed. In a multi-homed network environment, the NAT66 device connects to an
internal network and simultaneously connects to different external networks. Address
translation can be configured on each external network side interface of the NAT66
device to convert the same internal network address into different external network
addresses, and realize the mapping of the same internal address to multiple external addresses.
.. _destination-nat66:
DNAT66
^^^^^^
The :abbr:`DNPTv6 (Destination IPv6-to-IPv6 Network Prefix Translation)` destination address translation
function is used in scenarios where the server in the internal network provides services to the external
network, such as providing Web services or FTP services to the external network. By configuring the mapping
relationship between the internal server address and the external network address on the external network
side interface of the NAT66 device, external network users can access the internal network server through
the designated external network address.
Prefix Conversion
------------------
Source Prefix
^^^^^^^^^^^^^
Every SNAT66 rule has a translation command defined. The prefix defined
for the translation is the prefix used when the address information in
a packet is replaced.、
The :ref:`source-nat66` rule replaces the source address of the packet and calculates the
converted address using the prefix specified in the rule.
Example:
* Convert the address prefix of a single `fc01::/64` network to `fc00::/64`
* Output from `eth0` network interface
.. code-block:: none
set nat66 source rule 1 outbound-interface 'eth0'
set nat66 source rule 1 source prefix 'fc01::/64'
set nat66 source rule 1 translation prefix 'fc00::/64'
Destination Prefix
^^^^^^^^^^^^^^^^^^
For the :ref:`destination-nat66` rule, the destination address of the packet is
replaced by the address calculated from the specified address or prefix in the
`translation address` command
Example:
* Convert the address prefix of a single `fc00::/64` network to `fc01::/64`
* Input from `eth0` network interface
.. code-block:: none
set nat66 destination rule 1 inbound-interface 'eth0'
set nat66 destination rule 1 destination address 'fc00::/64'
set nat66 destination rule 1 translation address 'fc01::/64'
Configuration Examples
======================
Use the following topology to build a nat66 based isolated network between internal
and external networks (dynamic prefix is not supported):
.. figure:: /_static/images/vyos_1_4_nat66_simple.png
:alt: VyOS NAT66 Simple Configure
R1:
.. code-block:: none
set interfaces ethernet eth0 ipv6 address autoconf
set interfaces ethernet eth1 address 'fc01::1/64'
set nat66 destination rule 1 destination address 'fc00:470:f1cd:101::/64'
set nat66 destination rule 1 inbound-interface 'eth0'
set nat66 destination rule 1 translation address 'fc01::/64'
set nat66 source rule 1 outbound-interface 'eth0'
set nat66 source rule 1 source prefix 'fc01::/64'
set nat66 source rule 1 translation prefix 'fc00:470:f1cd:101::/64'
R2:
.. code-block:: none
set interfaces bridge br1 address 'fc01::2/64'
set interfaces bridge br1 member interface eth0
set interfaces bridge br1 member interface eth1
set protocols static route6 ::/0 next-hop fc01::1
set service router-advert interface br1 prefix ::/0

69
docs/configuration/nat/nptv6.rst
View File

@ -1,69 +0,0 @@
.. include:: /_include/need_improvement.txt
.. _nptv6:
#####
NPTv6
#####
:abbr:`NPTv6 (Network Prefix Translation)` is a form of NAT for IPv6. It's
described in :rfc:`6296`.
**Usage**
NPTv6 is very useful for IPv6 multihoming. It is also commonly used when the
external IPv6 prefix is dynamic, as it prevents the need for renumbering of
internal hosts when the extern prefix changes.
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:: none
set rule 10 source prefix 'fc00:dead:beef::/48'
set rule 10 outbound-interface 'eth1'
set rule 10 translation prefix '2001:db8:e1::/48'
set rule 20 source prefix 'fc00:dead:beef::/48'
set rule 20 outbound-interface 'eth2'
set rule 20 translation prefix '2001:db8:e2::/48'
Resulting in the following ip6tables rules:
.. code-block:: none
Chain VYOS_DNPT_HOOK (1 references)
pkts bytes target prot opt in out source destination
0 0 NETMAP all eth1 any anywhere 2001:db8:e1::/48 to:fc00:dead:beef::/48
0 0 NETMAP all eth2 any anywhere 2001:db8:e2::/48 to: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 NETMAP all any eth1 fc00:dead:beef::/48 anywhere to:2001:db8:e1::/48
0 0 NETMAP all any eth2 fc00:dead:beef::/48 anywhere to:2001:db8:e2::/48
0 0 RETURN all any any anywhere anywhere
.. _ULAs: https://en.wikipedia.org/wiki/Unique_local_address