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

[ciscomoderator]

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.

[Ricardo Prado Rueda]

Hola Christopher:

   Para este tipo de casos se ha llegado a manejar la configuración de "NAT-On-A-Stick" como una opción, sin embargo esta no es una configuración que esté soportada por Cisco o por el TAC. Las únicas dos configuraciones de NAT On a Stick que son soportadas son los ejemplos que vienen en la página que comentas, que como podrás observar son ejemplos muy particulares. El primer ejemplo es un NAT en una configuración de una sola interfaz, una aplicación muy común para este tipo de configuración está descrita en un documento que subí a la comunidad en español (Internet Central para clientes de VPN en Ruteador) y el objetivo es usar una interfaz Loopback para llevar a cabo el proceso de NAT cuando sólo contamos con una interfaz física catalogada como OUTSIDE. El segundo ejemplo es para interconectar redes que están usando el mismo direccionamiento y utiliza dos interfaces físicas OUTSIDE y una Loopback como INSIDE. La principal razón por la que estas configuraciones funcionan es que el tráfico sale del ruteador después de que el NAT es procesado. Para un caso como el que mencionas, esto no sucede por lo que no funciona correctamente. En mi experiencia he visto que esta configuración funciona en condiciones muy particulares en laboratorio pero no lo he visto antes en una red activa.

   Cabe mencionar que el tipo de configuración que se usa para este tipo de caso es muy complejo, las traducciones de NAT se utilizan para "engañar" al router haciéndolo suponer que el tráfico viene de otro equipo y el tráfico se hace pasar por las interfaces hasta 4 veces haciendo traducciones simultáneas de origen y destino, lo que aumenta mucho el procesamiento del ruteador y podría acortar su tiempo de vida útil.

Saludos,

Ricardo.

[Dani Ma]

Hola Ricardo, encontré este link para utilizar IP SLA en una configuración con dos reglas de NAT, pero no entiendo el objetivo del route-map dentro de la configuración. ¿Qué es exactamente lo que hace el comando “match interface FastEthernet0” dentro del route-map? Este es el link

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

Daniel

[Ricardo Prado Rueda · Accepted solution]

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.