cancelar
Mostrando los resultados de 
Buscar en lugar de 
Quiere decir: 
cancel
31172
Visitas
10
ÚTIL
17
Respuestas

PREGUNTE A LOS EXPERTOS - Network Address Translation (NAT) en IOS, PIX FW, ASA, VPN 3000 y ACE

ciscomoderator
Community Manager
Community Manager

Bienvenidos a la conversación en CSC en Español. Esta es su oportunidad de aprender y hacer todas las preguntas que tenga acerca de NAT en productos basados en IOS, PIX, Firewalls, ASAs, and VPNs con Ricardo Prado. Ricardo es ingeniero veterano de Soporte de Cisco Latinoamérica especializado en tecnologías de routing y switching. Estudió Ingenieria en Telecomunicaciones en la Universidad Nacional Autónoma de México (UNAM) y tiene varias certificaciones de Cisco incluyendo CCNA, CCNP, CCIP, y CCIE en Routing and Switching (# 21161). Ricardo lleva trabajando en Cisco 7 años, de los cuáles 6 años a formado parte del grupo de asistencia técnica y HTTS. Ricardo tiene amplia experiencia en resolver problemas técnicos acerca de NAT.

Por favor use las estrellas para calificar las respuestas y asi informar a Ricardo que usted ha recibido una respuesta adecuada.

Puede ser que Ricardo no pueda responder cada una de las preguntas debido la cantidad que anticipamos para este evento. Recuerde que usted puede preguntar o seguir haciendo preguntas an la comunidad de Routing & Switching.

Este evento está abierto hasta el 6 de Mayo de 2011.  Visite esta conversación seguido para ver las respuestas a sus preguntas.

2 SOLUCIONES ACEPTADAS

Soluciones aceptadas

Hola Adolfo:

   En la regla de NAT que estás utilizando también se está incluyendo la red a la que pertenecen tus servidores. Las reglas de NAT estático realizan un función de proxy para las resoluciones de ARP, es decir, cuando alguien en la LAN DMZ-RED10 manda una solicitud de ARP (Broadcast) para encontrar la dirección MAC de alguna IP dentro del rango 172.16.10.0/255.255.255.128 el ASA puede y debe contestar con su propia MAC de acuerdo con la configuración de NAT. Eventualmente tanto el equipo que originó el ARP como tu Switch aprenderán que determinada IP está ligada a la MAC del ASA y por lo tanto el tráfico será enviado al firewall. El ASA no puede redirigir el tráfico que recibe en su interfaz para que salga por la misma interfaz por lo que los paquetes son tirados. Necesitas modificar tu regla de NAT para que sea más específica y evites que el ASA haga proxy-arp para las direcciones IP de tus servidores, por ejemplo si tu red interna sólo incluye las IP’s 172.16.5.0/255.255.255.0, la configuración más adecuada sería:

static (inside,DMZ-RED10) 172.16.5.0 172.16.5.0 netmask 255.255.255.0

   Saludos,

Ricardo.

Ver la solución en mensaje original publicado

Hola Daniel:

   Para entender el uso de esta línea en la configuración del route-map hay que tomar en cuenta el orden de operación del NAT dentro de un ruteador con IOS. La forma simplificada la comenté en una pregunta anterior y depende de la dirección que el tráfico esté tomando con respecto a las interfaces INSIDE y OUTSIDE:

Dirección INSIDE->OUTSIDE:  PBR-> RUTEO -> NAT

Dirección OUTSIDE -> INSIDE:  NAT-> PBR -> RUTEO

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

   En este caso, si revisas la configuración de las dos reglas de NAT estas son prácticamente iguales, por lo tanto necesitamos diferenciar entre una regla y otra con el fin de que la traducción que corresponde al proveedor de servicios 1 se lleve a cabo sólo cuando el tráfico salga por el enlace que va hacia ese proveedor y de igual manera con el proveedor 2. En este sentido, la configuración del route-map cumple dos objetivos: verificar que el tráfico correcto sea traducido (match ip address) y además hay que confirmar que el tráfico se va a enrutar por la interfaz que corresponde al proveedor adecuado. Si alguna de estas dos condiciones no se cumplen, la siguiente regla de NAT disponible es evaluada.

   En resumen, cuando el paquete en dirección INSIDE -> OUTSIDE llega al ruteador el destino se compara con la tabla de ruteo y se envía al proveedor que corresponda, una vez efectuado el ruteo, la regla de NAT es evaluada tanto en el tipo de tráfico que se quiere traducir así como la interfaz de salida que se está utilizando para enviar el tráfico al proveedor si las dos son correctas el proceso de NAT se dispara y se ejecuta la traducción que corresponde.

   Saludos,

Ricardo.

Ver la solución en mensaje original publicado

17 RESPUESTAS 17

jose cortes
Level 1
Level 1

buen dia Ricardo,

Esta primera pregunta se relaciona con los conceptos de Outside Global, Outside Local, Inside Global e Inside Local. Siempre he tenido dudas frente a los que estas direcciones representan. Podrias aclararme que es y cual es la funcion de cada una de estas deficiniciones en el proceso de NAT. Un ejemplo seria bien recibido.

Gracias.

Hola José:

   Gracias por participar en este evento. En efecto, en los ruteadores los conceptos de inside/outside local/global son un poco confusos, hay diversas formas de interpretarlos, la manera en la que yo entiendo más estos conceptos es la siguiente:

INSIDE -> Cuando se menciona el concepto "inside" hay que asumir que se refiere al tráfico generado en la LAN, ahí vas a ver todas las IP's de tu LAN que estén involucradas en una traducción de NAT.

OUTSIDE -> Aquí hacemos referencia al tráfico fuera de tu LAN, es decir vamos a ver todas las IP's que son ajenas a tu red, por ejemplo direcciones públicas.

LOCAL -> Este concepto lo podemos tomar como un "punto de vista" dentro de la red que tú controlas (local), es decir, nos podemos preguntar: ¿Cómo se vería determinada dirección IP desde mi red LOCAL?

GLOBAL -> Contrario al elemento anterior, aquí el "punto de vista" es en la red que tú no controlas, por ejemplo Internet. La pregunta sería: ¿Cómo se vería determinada dirección IP desde la red GLOBAL?

   Aquí hay un par de ejemplos. Imaginemos una conexión sencilla hacia Internet. Utilizamos una regla de NAT dinámica que re-utiliza puertos (también llamada PAT) y mandamos un paquete a la dirección en Internet 4.2.2.2. Nuestra LAN tiene asignada la red 192.168.1.0/24. Aquí está la configuración:

interface Ethernet0/0
ip address 192.168.1.1 255.255.255.0
ip nat inside
!
interface Ethernet1/0
ip address 21.21.21.1 255.255.255.0
ip nat outside

ip nat inside source list 120 interface Ethernet1/0 overload

access-list 120 permit ip 192.168.1.0 0.0.0.255 any

Después de que se efectúa la traducción vemos lo siguiente en la tabla de traducciones:

ROUTER1#s ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 21.21.21.1:123    192.168.1.50:123   4.2.2.2:123        4.2.2.2:123

   Como puedes observar, las primeras dos columnas (después del protocolo) incluyen el concepto INSIDE, por lo que nos muestran las IP's de la red LAN, las últimas dos columnas manejan el concepto de OUTSIDE por lo que vemos las IP's de Internet, en este caso la IP 4.2.2.2.

Para la columna INSIDE GLOBAL, nos hacemos la pregunta: ¿Cómo se ve mi dirección 192.168.1.50 desde la red Global (INTERNET)? La respuesta es 21.21.21.1, en otras palabras Internet "ve" mi tráfico como la IP pública de mi interfaz.

Para la columna INSIDE LOCAL, nos hacemos la pregunta: ¿Cómo se ve mi dirección 192.168.1.50 desde mi red Local (LAN)? La respuesta es 192.168.1.50, esto es obvio puesto que dentro de mi red LAN sólo tengo esa IP privada para ese equipo.

   Si observas las dos columnas OUTSIDE la IP que vemos siempre es 4.2.2.2, la razón es que tanto desde mi red LAN como desde Internet el equipo remoto se "ve" como 4.2.2.2 en todo momento, porque no hay una traducción para esa IP en el ruteador.

   Ahora vamos a asumir que por política de nuestra empresa la IP pública 4.2.2.2 necesita ser vista como local con la IP 192.168.1.10, porque nuestro equipo 192.168.1.50 no puede enrutar tráfico fuera de nuestra red. Para hacer esto hacemos los siguientes cambios:

ip nat outside source static 4.2.2.2 192.168.1.10 extendable

ip route 192.168.1.10 255.255.255.255 21.21.21.2

Ahora el ruteador va a realizar dos traducciones, una para nuestra IP privada y otra para la IP de Internet. Después de la traducción vemos esto:

ROUTER1#s ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
icmp 21.21.21.1:1115   192.168.1.50:1115  192.168.1.10:1115  4.2.2.2:1115
--- ---                ---                192.168.1.10       4.2.2.2

Para el primer renglón de nuestra tabla de traducciones tenemos que las primeras dos columnas después del protocolo son iguales al ejemplo anterior, pero las últimas dos sí tienen información distinta:

Para la columna OUTSIDE GLOBAL, nos hacemos la pregunta: ¿Cómo se ve la dirección 4.2.2.2 desde la red Global (Internet)? La respuesta es obvia, desde Internet la IP pública sigue siendo 4.2.2.2.

Para la columna OUTSIDE LOCAL, nos hacemos la pregunta: ¿Cómo se ve la dirección 4.2.2.2 desde mi red Local (LAN)? La respuesta es la IP 192.168.1.10, que era lo que se necesitaba.

El último renglón es una entrada que se genera siempre que habilitamos una traducción estática y nos indica qué tipo de traducción se va a llevar acabo sobre determinada IP.

Espero que esta explicación te sirva para entender un poco más estos conceptos.

Saludos,

Ricardo.

Gracias por tu respuesta Ricardo, me parece muy clara la explicacion que me das.

ahora bien, tengo una duda puntual sobre la diferencia que existe entre NAT y PAT. Tengo entendido, corrigeme si estoy equivocado, que el NAT me permite traducir de una Direccion a otra, independiente del puerto que utilice es decir, si yo hago NAT sobre una IP el puerto, digamos Telnet (e.g 10.10.10.10 : 23), se mantiene pero ahora el socket queda asociado con la IP de la traduccion (e.g 4.2.2.2 : 23), el PAT que diferencias, ventajas y desventajas tiene y en que casos es recomendable.

gracias.

Jose

Hola José:

   Básicamente el NAT dinámico es una regla de configuración que entra en efecto cuando es requerida (dinámicamente) y dependiendo de si existe el modificador "overload" se puede llamar PAT (Port Address Translation) pero sigue siendo una regla de NAT dinámica. Para explicar mejor las diferencias entre un NAT dinámico y un NAT dinámico con PAT podemos revisar los siguientes ejemplos. Tenemos esta configuración de NAT dinámico sin PAT:

interface Ethernet0/0
ip address 192.168.1.1 255.255.255.0
ip nat inside


interface Ethernet1/0
ip address 21.21.21.1 255.255.255.0
ip nat outside

ip nat pool NATPOOL 21.21.21.5 21.21.21.5 netmask 255.255.255.0
ip nat inside source list 120 pool NATPOOL

access-list 120 permit ip 192.168.1.0 0.0.0.255 any

   En esta configuración utilizo una pool con una sóla dirección ya que la opción sin "overload" sólo está permitida con pools. Al realizar una traducción observamos lo siguiente en la tabla de NAT:

ROUTER1#s ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
--- 21.21.21.5         192.168.1.50       ---                ---

   Lo que la salida anterior nos está diciendo es que NAT asignó dinámicamente (la IP 192.168.1.50 fue la primera que solicitó acceso a una IP pública) todos los puertos de la IP de la pool 21.21.21.5. Si observas, la entrada en la tabla de NAT es exactamente igual a lo que obtendríamos con una traducción estática, que también asigna todos los puertos disponibles en una dirección IP. La diferencia es que con la regla estática tú tienes que determinar qué IP privada va a tener asignada una IP pública y con el NAT dinámico cualquier IP privada puede tomar una IP de la pool. Esta traducción permanece en la tabla durante 24 horas o hasta que se borre la tabla de traducciones. Como puedes ver si tienes pocas direcciones IP en tu pool esta opción no es muy práctica ya que pocos dispositivos en tu LAN tendrían una traducción, se necesitan tantas direcciones globales como dispositivos en la LAN para que este tipo de configuración sea útil. Otro punto es que cuando se tiene este tipo de entrada en la tabla de traducciones, la traducción es bidireccional, una vez asignada la IP de la pool a la IP privada, cualquiera en una red externa podría usar esta dirección pública para accesar a este equipo en tu LAN si no se tienen los filtros adecuados.

   Cuando usamos la opción de "overload" lo que estamos haciendo es decirle al equipo que utilice todos los puertos disponibles de la IP de la interfaz o la pool, es decir, estamos re-utilizando la misma IP pública para todos los equipos dentro de la LAN:

interface Ethernet0/0
ip address 192.168.1.1 255.255.255.0
ip nat inside


interface Ethernet1/0
ip address 21.21.21.1 255.255.255.0
ip nat outside

ip nat pool NATPOOL 21.21.21.5 21.21.21.5 netmask 255.255.255.0
ip nat inside source list 120 pool NATPOOL overload

access-list 120 permit ip 192.168.1.0 0.0.0.255 any

   Cuando se generan traducciones observamos lo siguiente:

ROUTER1#s ip nat trans
Pro Inside global      Inside local       Outside local      Outside global
udp 21.21.21.5:160    192.168.1.52:160   4.2.2.2:160        4.2.2.2:160
icmp 21.21.21.5:6366   192.168.1.52:6366  4.2.2.2:6366       4.2.2.2:6366
tcp 21.21.21.5:11001   192.168.1.50:11001 4.2.2.2:23         4.2.2.2:23
udp 21.21.21.5:4634   192.168.1.51:4634  4.2.2.2:4634       4.2.2.2:4634
icmp 21.21.21.5:6761   192.168.1.51:6761  4.2.2.2:6761       4.2.2.2:6761

   Aquí tenemos tres equipos (192.168.1.50, 192.168.1.51, 192.168.1.52) que están utilizando la misma IP de la pool (21.21.21.5) y mandando tráfico a la misma IP global (4.2.2.2). La diferencia entre cada sesión es el puerto de origen que se está ocupando, estamos re-utilizando la misma IP. Cuando tenemos pocas direcciones IP's globales a nuestra disposición esta es la mejor opción puesto que nos permite utilizar todos los puertos disponibles para permitir a muchos más equipos a tener acceso a la red global (65535 puertos por IP). Dada la escasa disponibilidad de direcciones IPv4 públicas, PAT es preferible para conservar este recurso tan limitado. Otro punto a favor es que, a pesar de que la traducción es bi-direccional, generalmente el puerto de origen que los equipos utilizan es un puerto aleatorio arriba de 1024, sobre el cual el equipo no tiene un servicio y no está obligado a responder a ningún acceso que no sea el que se solicitó originalmente.

   Saludos,

Ricardo.

Adolfo Suarez
Level 1
Level 1

Hola Ricardo,

Tengo esta topología en mi red:

VMWare------SW6500-----(DMZ-RED10)ASA(Outside)------Internet-----Clients

Mis servidores VMWare están en la red 172.16.10.0/255.255.255.128 y la IP de la interfaz DMZ-RED10 del ASA es: 172.16.10.1/255.255.255.128. Cada vez que agrego esta regla de NAT para hacer una traducción de una red a la misma entre mis interfaces inside y DMZ-RED10, la comunicación entre mis servidores dentro de la LAN deja de funcionar después de cierto tiempo:

static (inside,DMZ-RED10) 172.16.0.0 172.16.0.0 netmask 255.255.0.0 

¿Por qué esta configuración afectaría la comunicación dentro de una misma LAN si el ASA ni siquiera debería recibir este tráfico?

Hola Adolfo:

   En la regla de NAT que estás utilizando también se está incluyendo la red a la que pertenecen tus servidores. Las reglas de NAT estático realizan un función de proxy para las resoluciones de ARP, es decir, cuando alguien en la LAN DMZ-RED10 manda una solicitud de ARP (Broadcast) para encontrar la dirección MAC de alguna IP dentro del rango 172.16.10.0/255.255.255.128 el ASA puede y debe contestar con su propia MAC de acuerdo con la configuración de NAT. Eventualmente tanto el equipo que originó el ARP como tu Switch aprenderán que determinada IP está ligada a la MAC del ASA y por lo tanto el tráfico será enviado al firewall. El ASA no puede redirigir el tráfico que recibe en su interfaz para que salga por la misma interfaz por lo que los paquetes son tirados. Necesitas modificar tu regla de NAT para que sea más específica y evites que el ASA haga proxy-arp para las direcciones IP de tus servidores, por ejemplo si tu red interna sólo incluye las IP’s 172.16.5.0/255.255.255.0, la configuración más adecuada sería:

static (inside,DMZ-RED10) 172.16.5.0 172.16.5.0 netmask 255.255.255.0

   Saludos,

Ricardo.

Hola Ricardo,

Tengo el siguiente problema y quiero ver como me puedes ayudar a resolverlo:

Mis clientes de VPN no están funcionando correctamente, y lo que estoy observando es que el 1841 está traduciendo todos los paquetes que van a los clientes a pesar de que mi route-map está negando el tráfico. Encontre el bug CSCsi29869 pero ya actualicé mi versión a 12.4.15T12 pero el tráfico se sigue traduciendo. Esta es la configuración que tengo:

vpn client    =======  1841 ------- internal server

192.68.0.245            NAT           192.168.0.85

config

ip nat inside source static tcp 192.168.0.85 443 interface FastEthernet0/0 443

ip nat inside source static tcp 192.168.0.85 80 interface FastEthernet0/0 80

ip nat inside source static tcp 192.168.0.60 1723 interface FastEthernet0/0 1723

ip nat inside source static tcp 192.168.0.60 110 interface FastEthernet0/0 110

ip nat inside source static tcp 192.168.0.60 25 interface FastEthernet0/0 25

ip nat inside source static tcp 192.168.0.60 143 interface FastEthernet0/0 143

ip nat inside source route-map VPN_NAT_CONTROL interface FastEthernet0/0 overload

ip access-list extended NAT_CONTROL

deny   ip 192.168.0.0 0.0.0.255 201.201.201.0 0.0.0.255

deny   ip 192.168.0.0 0.0.0.255 192.168.0.0 0.0.0.255

permit ip 192.168.0.0 0.0.0.255 any

route-map VPN_NAT_CONTROL permit 10

match ip address NAT_CONTROL

Hola Fernando:

   Por la forma en que tu equipo está configurado, aparentemente tu problema es con el servidor interno 192.168.0.85. El comportamiento que estás observando no es un problema de software, simplemente es el funcionamiento normal de las reglas de NAT estático. El route-map que mencionas está aplicado a la regla de NAT dinámica y éste no tiene ningún efecto sobre las reglas estáticas, por lo que necesitaríamos aplicar dicho route-map sobre la regla estática (esto está permitido desde la versión 12.2(4)T, la única condición es que la regla de NAT debe hacer referencia a un IP en lugar de a una interfaz):

Router(config)#ip nat inside source static tcp 1.1.1.1 80 2.2.2.2 80 ?
  extendable  Extend this translation when used
  mapping-id  Associate a mapping id to this mapping
  no-alias    Do not create an alias for the global address
  no-payload  No translation of embedded address/port in the payload
  redundancy  NAT redundancy operation
  route-map   Specify route-map   <<<<<<<<<<<<<
  vrf         Specify vrf
 

Router(config)#ip nat inside source static tcp 1.1.1.1 80 2.2.2.2 80 route-map NAT_CONTROL
Router(config)#

   Con este tipo de configuración, ya estamos haciendo que el NAT estático sea condicional y ya no debería realizar la traducción del servidor cuando el tráfico necesita ser encriptado sin que se aplique una regla de NAT previamente.

Saludos,

Ricardo.

Hola Fernando:

   Ampliando un poco más mi respuesta, existe un segundo método que puedes emplear para este mismo escenario. En este método utilizas una configuración de PBR en la interfaz de tu red LAN y redireccionas todo el tráfico que va dirigido a tu VPN hacia una interfaz loopback. La interfaz loopback debe contener una dirección IP que no se encuentre en tu red para evitar problemas de ruteo y NO debe estar designada como IP NAT INSIDE. Lo que hacemos en este tipo de configuración es forzar a que el tráfico "entre" al ruteador una segunda vez, y al no llegar por una interfaz catalogada como INSIDE, las reglas de NAT no son ejecutadas:

interface Loopback0

ip address 10.255.255.1 255.255.255.0

interface

ip address

ip nat inside

ip policy route-map REDIRECT

access-list 150 permit ip 192.168.0.0 0.0.0.255 201.201.201.0 0.0.0.255

access-list 150 permit ip 192.168.0.0 0.0.0.255 192.168.0.0 0.0.0.255

route-map REDIRECT permit 10

match ip address 150

set ip next-hop 10.255.255.2

   Lo que va a suceder es que el tráfico que va hacia la VPN llega por una interfaz INSIDE, pero el PBR manda el tráfico por una interfaz que NO es OUTSIDE, por lo tanto las reglas de NAT no son revisadas. Ahora bien, si observas bien la configuración de PBR, estamos mandando el tráfico de VPN a la dirección ip 10.255.255.2, que ningún equipo tiene configurada. Sin embargo, el ruteador sabe que esa dirección está alojada en la interfaz Loopback0, por las condiciones mismas de este tipo de interfaz virtual, el tráfico es devuelto al ruteador, haciendo el efecto de tráfico entrante por una interfaz que NO dispara el proceso de NAT, por lo tanto no se hace la traducción. Ambos métodos son válidos, sin embargo es preferible hacer las reglas de NAT estáticas condicionales, ya que PBR generalmente provoca un aumento en la utilización de CPU y también estamos forzando a que el ruteador maneje el mismo tráfico más de una vez durante el intercambio de datos.

  Saludos,

Ricardo.

Hola Ricardo, en una de tus respuestas pusiste estos comandos

ip nat outside source static 4.2.2.2 192.168.1.10 extendable

ip route 192.168.1.10 255.255.255.255 21.21.21.2

entiendo el comando de nat static, pero porque incluiste la ruta tambien?

Hola Gustavo:

   Para responder a tu pregunta debemos tomar en cuenta dos cosas:

1) Para este ejemplo en particular, la traducción de NAT estática en la interfaz OUTSIDE traduce la dirección 4.2.2.2 a una dirección que pertenece a la LAN (192.168.1.0/24). La razón para esto era que el equipo en la LAN no tenía una puerta de enlace por default y por lo tanto no podía enrutar tráfico a una red que no fuera la local. Es decir, para este equipo en particular, la IP 4.2.2.2 se ve como directamente conectada en la LAN.

