ISA 3 patas: funciona pero ¿por qué?

08/07/2004 - 08:20 por Beemer | Informe spam
Buenos días, quería consultaros una duda de concepto:
Tengo desde hace meses un ISA de dos patas que se encarga de que una
delegación entre por VPN PPTP en la central mediante un ADSL. En la pata
exterior está el router ADSL y en la interior la red privada, que está dada
de alta completa en la LAT. Todo funciona correctamente.

Peo ayer, con el fín de que una empresa hermana, que se ha instalado en el
mismo edificio de la central, acceda a determinados servicios de uno de los
servidores, añadí una tercera tarjeta a este mismo ISA, conectada a la red
de la empresa Hermana. Y empecé a probar configuraciones:
1-)Si añadía la red completa Hermana a la LAT, ISA consideraba que era
interna y no había comunicación entre ellas.
2-)Si no añadía la red Hermana a la LAT, ISA la consideraba externa.
Entonces puse un filtro de paquetes (pasa-todo para probar) con
origen Local el servidor en central que ofrece el servicio y remoto la red
Hermana completa: No funciona.
Si cambiaba el origen a la interfaz externa del ISA si funcionaba,
pero Hermana accedía a toda la red Central, no solo al servidor concreto,
como se deseaba.
Esto mismo ocurría si Local era una red que incluyera al NIC de
Central en el ISA.
3-)La solución: Cambié la IP del NIC del ISA para Hermana a la 245 (clase C)
e incluí en la LAT las direcciones 1-253 (Es decir toda excepto la propia
NIC del ISA)
Probé el filtro de paquetes anterior, es decir Local el servidor de
Central que ofrece el servicio y Remoto Toda la red Hermana (la clase C
entera, incluyendo la pata del ISA): Funciona exactamente como se desea.
Limité el filtro al puerto concreto del servicio prestado por el
servidor y funcionó correctamente, Hermana solo puede ver en Central a ese
servidor por ese puerto y Central no ve en absoluto a Hermana.


Y aquí viene la pregunta: Esta solución reconozco que la encontrá a tanteo,
y después de pasarme la noche sin dormir, sigo sin comprender porque
funciona. Si alguien lo entiende, me gustaría que me lo explicase, porque no
me quedo agusto, como supongo que le pasaría a cualquiera de vosotros.
Por otro lado, ¿por que no funcionaba la solución 2-1? Aquí pienso que
probablemente era una cuestión de NAT, aunque cometí la torpeza de no hacer
unos netstat -na en ambos extremos para verificar que veía cada cual, si
IP's reales o la de la para del ISA cuando al abrir en 2-2 a una red
superior empezaba a funcionar.

Perdón por la extensión, pero es dificil concentrar en menos líneas seis
horas de quebradero de cabeza (sin contar toda la noche pensando).

Un saludo.
beemer

Preguntas similare

Leer las respuestas

#1 Ivan [MS MVP]
08/07/2004 - 09:14 | Informe spam
Si vas a instalar en el ISA un tercer adaptador solo tienes dos opciones,
que la direccion IP de ese adaptador pertenezca a la red interna (su
direccion esta incluida en la LAT) o usar una configuracion Three-homed DMZ,
no hay mas opciones.
En el primer caso, el rango de direcciones de ambos interfaces internos debe
ser distinto y, si quieres que se pueda establecer la comunicacion entre
ambos rangos debes habilitar el IP routing. En este caso puedes hacer uso
del filtrado de RRAS y limitar al acceso entre ambas subredes.
En el segundo caso, Three-homed DMZ, los rangos de direcciones IP de los
tres interfaces, deben ser distintos y tambien debes habilitar el IP routing
para permitir la comunicacion entre el interface externo-DMZ. La relacion
entre redes es de esta forma:
Interna-DMZ= NAT
Interna-Externa=NAT
DMZ-Externa=Routing

