Cisco - Dual WAN Internet with Failover (NAT & Routes)

In the past I had the need to implement failover between two connections to the Internet on the same router, at the time I implemented it using EEM Scripts which wasn’t the most elegant solution, so here I’m going to show you a  a better solution to do this.

Implementing the failover mechanism at first glance seems easier with one router than with two, but that is not the case, with two routers you can have them configured normally with the adition of VRRP/HSRP to do the failover between the routers.

With only one router you are going to have two aditional problems:

• Changing the route from the primary to the secondary Internet access
• Changing the NAT overload to the Interface towards the Secondary ISP / WAN (this was the part that I implemented with EEM scripts)

the first you can easily solve with a floating static route (secondary route) and a track / ip sla (to remove the primary route when the connectivity to the primary ISP is lost).

The second one is harder, you can have two NAT rules with two interfaces towards the two ISPs:

ip nat inside source 130 interface FastEthernet0/0 overload
ip nat inside source 131 interface FastEthernet1/0 overload

but selecting the one as the active one is the tricky part.

Even if the interface towards the primary ISP were to fail and become shutdown, the NAT rule remains active.

The cenario bellow has two different ISPs for for the WAN accesses, but its the sames as having two different connectivities via the same ISP (eg. Primary via Fiber Optic | Secondary via 4G)

Cenario

Logical View

Fisical View

You can download the lab fully implemented here:

• 2015.10.18_Dual WAN Internet with Failover (RT & NAT) (DONE)_v2.zip

it was implemented on GNS3 v1.2.1.

 

Configuration

 

PC1
====================================================
enable
conf t

hostname PC1

interface FastEthernet0/0
description *** Link to CPE1 ***
ip address 192.168.1.1 255.255.255.0
no shutdown

ip route 0.0.0.0 0.0.0.0 192.168.1.254 name DefaultGW
 
do write
 
 
CPE1
====================================================
enable
conf t

hostname CPE1

interface FastEthernet0/0
description *** Link to ISP1 ***
ip address 11.0.0.2 255.255.255.252
ip nat outside
no shutdown
 
interface FastEthernet0/1
description *** Link to ISP2 ***
ip address 22.0.0.2 255.255.255.252
ip nat outside
no shutdown
 
interface FastEthernet1/0
no switchport
description *** Link to PC1 ***
ip address 192.168.1.254 255.255.255.0
ip nat inside
no shutdown

 
!-- Select the Route - via ISP1 or ISP2 -------------------
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! The first route makes all the traffic flow via
! ISP1, but this is conditioned to track 10, that
! detects the  connectivity to ISP1.
! If track 10 fails the route is removed from the
! routing table.
!
!
! The second route has an higher administrative
! distance (worst), and as long as the first rule
! is available this rule is never inserted on
! the routing table (aka floating static route)
!
! If the first route disapears because the track
! failed then the second route is inserted in the
! routing table, and all traffic will flow via ISP2
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

ip route 0.0.0.0 0.0.0.0 11.0.0.1 track 10 name Default-Primary
ip route 0.0.0.0 0.0.0.0 22.0.0.1 250 name Default-Secondary

ip sla 10
icmp-echo 11.0.0.1 source-interface FastEthernet0/0
frequency 5
ip sla schedule 10 life forever start-time now

track 10 ip sla 10 reachability
!show track brief
!show track 10

!-- Change the NAT Interface to Reflect the Active Route --
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! Changing the routes isn't enough, we also
! need to change the NAT rule, because each route
! implies a different exit interface.
!
! To select which NAT rule will be used for each
! route, we used route maps instead of an ACL
! to identify traffic (active the rule).
!
! These route maps match the LAN traffic, plus
! the current next hop to forward the traffic thus
! selecting the correct NAT rule for the current
! active route.
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

ip nat inside source route-map RM-ISP1-PRIMARY interface FastEthernet0/0 overload
ip nat inside source route-map RM-ISP2-PRIMARY interface FastEthernet0/1 overload

access-list 130 remark *** Traffic for The Internet (NAT) ***
access-list 130 permit ip 192.168.1.0 0.0.0.255 any

route-map RM-ISP1-PRIMARY permit 10
match ip address 130
match interface FastEthernet0/0        !--> Match the exit interface of the route

route-map RM-ISP2-PRIMARY permit 10
match ip address 130
match interface FastEthernet0/1        !--> Match the exit interface of the route
!show route-map