2) Cuando usamos NAT OUTSIDE siempre debemos tener muy presente el orden de operación del NAT en los equipos:

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080133ddd.shtml

   En forma simplificada el orden de operación cambia dependiendo de la dirección del tráfico, de INSIDE hacia OUTSIDE y de OUTSIDE a INSIDE:

Dirección INSIDE->OUTSIDE:  PBR-> RUTEO -> NAT

Dirección OUTSIDE -> INSIDE:  NAT-> PBR -> RUTEO

   Tomando en cuenta estos dos puntos, hay que analizar que pasa con un paquete que llega al ruteador:

PAQUETE 1 (origen 4.2.2.2; destino 21.21.21.1)

   En cuanto el paquete llega a la interfaz OUTSIDE se realiza la traducción, de acuerdo con la información del inciso 2). El origen se cambia por 192.168.1.10 según la regla de NAT estático y el destino por 192.168.1.50 de acuerdo con la tabla de traducciones de NAT (hay que recordar que esta traducción se generó por un PAT originalmente). Después se revisa si hay un PBR en la interfaz (no hay) y finalmente se revisa la tabla de ruteo para encontrar por dónde accedemos a la IP destino 192.168.1.50 y esto es por la interfaz LAN. El paquete se entrega al servidor como esperamos.