La pregunta seria: que rangos de direcciones estas usando en cada uno de los
interfaces y que rangos estan en la LAT ? en funcion de esto, la forma de
permitir la comunicacion entre las distintas subredes cambia muchisimo.
1-El tercer adaptador esta incluido en la LAT: en este caso la otra subred
debe poder acceder sin ningun tipo de restriccion siempre y cuando el IP
routing este habilitado en el ISA y la unica forma de controlar el acceso es
usando el filtrado de RRAS, algo como esto:
http://www.isaserver.org/tutorials/...urity.html
2-El tercer adaptador no esta incluido en la LAT: en este caso tenemos una
three-homed DMZ y la forma de permitir el trafico entre la subred DMZ y la
red interna es empleando reglas de publicacion, los filtros solo sirven para
permitir el trafico entre la DMZ y el propio servidor ISA y entre la red
externa/DMZ.

La solucion 2-1 no funciona porque debes permitir el acceso con reglas de
publicacion, no con filtros. La solucion que estas usando actualmente no me
parece correcta a priori. Necesitaria ver los rangos de direcciones de cada
interface y el contenido de la LAT.

Un saludo.
Ivan
MS MVP ISA Server


"Beemer" escribió en el mensaje
news:
Mostrar la cita
dada
Mostrar la cita
los
Mostrar la cita
C)
Mostrar la cita
de
Mostrar la cita
tanteo,
Mostrar la cita
no
Mostrar la cita
hacer
Mostrar la cita
#2 Beemer
08/07/2004 - 10:14 | Informe spam
Muchas gracias por tu respuesta Ivan.
En principio, lo que comentas es lo que yo entendía como correcto. Por eso
me rompe los esquemas lo que está ocurriendo. Te comento con detalle la
configuración de IPs:
Red externa:
Router ADSL con IP etehernet interna 192.168.175.1
ISA NIC: 192.168.175.2
Red Interna Central:
ISA NIC: 192.168.171.1
Servidor W2K: 192.168.171.10
Red Hermana:
ISA NIC: 192.168.0.254
Puesto de pruebas WXP: 192.168.0.10

LAT:
192.168.171.1-192.168.171.255
192.168.0.1-192.168.0.253 (Fijate que no incluyo la ISA NIC en la
254)

Regla de filtro de paquetes IP:
Permitir Local:Maquina interna-192.168.171.10 Remoto:192.168.0.0
255.255.255.0 TCP Entrada 445 Todos los puertos.

Lo sorprendente es que funciona. El puesto de pruebas puede conectar una
unidad de red al servidor y no ve al resto de la red Central ni por supuesto
puede hacer ping a nada. Los puestos de la red Central no ven la red
Hermana.

La solución que propones por RRAS tiene a mi parecer el inconveniente de que
me permitiría acceder al puerto 445 de cualquier servidor de Central desde
la red Hermana, ya que el filtrado de paquetes a nivel de NIC no permite
especificar IP de destino.

Un saludo y gracias de nuevo.
Beemer

