Puerta de enlace tras conexion VPN

Hola a :
He configurado Windows 2003 Server para hacer de servidor VPN para
multiples clientes, este mismo servidor es controlador de dominio,
servidor DHCP, DNS y WINS (estoy probando :p)
El caso es que cuando un cliente se conecta a la VPN, automaticamente
su puerta de enlace pasa por el tunel VPN, lo explicare mas detallado.

Mi amigo se conecta desde su casa (ambos tenemos adsl 512/128), ahora
tiene 2 conexiones, su "Conexiond e area local" y la conexion VPN con
mi servidor. Si hacemos un tracert de www.google.com desde la maquina
de mi amigo, la peticion pasa por mi servidor y este se la da a mi
Router para que la resuelva, asi que mi amigo ve toda su conexion a
internet muy ralentizada, ya que esta tunelizada en el VPN. He
conseguido solucionar esto con el comando route, si en el ordenador
de mi amigo elimino una de las 2 rutas hacia 0.0.0.0, concretamente
la que apunta a mi servidor, consigo que el tracert ya no pase por el
tunel.
Ahora bien:
¿Como puedo configurar el servidor para que los clientes solo accedan
por el tunel cuando quieran acceder a una IP que este al otro lado?
Si la red de mi amigo es 192.168.12.0 y la mia 192.168.12.0 ¿Esto
puede generar algun error en las rutas, como solventarlo?
Ahora mismo el servidor DHCP se encarga de dar las direcciones a los
clientes de la VPN, tambien probé a dar un rango aparte para los
clientes VPN, desde la configuracion de "Enrutameinto y acceso
remoto" pero el problema persistia, el servidor se pone como puerta
de enlace de los cleintes, esto hace que se agregue la segunda ruta
hacia 0.0.0.0, lo que hace que se tunelize toda la conexion del
cliente.
Espero haberme explicado claramente, un saludo

Mythox.

No se corrige en el servidor, se hace en los clientes. En las propiedades de
la conexión del cliente, ficha de rec, en las propiedades de TCP/IP, botón
avanzadas, está la opción de usar la puerta de enlace en la red remota.

Es el valor por omisión que toman las conexiones de discado. Desde el
servidor no puedes hacer nada
Si eliminas el uso de la puerta de enlace en la red remota, debes utilizar
ROUTE -P para crear la ruta a la otra red


Por otro lado, si ambas redes son las mismas: 192.168.12.0/24 por lo que
dices entonces nunca va a "rutear" porque todo creerá que es local. Otra
cosa es si estás hablando de la dirección IP de la VPN que entrega el
servidor.
Una red la tienes en tu casa, otra red la tendrá tu amigo, y una tercera red
es la vpn. Aunque puede ser que esta última (VPN) sea la misma que la del
servidor VPN

Saludos

Guillermo Delprato
MVP-MCT-MCSE-MCSA-MCP
Buenos Aires, Argentina

NOTA. Por favor, las preguntas y comentarios en los grupos, así nos
beneficiamos todos. Este mensaje se proporciona "como está" sin
garantías de ninguna clase, y no otorga ningún derecho. Ud. asume los
riesgos This posting is provided "AS IS" with no warranties, and
confers no rights. You assume all risk for your use.



Mythox wrote:
> Hola a :
> He configurado Windows 2003 Server para hacer de servidor VPN para
> multiples clientes, este mismo servidor es controlador de dominio,
> servidor DHCP, DNS y WINS (estoy probando :p)
> El caso es que cuando un cliente se conecta a la VPN, automaticamente
> su puerta de enlace pasa por el tunel VPN, lo explicare mas detallado.
>
> Mi amigo se conecta desde su casa (ambos tenemos adsl 512/128), ahora
> tiene 2 conexiones, su "Conexiond e area local" y la conexion VPN con
> mi servidor. Si hacemos un tracert de www.google.com desde la maquina
> de mi amigo, la peticion pasa por mi servidor y este se la da a mi
> Router para que la resuelva, asi que mi amigo ve toda su conexion a
> internet muy ralentizada, ya que esta tunelizada en el VPN. He
> conseguido solucionar esto con el comando route, si en el ordenador
> de mi amigo elimino una de las 2 rutas hacia 0.0.0.0, concretamente
> la que apunta a mi servidor, consigo que el tracert ya no pase por el
> tunel.
> Ahora bien:
> ¿Como puedo configurar el servidor para que los clientes solo accedan
> por el tunel cuando quieran acceder a una IP que este al otro lado?
> Si la red de mi amigo es 192.168.12.0 y la mia 192.168.12.0 ¿Esto
> puede generar algun error en las rutas, como solventarlo?
> Ahora mismo el servidor DHCP se encarga de dar las direcciones a los
> clientes de la VPN, tambien probé a dar un rango aparte para los
> clientes VPN, desde la configuracion de "Enrutameinto y acceso
> remoto" pero el problema persistia, el servidor se pone como puerta
> de enlace de los cleintes, esto hace que se agregue la segunda ruta
> hacia 0.0.0.0, lo que hace que se tunelize toda la conexion del
> cliente.
> Espero haberme explicado claramente, un saludo
>
> Mythox.

