ISA 3 patas: funciona pero ¿por qué?

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:

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

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:

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:
> 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
>
>

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:%

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:
> 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:
> > 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
> >
> >
>
>

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:

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:%
> 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:
> > 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:
> > > 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
> > >
> > >
> >
> >
>
>

"Beemer" escribió en el mensaje
news:

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.

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.

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.

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

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.

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.

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?

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.

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...

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