PAQUETE 2 (origen 192.168.1.50; destino 192.168.1.10)

   Ahora es el turno del paquete que viene del equipo 192.168.1.50 buscando a la IP 192.168.1.10 que en realidad es la IP global 4.2.2.2. En primer lugar, el servidor sabe que la IP 192.168.1.10 está en la LAN, por lo que manda un paquete de ARP buscando mapear la dirección de capa 3 (MAC) con la dirección de capa 2 (MAC). Como tenemos una regla de NAT estático el ruteador contesta ese paquete con su propia MAC, y el equipo manda el paquete a la interfaz INSIDE del ruteador. Con base en el orden de operación de INSIDE->OUTSIDE el ruteador primero revisa si hay un PBR configurado en la interfaz (no hay) y después revisa la tabla de ruteo. Si no existe la ruta estática que configuré en el ejemplo, el ruteador sólo sabe que el destino es 192.168.1.10 y esa IP debería estar en esta misma interfaz INSIDE. Una vez que se da cuenta de esto, el ruteador manda un paquete de ARP buscando al dueño de la IP, obviamente nadie contestaría y la comunicación se pierde. Este es un caso muy particular de usar una regla de NAT OUTSIDE, en este caso forzosamente necesito una ruta estática que obligue a que el tráfico se mande a la interfaz OUTSIDE para poder realizar las traducciones necesarias y cambiar el origen por 21.21.21.1 y el destino por 4.2.2.2. En estos casos, la ruta ni siquiera necesita tener un "gateway" válido, simplemente debe contener una manera de forzar el tráfico a la interfaz catalogada como OUTSIDE.

   Saludos,