!-- Simulate a Failure Along The Way ----------------------
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
! To simulate the failure to see the topology
! changing to the secondary access, we are going
! to use a route to force the track/ip sla to fail.
!
! This route will force all the connectivity test
! traffic destined for ISP1(11.0.0.1) to go to NULL
! which is a black hole. Like this ISP1 will never
! get the icmp echos requests from the ip sla test
! or respond to it, thus simulating a connectivity
! failure towards ISP1
!
! NOTE: It takes a couple of seconds to change
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

!-- Failure Sim + Debug/Tshoot --
do debug ip nat
ping 77.0.0.1
show ip route
!S*    0.0.0.0/0 [1/0] via 11.0.0.1

ip route 11.0.0.1 255.255.255.255 NULL0 name FailureSim

ping 77.0.0.1
show ip route
!S*    0.0.0.0/0 [250/0] via 22.0.0.1

! Both Pings will work but notice that the default
! route is diferent (diferent next hop)

!-- Restore to Normal Operation --
no ip route 11.0.0.1 255.255.255.255 NULL0 name FailureSim
do no debug all

ISP1-PRIMARY
====================================================
enable
conf t

hostname ISP1-PRIMARY

interface FastEthernet0/0
description *** Link to CPE1 ***
ip address 11.0.0.1 255.255.255.252
no shutdown

interface FastEthernet0/1
description *** Link to CPE2 ***
ip address 11.0.0.5 255.255.255.252
no shutdown
 
 
interface FastEthernet1/0
no switchport
description *** Link to ISP2 ***
ip address 22.0.0.6 255.255.255.252
no shutdown

    
ip route 77.0.0.0 255.255.255.248 11.0.0.6 name PublicIPs
ip route 22.0.0.0 255.255.255.252 22.0.0.5 name NatedLAN-viaIPS2

do write

ISP2-SECONDARY
====================================================
enable
conf t

hostname ISP2-SECONDARY

interface FastEthernet0/1
description *** Link to CPE1 ***
ip address 22.0.0.1 255.255.255.252
no shutdown
 
interface FastEthernet0/0
description *** Link to ISP1 ***
ip address 22.0.0.5 255.255.255.252
no shutdown

ip route 0.0.0.0 0.0.0.0 22.0.0.6 name Default
 
do write
 
 
CPE2
====================================================
enable
conf t

hostname CPE2

interface FastEthernet0/1
description *** Link to ISP1 ***
ip address 11.0.0.6 255.255.255.248
no shutdown
 
interface FastEthernet1/0
description *** Link to Internet Server ***
no switchport
ip address 77.0.0.6 255.255.255.248

ip route 0.0.0.0 0.0.0.0 11.0.0.5 name Default

do write

INTERNET SERVER
====================================================
enable
conf t

hostname INTERNET-SERVER

interface FastEthernet0/0
description *** Link to CPE1 ***
ip address 77.0.0.1 255.255.255.248
no shutdown
 
ip route 0.0.0.0 0.0.0.0 77.0.0.6 name Default

do write

Related Links

• http://docwiki.cisco.com/wiki/NAT_failover_with_DUAL_ISP_on_a_router_Configuration_Example

Linux – SSH Reverse Tunnel to Bypass NAT

Have you ever wanted to reach a server via some application, for example ssh, but you couldn’t because the remote computer (LinuxB) was beind NAT, and you didn’t had access to the router (CPE2-NAT) to add a port forwarding:

but if you add another server with a Public IP (LinuxM) in the midlle you can set up a Reverse SSH Tunel between the destination (LinuxB) and the server in the middle (LinuxM) that will forward conection to a local port on LinuxM to the destination port  on LinuxB via the established ssh session that has the reverse/remote tunel configured.

To test the Reverse SSH Tunel to bypass NAT I’m going to do a proof of concept (POC), with some linux (Ubuntu) machines with private addressing, the cenario looks like this:

Linux_M – Middleman
===========================================================

## Hostname ##
sudo nano /etc/hostname
LinuxM
hostname LinuxM
hostname

sudo nano /etc/hosts
127.0.1.1       LinuxM
 
 
## Interfaces ##
sudo ifdown eth0                                                                 
sudo ifconfig eth0 192.168.1.254 netmask 255.255.255.0
sudo ifup eth0                                      

sudo ifdown eth1                                                                 
sudo ifconfig eth1 172.16.1.254 netmask 255.255.255.0
sudo ifup eth1                                      