A mi me pasa lo mismo.

En mi red local, o sea dentro de la VPN, tengo una subred
172.26.255.255 mientras que la de todos mis clientes es 192.168.0.255
y cuando se conectan ademas se añadirse la ruta para 172.26.255.255
tirar del servidor VPN, se añade para las rutas 0.0.0.0 y
255.255.255.255.

¿Si en los clientes desactivo esa opcion, no se quitara la ruta para
172.26.255.255 no?

Porque estariamos en el problema inverso :S.

¿En clientes UNIX o Macintosh no hay ninguna forma de hacer que no se
añada esa ruta nada mas que eliminarla manualmente?

Gracias

"Guillermo Delprato [MS-MVP]" escribió:

No se corrige en el servidor, se hace en los clientes. En las
propiedades de la conexión del cliente, ficha de rec, en las
propiedades de TCP/IP, botón avanzadas, está la opción de usar la
puerta de enlace en la red remota.

Es el valor por omisión que toman las conexiones de discado. Desde el
servidor no puedes hacer nada
Si eliminas el uso de la puerta de enlace en la red remota, debes
utilizar ROUTE -P para crear la ruta a la otra red


Por otro lado, si ambas redes son las mismas: 192.168.12.0/24 por lo
que dices entonces nunca va a "rutear" porque todo creerá que es
local. Otra cosa es si estás hablando de la dirección IP de la VPN
que entrega el servidor.
Una red la tienes en tu casa, otra red la tendrá tu amigo, y una
tercera red es la vpn. Aunque puede ser que esta última (VPN) sea la
misma que la del servidor VPN

Saludos

Guillermo Delprato
MVP-MCT-MCSE-MCSA-MCP
Buenos Aires, Argentina

NOTA. Por favor, las preguntas y comentarios en los grupos, así nos
beneficiamos todos. Este mensaje se proporciona "como está" sin
garantías de ninguna clase, y no otorga ningún derecho. Ud. asume los
riesgos This posting is provided "AS IS" with no warranties, and
confers no rights. You assume all risk for your use.



Mythox wrote:

Hola a :
He configurado Windows 2003 Server para hacer de servidor VPN para
multiples clientes, este mismo servidor es controlador de dominio,
servidor DHCP, DNS y WINS (estoy probando :p)
El caso es que cuando un cliente se conecta a la VPN,
automaticamente su puerta de enlace pasa por el tunel VPN, lo
explicare mas detallado.

Mi amigo se conecta desde su casa (ambos tenemos adsl 512/128),
ahora tiene 2 conexiones, su "Conexiond e area local" y la conexion
VPN con mi servidor. Si hacemos un tracert de www.google.com desde
la maquina de mi amigo, la peticion pasa por mi servidor y este se
la da a mi Router para que la resuelva, asi que mi amigo ve toda su
conexion a internet muy ralentizada, ya que esta tunelizada en el
VPN. He conseguido solucionar esto con el comando route, si en el
ordenador de mi amigo elimino una de las 2 rutas hacia 0.0.0.0,
concretamente la que apunta a mi servidor, consigo que el tracert
ya no pase por el tunel.
Ahora bien:
¿Como puedo configurar el servidor para que los clientes solo
accedan por el tunel cuando quieran acceder a una IP que este al
otro lado? Si la red de mi amigo es 192.168.12.0 y la mia
192.168.12.0 ¿Esto puede generar algun error en las rutas, como
solventarlo?
Ahora mismo el servidor DHCP se encarga de dar las direcciones a los
clientes de la VPN, tambien probé a dar un rango aparte para los
clientes VPN, desde la configuracion de "Enrutameinto y acceso
remoto" pero el problema persistia, el servidor se pone como puerta
de enlace de los cleintes, esto hace que se agregue la segunda ruta
hacia 0.0.0.0, lo que hace que se tunelize toda la conexion del
cliente.
Espero haberme explicado claramente, un saludo

Mythox.