Ricardo.

Hola

En mi empresa tengo un servidor de Web local en donde esta alojada nuestro portal. Originalmente teníamos un equipo checkpoint que hacía una traducción estática al servidor y se podía accesar al portal sin problemas. Acabamos de cambiar el checkpoint por un Cisco 871 y ahora nadie en la LAN puede entrar a la página. La configuración es equivalente entre el 871 y el checkpoint sólo tengo un NAT dinámico y una traducción estática para el servidor. ¿Necesito configurar algo más en el 871 para que el acceso funcione?

Gracias.

Hola Christopher:

   Este es un problema bastante conocido en Cisco y la respuesta corta es que los equipos con IOS no dan soporte a este tipo de configuración. La razón es muy sencilla, el estándar de NAT bajo el cual está programado el IOS indica que para realizar una traducción de NAT el tráfico necesita ser recibido en una interfaz catalogada como INSIDE y salir por una interfaz OUTSIDE. En el sentido contrario, el tráfico debe llegar por una interfaz catalogada como OUTSIDE, aunque no es necesario que el tráfico salga por una interfaz INSIDE para llevar a cabo el NAT.

   En este caso no estamos cumpliendo con estos requerimientos. El tráfico originado de la LAN buscando la IP pública del servidor llega por una interfaz INSIDE con destino a una interfaz OUTSIDE. La traducción se lleva a cabo sin problema, sin embargo, el verdadero destino es una IP por la que el ruteador debe contestar y redirigir hacia el servidor interno. Este es el paso que no se está llevando a cabo ¿por qué? Porque el tráfico NO está llegando por una interfaz OUTSIDE, el tráfico está adentro del ruteador. Lo que generalmente ocurre es que el ruteador toma este tráfico como propio (a final de cuentas el destino es una IP que el ruteador controla) y responde de ser posible. En este caso, si la conexión es al puerto TCP 80, y el ruteador tiene instalado SDM, lo que el usuario interno verá será la página de inicio de SDM.

   Existen diversas opciones para evitar este problema:

OPCIÓN 1: Utilizar la IP privada del servidor local. Esto evita que el tráfico sea manejado por el ruteador.

OPCIÓN 2: Utilizar un servidor DNS local que tenga una entrada apuntando a la IP privada del servidor. Así cuando algún equipo busca la IP del servidor recibiría la IP privada y contactaría al servidor directamente en lugar de usar el ruteador.

OPCIÓN 3: Configurar al ruteador como servidor DNS. Los equipos en la LAN deben utilizar la IP del ruteador como DNS y se agrega la siguiente configuración:

config t

ip dns server

ip domain lookup

name-server X.X.X.X      <<<<< DNS público

ip host www.domain.com    <<<<< IP Privada del servidor

OPCIÓN 4: Cada PC en la LAN contiene un archivo de IP’s que usa como referencia antes de mandar una solicitud a un servidor DNS, es posible modificar este archivo para agregar más referencias. El archivo, llamado "hosts", está generalmente ubicado en la siguiente dirección:

X:\windows\system32\drivers\etc

El archivo hosts puede ser editado con el Block de Notas y por default tiene más o menos la siguiente información sólo hay que agregar una entrada similar a la del "localhost" para el servidor local:


# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP for Windows.
#
# This file contains the mappings of IP addresses to host names. Each
# entry should be kept on an individual line. The IP address should
# be placed in the first column followed by the corresponding host name.
# The IP address and the host name should be separated by at least one
# space.
#
# Additionally, comments (such as these) may be inserted on individual
# lines or following the machine name denoted by a '#' symbol.
#
# For example:
#
#      102.54.94.97     rhino.acme.com          # source server
#       38.25.63.10     x.acme.com              # x client host

127.0.0.1       localhost
<<<<<<<

   Saludos,

Ricardo.

Sobre este mismo asunto me comentaron de una configuracion de nat on a stick, esta podria ser una opcion? Como se configuraria para este caso?

http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080094430.shtml