## IP Forwarding (Routing) ##
sudo  sysctl -w net.ipv4.ip_forward=1

## Activate Gateway Ports ##
sudo nano /etc/ssh/sshd_config
GatewayPorts yes
sudo service ssh stop
sudo service ssh start

#####################################################
# When you forward a TCP port (either locally or
# remotely), by default SSH only listens for
# connections to the forwarded port on the loopback
# address (localhost, 127.0.0.1). This means only
# other programs running on the same host as the
# listening side of the forwarding can connect to
# the forwarded port. This is a security feature,
# since there is no authentication applied to such
# connections. Also, such a forwarded connection is
# potentially insecure, since a portion of it is
# carried over the network in a plain TCP connection
# and not protected by SSH.
#####################################################

       

Linux_B – Destination
===========================================================

## Hostname ##
sudo nano /etc/hostname
LinuxB
hostname LinuxB
hostname

sudo nano /etc/hosts
127.0.1.1       LinuxB
 
 
## Interface ##
sudo ifdown eth0                                                                 
sudo ifconfig eth0 172.16.1.1 netmask 255.255.255.0
sudo ifup eth0                                      

## Route (default) ##
sudo route add default gw 172.16.1.254 eth0

## Reverse/Remote SSH Tunnel ##
ssh -R 10002:localhost:22 lubuntu@172.16.1.254

######################################################
# This sets up the reverse/remote ssh tunnel
# between the destination (LinuxB) and the server
# in the middle (LinuxM) that will forward connection
# on the local port 10002 on LinuxM to the
# destination port 22 LinuxB via the established
# ssh session that has the reverse/remote tunel
# configured.
#
# After this command you will have the reverse/remote
# ssh thunnel configured and the bash/CLI of LinuxM.
#
# YOU MUST MAINTAIN THE BASH/CLI OF LinuxM ON LinuxB
# VIA SSH, FOR THE FORWARDING/TUNNELING TO WORK
#####################################################

At this point you have this:

the reverse/remote ssh tunnel wating for a connection on LinuxM on port 10002 to forward LinuxB on port 22 (ssh)

 

Linux_A – Client
===========================================================

## Hostname ##
sudo nano /etc/hostname
LinuxA
hostname LinuxA
hostname

sudo nano /etc/hosts
127.0.1.1       LinuxA

 
## Interface ##
sudo ifdown eth0                                                                 
sudo ifconfig eth0 192.168.1.1 netmask 255.255.255.0
sudo ifup eth0                                      

## Route (default) ##
sudo route add default gw 192.168.1.254 eth0   

## Connect LinuxM (will forward to LinuxB) ##
## Gateway Ports = ON on LinuxM                ##
ssh lubuntu@192.168.1.254 -p 10002

or

## Connect LinuxM (will not forward to LinuxB) ##
## Gateway Ports = OFF on LinuxM                      ##
ssh lubuntu@192.168.1.254         
ssh lubuntu@localhost -p 10002
######################################################
# Assuming the "Gateway Ports" is OFF, then the
# reverse/remote ssh tunnel will only be accessible
# on LinuxM locally
#
# So in the above commands we first connect via SSH
# to LinuxM, and from there connect local ports of the
# reverse/remote ssh tunnel so that it will forward
# the connection on the local port 10002 of LinuxM
# to the destination port 22 LinuxB
#####################################################

At this point you have this (Gateway Ports = ON):

and you should be in the bash/CLI of LinuxB

 

Related Links:

• http://www.marksanborn.net/howto/bypass-firewall-and-nat-with-reverse-ssh-tunnel/
• http://www.snailbook.com/faq/gatewayports.auto.html
  

 

Cisco IP NAT – Extendable Option

Recently at work I ran across a weird static NAT implemention, where it had the “extendable” key word, and the router had two Internet connections (two public IPs):

ip nat inside source static 10.0.0.1 100.0.0.2 extendable
ip nat inside source static 10.0.0.1 200.0.0.2 extendable

The “extendable” option allows static NAT mappings of one Inside Local Address (private address) to multiple Inside Global addresses (public addresses), the keyword “extendable” is added to the end of the mapping statements. [cisco]

This is a good option for accessing one a server via two Internet connections, the traffic can come from any internet connection, that public address gets translated to the same private address (server address), this raises no ambiguity.

As for traffic started by the server with destination to the Internet, I didn’t found very clear information on how the router handles the ambiguity created by the fact that the SERVER address (private address) can be translated to two public addresses.

