cancelar
Mostrando los resultados de 
Buscar en lugar de 
Quiere decir: 
Avisos
¡Bienvenido a la nueva Comunidad de Soporte de Cisco! Nos encantaría conocer su opinión
New Member

Problema con reenvio del Puerto 80

Hola tengo un problema con el acceso a un servidor web de manera local dentro de mi red y deseo que los usuarios accedan a el mediante el puerto 80, el detalle es que cuando escribo en mi navegador la URL de mi pagina me manda directamente a la pagina de configuración del router y no a la pagina web de mi servidor.

he probado con la siguiente configuración mediante NAT:

ip nat inside source static tcp 172.xxx.x.x 80 interface GigabitEthernet0 80 o bien

ip nat inside source static tcp 172.xxx.x.x 80 ip publica 188.xxx.xxx.x 80  extendable ———> alternativa 2

En la lista de acceso extendida tengo lo siguiente:

p access-list extended VLAN_ALL

permit udp  any host 172.xxx.x.xxx any

permit tcp any host 172.xxx.x.xxx any

permit tcp any host 172.xxx.x.xxx eq 80

pero como mencione anteriormente sigo sin acceder a la pagina de mi servidor me manda directamente a la pagina web de configuración del router, pero cuando desactivo el ip http server me da el siguiente error : erro_conection_reforsed

y cuando lo vuelvo activar ip http server y cambio de puerto en este caso al 443 para dejar libre el puerto 80 hace lo mismo me manda a la pagina web del router.

El router cisco es un 891-k9 ISR, anexo el archivo de configuración, espero contar con la ayuda de alguien pudiendo darme alguna  solución de antemano gracias.

1 SOLUCIÓN ACEPTADA

Soluciones aceptadas
Cisco Employee

Hola:

Hola:

   Lamentablemente lo que estás tratando de hacer (acceder a un servidor local a través de su dirección de NAT) no es posible con un router Cisco. La razón de esto es que el IOS está basado en el RFC de NAT 1631 que requiere que el flujo de tráfico vaya de la interfaz inside a la outside y viceversa en el flujo contrario. En este caso lo que ocurre es lo siguiente:

  1. El paquete inicial se manda al router buscando la dirección pública del servidor.
  2. El paquete llega a la interfaz inside, se verifica que el ruteo que debe seguir (default gateway) y se enruta.
  3. Después de la decisión de ruteo se buscan reglas de NAT para alterar origen y/o destino. En este caso solo se afecta el origen, la regla de NAT estático no aplica en este caso cuando el paquete va entrando por inside.
  4. El paquete se traduce y se manda a la dirección de la interfaz de salida. Pero la IP destino es el mismo router, ya sea porque es la IP asignada a la interfaz o porque el NAT generó un alias para responder por la misma y por esta razón el router contesta con el servicio si es que está habilitado (http server) o te dice que el puerto no está permitido. El paquete nunca salió del router y por eso no se cumplen las condiciones del RFC y no se aplica nunca la regla de NAT estática de tu servidor.
  5. Cualquier paquete que venga desde Internet va a funcionar correctamente porque ahora sí cumple las condiciones de pasar a través de las dos interfaces para que las reglas de NAT puedan ejecutarse.

Los routers Linksys por ejemplo, sí permiten este tipo de tráfico porque al tener menos features que IOS pueden programar la implemenación de NAT de manera diferente. Para usar el 891 en este escenario necesitarías usar alguna de las siguientes opciones:

OPCIÓN 1: Usar la IP privada para acceder al servidor. Este tráfico no pasa a través del router y el NAT no es necesario.

OPCIÓN 2: Configurar un servidor interno como DNS local y apuntar el URL de tu servidor a la dirección privada en lugar de la pública. Todos tus usuarios deben usar ese servidor como DNS.

OPCIÓN 3: Usar el router como servidor de DNS y usarlo como DNS de tu red. Agregar el URL de tu servidor a la IP privada:

config t
ip dns server
ip domain lookup
name-server X.X.X.X      <<<<< DNS público que usas ahora para otras solicitudes

ip host www.domain.com <Y.Y.Y.Y>   <<<<< URL del servidor local con IP privada

OPCIÓN 4: Editar el archivo "hosts" en cada computadora para ligar el URL a la IP privada. El archivo hosts siempre se revisa primero antes de buscar un DNS externo.

Hace muchos años había una configuración llamada NAT on a Stick que en algunas circunstacias podía ayudar en estos casos, pero esta configuración para este problema en particular no está soportado por Cisco ni por el TAC ya que no siempre funciona  y por lo general incrementa mucho la utilización del CPU del equipo.

Saludos.

2 RESPUESTAS
Cisco Employee

Hola:

Hola:

   Lamentablemente lo que estás tratando de hacer (acceder a un servidor local a través de su dirección de NAT) no es posible con un router Cisco. La razón de esto es que el IOS está basado en el RFC de NAT 1631 que requiere que el flujo de tráfico vaya de la interfaz inside a la outside y viceversa en el flujo contrario. En este caso lo que ocurre es lo siguiente:

  1. El paquete inicial se manda al router buscando la dirección pública del servidor.
  2. El paquete llega a la interfaz inside, se verifica que el ruteo que debe seguir (default gateway) y se enruta.
  3. Después de la decisión de ruteo se buscan reglas de NAT para alterar origen y/o destino. En este caso solo se afecta el origen, la regla de NAT estático no aplica en este caso cuando el paquete va entrando por inside.
  4. El paquete se traduce y se manda a la dirección de la interfaz de salida. Pero la IP destino es el mismo router, ya sea porque es la IP asignada a la interfaz o porque el NAT generó un alias para responder por la misma y por esta razón el router contesta con el servicio si es que está habilitado (http server) o te dice que el puerto no está permitido. El paquete nunca salió del router y por eso no se cumplen las condiciones del RFC y no se aplica nunca la regla de NAT estática de tu servidor.
  5. Cualquier paquete que venga desde Internet va a funcionar correctamente porque ahora sí cumple las condiciones de pasar a través de las dos interfaces para que las reglas de NAT puedan ejecutarse.

Los routers Linksys por ejemplo, sí permiten este tipo de tráfico porque al tener menos features que IOS pueden programar la implemenación de NAT de manera diferente. Para usar el 891 en este escenario necesitarías usar alguna de las siguientes opciones:

OPCIÓN 1: Usar la IP privada para acceder al servidor. Este tráfico no pasa a través del router y el NAT no es necesario.

OPCIÓN 2: Configurar un servidor interno como DNS local y apuntar el URL de tu servidor a la dirección privada en lugar de la pública. Todos tus usuarios deben usar ese servidor como DNS.

OPCIÓN 3: Usar el router como servidor de DNS y usarlo como DNS de tu red. Agregar el URL de tu servidor a la IP privada:

config t
ip dns server
ip domain lookup
name-server X.X.X.X      <<<<< DNS público que usas ahora para otras solicitudes

ip host www.domain.com <Y.Y.Y.Y>   <<<<< URL del servidor local con IP privada

OPCIÓN 4: Editar el archivo "hosts" en cada computadora para ligar el URL a la IP privada. El archivo hosts siempre se revisa primero antes de buscar un DNS externo.

Hace muchos años había una configuración llamada NAT on a Stick que en algunas circunstacias podía ayudar en estos casos, pero esta configuración para este problema en particular no está soportado por Cisco ni por el TAC ya que no siempre funciona  y por lo general incrementa mucho la utilización del CPU del equipo.

Saludos.

New Member

Efectivamente Ricardo la

Efectivamente Ricardo la conexión de internet es decir de otro proveedor o bien del exterior si funciona y pues usare la opción 1 ya solo modificare el host de la pc para cuando quiera ingresar a la pagina no sea por la ip sino el nombre dominio muchas gracias.

287
Visitas
4
ÚTIL
2
Respuestas
CrearPor favor para crear contenido