"Ivan [MS MVP]" escribió en el mensaje
news:
Mostrar la cita
DMZ,
Mostrar la cita
debe
Mostrar la cita
routing
Mostrar la cita
los
Mostrar la cita
es
Mostrar la cita
http://www.isaserver.org/tutorials/...urity.html
Mostrar la cita
para
Mostrar la cita
me
Mostrar la cita
cada
Mostrar la cita
el
Mostrar la cita
red
Mostrar la cita
red
Mostrar la cita
funcionaba,
Mostrar la cita
concreto,
Mostrar la cita
(clase
Mostrar la cita
propia
Mostrar la cita
ese
Mostrar la cita
porque
Mostrar la cita
#3 Ivan [MS MVP]
08/07/2004 - 10:31 | Informe spam
Hola Beemer,
No es correcto, yo dejaria la LAT unicamente como:
192.168.171.0-192.168.171.255, una Three-homed DMZ.
Aunque no este el interface del ISA en la LAT, lo mas probable es que las
peticiones del cliente de pruebas 192.168.0.10 te las detecte como IP
spoofing ya que se trata de una peticion que no es alcanzable por el
interface sobre el que se recibe
Otra pregunta importante, que trafico tienes que permitir entre la red
interna y la red DMZ ? si se trata de trafico entre dominios, es complicado,
aunque por poder se puede. Si solo necesitas publicar servicios como Web,
FTP, SMTP, POP3, etc sin problemas.

Con el filtrado de RRAS si puedes permitir o denegar en funcion de la IP o
rango de IPs origen, IP o rango de IPs destino, puerto origen y puerto
destino, no me refiero al filtrado disponible en las propiedades de TCP/IP.

Un saludo.
Ivan
MS MVP ISA Server


"Beemer" escribió en el mensaje
news:%
Mostrar la cita
Remoto:192.168.0.0
Mostrar la cita
supuesto
Mostrar la cita
que
Mostrar la cita
opciones,
Mostrar la cita
uso
Mostrar la cita
relacion
Mostrar la cita
de
Mostrar la cita
subred
Mostrar la cita
acceso
Mostrar la cita
http://www.isaserver.org/tutorials/...urity.html
Mostrar la cita
una
Mostrar la cita
la
Mostrar la cita
de
Mostrar la cita
pata
Mostrar la cita
en
Mostrar la cita
de
Mostrar la cita
con
Mostrar la cita
de
Mostrar la cita
servidor
Mostrar la cita
C
Mostrar la cita
desea.
Mostrar la cita
el
Mostrar la cita
si
Mostrar la cita
seis
Mostrar la cita
#4 Beemer
08/07/2004 - 11:37 | Informe spam
Hola Ivan,
El tráfico que tengo que permitir es que desde la red Hermana (DMZ en
terminos ISA) los equipos XP se conecten a SMB (445) en W2K, Oracle (1521)
en Unix, Tuxedo(7000 y dinámico) en NT y Lanmanserver (UDP137-138,TCP139) en
NT. Mas adelante a SQL server. Ya está configurado todo esto y funciona. Los
equipos de la red Hermana están en un grupo de trabajo, pero se identifican
con cuentas del dominio principal (NT) habilitadas al efecto para hcer los
mapeos SMB y Lanmanserver y cuentas Oracle para Oracle y Tuxedo.

Sobre el tema de filtrado de paquetes por RRAS, que me interesa mucho, he
estado revisando el documento que me indicas, pero solo veo que hable del
filtrado de propiedades de TCP/IP pero buscando en el Technet he encontrado
donde hacerlo en RRAS (está escondidillo el tema). Luego me he acordado de
que en alguna ocasión lo he utilizado para limitar el tráfico de las VPN,
pero no había caido en usarlo de esta manera.

Supongo que hacerlo por RRAS al estar sportado por Microsoft, será mas
seguro que hacerlo por ISA. Pero lo sorprendente es que funcione. No estoy
de acuerdo en que ISA opine que sean IP spoofing las peticiones del cliente
de pruebas, ya que de hecho esta en la misma subred que el interface DMZ del
ISA a nivel de configuración del NIC.

Yo me inclino mas, por el lado de NAT. Creo que si meto el interface NIC DMZ
de ISA en la LAT, ISA lo considera interno y le pasa el trabajo a RRAS, pero
si no meto ni el interface ni la red Hermana, me hace NAT en las peticiones
de la red interna a la DMZ y por eso falla. Sin embargo al meter toda la red
DMZ como Interna en LAT, menos la propia NIC del ISA no hace NAT ni se lo
pasa al RRAS.
A lo mejor lo que digo es una tontería, pero no se me ocurre otra cosa. ¿tu
que opinas?

En cualquier caso, y aparte del deseo de saber porqué esta funcionando, creo
que lo voy a cambiar todo, como recomiendas, a filtrado por RRAS. Anteayer
estuve en una presentación de ISA 2004 y la verdad es que estas cosas las
hace mucho mas simples...

Un saludo.
Beemer.

"Ivan [MS MVP]" escribió en el mensaje
news:
Mostrar la cita
complicado,
Mostrar la cita
TCP/IP.
Mostrar la cita
eso
Mostrar la cita
desde
Mostrar la cita
Three-homed
Mostrar la cita
internos
Mostrar la cita
entre
Mostrar la cita
los
Mostrar la cita
de
Mostrar la cita
muchisimo.
Mostrar la cita
IP
Mostrar la cita
http://www.isaserver.org/tutorials/...urity.html
Mostrar la cita
y
Mostrar la cita
sirven
Mostrar la cita
red
Mostrar la cita
no
Mostrar la cita
está
Mostrar la cita
la
Mostrar la cita
era
Mostrar la cita
la
Mostrar la cita
clase
Mostrar la cita
por
Mostrar la cita
a
Mostrar la cita
vosotros.
Mostrar la cita
que
Mostrar la cita
no
Mostrar la cita
cual,
Mostrar la cita
#5 Ivan [MS MVP]
08/07/2004 - 12:34 | Informe spam
"Beemer" escribió en el mensaje
news:
Mostrar la cita
en
Mostrar la cita
Los
Mostrar la cita
identifican
Mostrar la cita
Complicado realizarlo en una configuracion Three-homed DMZ, aunque es
perfectamente posible. NetBIOS olvidate, aunque puedes utilizar un WINS en
cada red y configurar la replicacion. Como necesitas publicar 445, la unica
forma de hacerlo para empezar es deshabilitando NetBIOS sobre TCP/IP
totalmente, no desde las propiedades de TCP/IP si no desde el adminsitrador
de dispositivos con lo cual la unica forma de adminsitrar el ISA es mediante
terminal services u otros programas de control remoto. Tambien, por cada
servidor que necesites publicar para acceder con direct host (445 TCP)
necesitas usar una IP en el interface DMZ, bueno esto para cualquier
servicio, si por ejmeplo tienes dos SQL necesitas dos IPs en el inetrface
DMS del ISA y publicar 1433 TCP en cada IP.

Mostrar la cita
encontrado
Mostrar la cita
Si, lo habitual es cerrar todo y permitir los puertos y protocolos del
trafico VPN.

Mostrar la cita
cliente
Mostrar la cita
del
Mostrar la cita
Pues ni de coña ;-) el filtrado de RRAS es el filtrado de paquetes de
toda la vida, no hay inspeccion de estado, ni filtros de aplicaciones ni
nada de nada. Si quieres permitir por ejemplo ftp, debes permitir el puerto
21 TCP en entrante a la IPs o rangos de IPs y por otro lado crear otro
filtro en entrante que permite todos los puertos al puerto destino 20 mas
los filtros en saliente para las dos operaciones anteriores: origen 21 TCP,
destino all ports, origen 20 TCP destino all ports. Esto en ISA no es
necesario gracias al filtro FTP, no tienes que permitir ramgos de puertos
enormes. Si por ejemplo necesitas permitir FTP pasv con RRAS casi mejor ni
usar filtrado...
Tambien para permitir RPC vas a necesitar realziar cambios en el registro en
los servidores para limitar el rango de puertos dinamicos, si no lo haces,
el filtrado de RRAS no hace nada ya que tendrias que.permitir absolutamente
todo. Esto con el filtro any RPC del ISA no es necesario si bien, al tener
NAT exige una IP sobre el inetrface DMZ por cada servidor publicado.

Mostrar la cita
DMZ
Mostrar la cita
pero
Mostrar la cita
peticiones
Mostrar la cita
red
Mostrar la cita
¿tu
Mostrar la cita
Estas poniendo en la LAT direcciones externas. Esto no es logico aunque por
poder... Desde mi punto de vista es una configuracion erronea. La relacion
entre red interna y DMZ es de NAT, luego si esas direcciones estan en la
LAT, dificilmente un cliente firewall va a poder alcanzar la DMZ.

Mostrar la cita
creo
Mostrar la cita
Si, no hay color, ya que puedes establecer la relacion entre red interna y
DMZ como routing y es mucho mas sencillo. ISA 2004 tiene que estar al caer.
Si no te corre mucha prisa, igual merece la pena esperar un poquito

Un saludo.
Ivan
MS MVP ISA Server
Ads by Google
Search Busqueda sugerida