So in order two answer this question i did some testing, using the topology above.

 

Testing Conclusions

My conclusions where the following:

The Nat extendable works great in following direction:

• R3->R1 (ISP1 –> SERVER)
• R4->R1 (ISP2 –> SERVER)

because the isn't any ambiguity

But in the inverse direction

• R1->R3 (SERVER –> ISP1)
• R1->R4 (SERVER –> ISP2)

it depends on the on the order of intruduction of the NAT rules,

R2-CFG1 
ip nat inside source static 10.0.0.1 100.0.0.2 extendable - R1->R3 - OK
ip nat inside source static 10.0.0.1 200.0.0.2 extendable - R1->R4 - NOK
or
R2-CFG2 
ip nat inside source static 10.0.0.1 200.0.0.2 extendable - R1->R4 - OK
ip nat inside source static 10.0.0.1 100.0.0.2 extendable - R1->R3 - NOK

where the first introduced NAT rule is the one that works
despite of always having the same order on the running-config

ip nat inside source static 10.0.0.1 100.0.0.2 extendable 
ip nat inside source static 10.0.0.1 200.0.0.2 extendable

My guess, is that it’s that this happens because the first rule is considered the main rule and second rule "extends" it (secondary rule), and when there’s ambiguity it defaults to the main rule. 

   

Topology and Configuration

R1
==========================
hostname R1

interface FastEthernet0/0
ip address 10.0.0.1 255.255.255.0
duplex auto
speed auto
ip route 0.0.0.0 0.0.0.0 10.0.0.254

line con 0
logging synchronous
line aux 0
line vty 0 4
password cisco
login

R2
===========================
hostname R2

interface FastEthernet0/0
ip address 10.0.0.254 255.255.255.0
ip nat inside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet0/1
ip address 100.0.0.1 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!
interface FastEthernet1/0
ip address 200.0.0.1 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto
!        
ip nat inside source static 10.0.0.1 100.0.0.2 extendable
ip nat inside source static 10.0.0.1 200.0.0.2 extendable

R3
==========================
hostname R3

interface FastEthernet0/1
ip address 100.0.0.254 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto

R4
==========================
hostname R4

interface FastEthernet0/1
ip address 100.0.0.254 255.255.255.0
ip nat outside
ip virtual-reassembly
duplex auto
speed auto

Tests – Part 1

Initial NAT Table on R2
--------------------------------------------------------------
R2#show ip nat translations 
Pro Inside global      Inside local       Outside local      Outside global
--- 100.0.0.2          10.0.0.1           ---                ---
--- 200.0.0.2          10.0.0.1           ---                ---

Trying To Ping R3 and R4 from R1 via NAT on R2
--------------------------------------------------------------
R1#ping 100.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/21/40 ms

R1#ping 200.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

NAT Table on R2 after the Pings from R1->R3 / R1->R4
--------------------------------------------------------------
R2#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 100.0.0.2:30      10.0.0.1:30    100.0.0.254:30     100.0.0.254:30
icmp 100.0.0.2:31      10.0.0.1:31        200.0.0.254:31     200.0.0.254:31
--- 100.0.0.2          10.0.0.1           ---                ---
--- 200.0.0.2          10.0.0.1           ---                ---

The ping to R4 didn't work, and you can see why on second translation in the NAT table (the "Inside Global" instead of beeing 200.0.0.2 it’s 100.0.0.2 and R4 does not know network 100.0.0.0/24, so it does not reply)

Trying To Ping R1 from R3 and R4 via NAT
--------------------------------------------------------------
R3#ping 100.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/24/36 ms

R4#ping 200.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/23/32 ms

As you can see in this direction things work great

NAT Table on R2 after the Pings from R3->R1 / R4->R1
--------------------------------------------------------------
R2#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 100.0.0.2:5       10.0.0.1:5         100.0.0.254:5      100.0.0.254:5
icmp 200.0.0.2:7       10.0.0.1:7         200.0.0.254:7      200.0.0.254:7
--- 100.0.0.2          10.0.0.1           ---                ---
--- 200.0.0.2          10.0.0.1           ---                ---

Trying To Ping R3 and R4 from R1 via NAT on R2 (AGAIN)
----------------------------------------------------------
R1#ping 100.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/21/40 ms

R1#ping 200.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

