nptv6: T2518: Add document support for nat66

4 files changed, 862 insertions, 798 deletions

diff --git a/docs/configuration/nat/index.rst b/docs/configuration/nat/index.rst
index f0f5bd6a..90275226 100644
--- a/docs/configuration/nat/index.rst
+++ b/docs/configuration/nat/index.rst
@@ -8,732 +8,5 @@ NAT
    :maxdepth: 1
    :includehidden:
 
-   nptv6
-
-: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.
+   nat44
+   nat66
diff --git a/docs/configuration/nat/nat44.rst b/docs/configuration/nat/nat44.rst
new file mode 100644
index 00000000..59cee741
--- /dev/null
+++ b/docs/configuration/nat/nat44.rst
@@ -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.
diff --git a/docs/configuration/nat/nat66.rst b/docs/configuration/nat/nat66.rst
new file mode 100644
index 00000000..bcf5570f
--- /dev/null
+++ b/docs/configuration/nat/nat66.rst
@@ -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
diff --git a/docs/configuration/nat/nptv6.rst b/docs/configuration/nat/nptv6.rst
deleted file mode 100644
index c09c8336..00000000
--- a/docs/configuration/nat/nptv6.rst
+++ /dev/null
@@ -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