diff options
Diffstat (limited to 'docs/nat.rst')
| -rw-r--r-- | docs/nat.rst | 417 |
1 files changed, 222 insertions, 195 deletions
diff --git a/docs/nat.rst b/docs/nat.rst index 22ed1271..17698c26 100644 --- a/docs/nat.rst +++ b/docs/nat.rst @@ -4,60 +4,65 @@ NAT ### -: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: +: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. +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`). +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. +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. +recognize the new address space. Allocating more private IPv4 address +space for NAT devices might prolong the transition to IPv6. Overview ======== @@ -70,26 +75,28 @@ Different NAT Types 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. +: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. +: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: @@ -97,33 +104,35 @@ 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. +: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. +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. +: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 establiushed ocnnections are not affected. +.. 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. +.. 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`. +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. @@ -133,12 +142,13 @@ For :ref:`bidirectional-nat` a rule for both :ref:`source-nat` and 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 +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. +* **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: @@ -156,8 +166,8 @@ rules applied. Five different filters can be applied within a NAT rule 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 +* **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: @@ -170,15 +180,16 @@ rules applied. Five different filters can be applied within a NAT rule 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. +* **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 192.0.3.0/24 network - with a source port of 80 and 443 + * 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 192.0.3.0/24 + network with a source port of 80 and 443 .. code-block:: none @@ -187,16 +198,17 @@ rules applied. Five different filters can be applied within a NAT rule 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. +* **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. + * Configure SNAT rule (40) to only NAT packets with a destination + address of 192.0.2.1. .. code-block:: none @@ -206,34 +218,36 @@ rules applied. Five different filters can be applied within a NAT rule 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. +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. +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:: 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. +.. 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 +* 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 @@ -251,8 +265,8 @@ 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 +* DNAT rule 10 replaces the destination address of an inbound packet + with 192.0.2.10 .. code-block:: none @@ -268,8 +282,8 @@ To setup SNAT, we need to know: * 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: +In the example used for the Quick Start configuration above, we +demonstrate the following configuration: .. code-block:: none @@ -291,76 +305,84 @@ Which generates the following configuration: } } -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. +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. +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. +Example: For an ~8,000 host network a source NAT pool of 32 IP addresses +is recommended. -A pool of addresses can be defined by using a **-** in the -`set nat source rule [n] translation address` statement. +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' -.. note:: Avoiding "leaky" NAT +.. _avoidng_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). +Avoiding "leaky" NAT +-------------------- -In other words, connection tracking has already observed the connection be -closed and has transition the flow to INVALID to prevent attacks from +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. +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. +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 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`. +* 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 @@ -433,12 +455,12 @@ Which results in a configuration of: 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. +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. +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: @@ -446,9 +468,10 @@ To setup a destination NAT rule we need to gather: * 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 +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: @@ -480,19 +503,21 @@ Which would generate the following NAT destination configuration: } } -.. note:: If forwarding traffic to a different port than it is arriving on, - you may also configure the translation port using +.. 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. +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. +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. +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 @@ -527,19 +552,19 @@ This would generate the following configuration: ---------- 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. +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. +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: +Here's an extract of a simple 1-to-1 NAT configuration with one internal +and one external interface: .. code-block:: none @@ -556,24 +581,24 @@ one external interface: 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. +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. +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. +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 % @@ -596,9 +621,10 @@ The required configuration can be broken down into 4 major pieces: 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. +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: @@ -639,8 +665,8 @@ The ASP has documented their IPSec requirements: * DH Group 14 -Additionally, we want to use VPNs only on our eth1 interface (the external -interface in the image above) +Additionally, we want to use VPNs only on our eth1 interface (the +external interface in the image above) .. code-block:: none @@ -663,10 +689,11 @@ interface in the image above) 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. +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 @@ -685,8 +712,8 @@ step, make sure you use the correct names here too. Testing and Validation """""""""""""""""""""" -If you've completed all the above steps you no doubt want to see if it's all -working. +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: |