This was just to see if the ping from R3->R1 and R4->R1,
could somehow influence the pings in the opposite direction
from R1->R3 / R1->R4, but no, the result is the same.

 

Tests – Part 2

R2 Config Change – Change the Order of the NAT Rules
--------------------------------------------------------
no ip nat inside source static 10.0.0.1 100.0.0.2 extendable
no ip nat inside source static 10.0.0.1 200.0.0.2 extendable
ip nat inside source static 10.0.0.1 200.0.0.2 extendable
ip nat inside source static 10.0.0.1 100.0.0.2 extendable

As you will see bellow instead of a success ping from R1->R3,
you will see a successful ping from R1->R4, and the running
config looks the same before and after this change:

...
ip nat inside source static 10.0.0.1 100.0.0.2 extendable
ip nat inside source static 10.0.0.1 200.0.0.2 extendable
...   

Initial NAT Table on R2
---------------------------------------------------------------
R2#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
--- 100.0.0.2          10.0.0.1           ---                ---
--- 200.0.0.2          10.0.0.1           ---                ---

Trying To Ping R3 and R4 from R1 via NAT on R2
--------------------------------------------------------------
R1#ping 100.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R1#ping 200.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 24/31/60 ms

NAT Table on R2 after the Pings from R1->R3 / R1->R4
---------------------------------------------------------------
R2#show ip nat translations

Pro Inside global      Inside local       Outside local      Outside global
icmp 200.0.0.2:39      10.0.0.1:39        100.0.0.254:39     100.0.0.254:39
icmp 200.0.0.2:40      10.0.0.1:40    200.0.0.254:40     200.0.0.254:40
--- 200.0.0.2          10.0.0.1           ---                ---
--- 100.0.0.2          10.0.0.1           ---                ---

The ping to R3 didn't work, and you can see why on first translation in the NAT table (the "Inside Global" instead of beeing 100.0.0.2 it’s 200.0.0.2 and R3 does not know network 200.0.0.0/24, so it does not reply)

Trying To Ping R1 from R3 and R4 via NAT
--------------------------------------------------------------
R3#ping 100.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 16/20/24 ms

R4#ping 200.0.0.2

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.2, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 20/23/24 ms

NAT Table on R2 after the Pings from R3->R1 / R4->R1
--------------------------------------------------------------
R2#show ip nat translations

R2#show ip nat translations
Pro Inside global      Inside local       Outside local      Outside global
icmp 100.0.0.2:6       10.0.0.1:6         100.0.0.254:6      100.0.0.254:6
icmp 200.0.0.2:8       10.0.0.1:8         200.0.0.254:8      200.0.0.254:8
--- 200.0.0.2          10.0.0.1           ---                ---
--- 100.0.0.2          10.0.0.1           ---                ---

Trying To Ping R3 and R4 from R1 via NAT on R2 (AGAIN)
--------------------------------------------------------------
R1#ping 100.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 100.0.0.254, timeout is 2 seconds:
.....
Success rate is 0 percent (0/5)

R1#ping 200.0.0.254

Type escape sequence to abort.
Sending 5, 100-byte ICMP Echos to 200.0.0.254, timeout is 2 seconds:
!!!!!
Success rate is 100 percent (5/5), round-trip min/avg/max = 8/20/28

This was just to see if the ping from R3->R1 and R4->R1,
could somehow influence the pings in the opposite direction
from R1->R3 and from R1->R4, but no, the result is the same.

As stated before in the conclusions above:

• R1->R3 (SERVER –> ISP1) –– OK on Tests - Part 1
• R1->R4 (SERVER –> ISP2) –– OK on Tests - Part 2

the order of the introduction off the NAT static matters, because only the first rule is used, because of the ambiguity.

Links

• http://www.ciscopress.com/articles/article.asp?p=25273&seqNum=4
• http://www.cisco.com/en/US/technologies/tk648/tk361/tk438/technologies_white_paper09186a0080091cb9.html
• Example: http://ccie4all.wordpress.com/2013/01/12/nat-with-extendable-keyword/
• Small Example: http://network-101.blogspot.pt/2011/05/nat-extendable-option.html
• http://www.routerie.com/cgi-bin/ultimatebb.cgi?ubb=get_topic;f=50;t=003660
• http://network-101.blogspot.pt/2011/05/nat-extendable-option.html?m=1
  http://www.dslreports.com/forum/r24372553-Nat-Extendable-Command
• http://network-101.blogspot.pt/2011/05/nat-extendable-option.html?m=1