• ¿Quieres apoyar a nuestro foro haciendo una donación?, entra aquí.

Resuelto Conexión cliente-LAN router VPN

Las advanced?
Post automatically merged:

Lo haría pero hace media hora se cortó el suministro de energía eléctrica (un wn choco un poste oee).

De memoria:

Router:

Pestaña L2TP server:

WAN: WAN1 (boca a internet, DDNS para IP dinámica de VTR).

Encrypted: Encrypted.

PSK: 123456.

Pestaña usuarios:

Username: Operador

Password: 123456

Local IP Address: IP privada de router 192.168.12.6

VPN IP pool: pool de 41 direcciones IPV4, 192.168.12.200 a 192.168.12.240.

WAN: WAN1 (boca dirigida a internet con IP dinámica por DDNS).

Enable: Yes.

Cliente VPN Windows:

Modo: L2TP.

Dirección IP de servidor: dirección dinámica pública asignada, uso un DDNS.

Contraseña pre compartida: 123456.

Usuario: Operador.

Contraseña: 123456.
Cambia a unencrupted
Post automatically merged:

Es lo mismo. Si el router encripta el tunel entonces el otro dispotivo debe ser capaz de desencriptar para establecer comunicacion.
Técnicamente no, el túnel encriptado no es lo mismo que el dato encriptado , pero si la idea es la misma
 
:blahblah:

Local IP Address: IP privada de router 192.168.12.6

VPN IP pool: pool de 41 direcciones IPV4, 192.168.12.200 a 192.168.12.240.


:blahblah:

de lo citado entiendo que tu segmento local es 192.168.12.0/24 y el pool de la VPN el mismo...intenta asignar otro segmento al pool vpn
 
de lo citado entiendo que tu segmento local es 192.168.12.0/24 y el pool de la VPN el mismo...intenta asignar otro segmento al pool vpn
Esas son las ip asignadas a los clientes que ingresen a la LAN, no debiera cambiar el resultado pero vale, nada pierdo :sconf:.

Actualizo, sigue igual, no hay negociación.

El server DHCP tiene asignado desde el 192.168.12.8 hasta el 192.168.12.199, no se solapan y en caso de solaparse las ip el router da aviso.

Tengo hasta las 17 horas de hoy para sacar el cacho, sino, toca ir por el plan B que es menos bonito pero igual de eficaz a modo demostrativo.
 
Última edición:
Esas son las ip asignadas a los clientes que ingresen a la LAN, no debiera cambiar el resultado pero vale, nada pierdo :sconf:.
asi es, las vpn normalmente toman un rango distinto y a través de reglas se pueden ver con el rango lan, por lo que no deberían ser iguales para no crear conflicto. fuente: yo, me ha pasado
Post automatically merged:

@yuseppi2 cuando abriste el tema pusiste:
Como dice el título, estoy dando la real cacha con la conexión del router VPN, puedo crear el túnel entre los dos router VPN de marca TP Link modelo TL R600VPN, pero de forma local (un patch cord entre las primeras tomas WAN), por IPSec, pero no encuentro forma de crear el túnel para el modo cliente-LAN
eso sigue siendo asi? la conexión punto a punto funciona pero al involucrar un cliente que está detrás de alguno de los peer no funciona?
 
Última edición:
oiga hermane pq no monta un servidor en una maquina virtual... asi descartas esa caga de router.
pesque un router casero y chantele un openwrt ... quedan mucho mejores que esas cagas de routers con firmware de fabrica.
o un raspberry-pi :clapclap:

es mas le dejo un dato, openwrt + zerotier.
 
oiga hermane pq no monta un servidor en una maquina virtual... asi descartas esa caga de router.
pesque un router casero y chantele un openwrt ... quedan mucho mejores que esas cagas de routers con firmware de fabrica.
o un raspberry-pi :clapclap:

es mas le dejo un dato, openwrt + zerotier.
Sí, ya fue en todo caso la wea de VPN por router, haré otra cosa, esas cagás de router se los venderé a otro wn/wns cuando termine la tesis, muchos problemas para algo que en teoría es sencillo.

El túnel IPSec punto a punto funcionó en menos de 5 minutos, pero no hay caso para una conexión cliente-LAN.

Ni ahí con algo así de tincado.

OpenWRT zerotier y todo eso, paso la verdad, necesito el equipamiento para diciembre y enero nomás, una muestra de un proceso que al final terminaré haciendo local ya que me dieron la patada al pecho hace poco como para usar la conexión dedicada de dónde haré la presentación del frankestein.

Agradecido por el dato de los equipos de todas maneras chimpadrito, le encontraré algún uso a eso del Raspberry, es atractivo el bajo consumo del bicho y para visión artificial apaña :buenaonda:.

@networker , el punto a punto funcionó sin mayores sobresaltos, la conexión fue limpia y tenía acceso a los recursos de mi servidor con una baja latencia (lo más seguro es por ser una distancia como de 1 metro :lol2:).

Necesito weas que funcionen como dicta el manual y como dice la teoría, no algo a que le deba meter mano, a menos que viva de eso.

Igual probaré si me da el tiempo hacer un VPN dentro del windows server y probar con el rol de Gateway etc etc.
 
al final no me quedó claro el escenario que estabai tratando de configurar, pero creo que era algo como un RoadWarrior? :zippymmm: ikev2/rw-psk-ipv4
Era una conexión por IPSec desde el internet hacia mi servidor detrás de un NAT.

No sé que hice, no me interesa, pero ahora me funciona a toda nalga a través del teléfono.

La maldita wea al parecer pedía prestado algunos parámetros de un servidor cliente-LAN de IPSec para tomar la configuración para el L2TP/IPSec.

Encontré por ahí una recomendación:

Jamás usar AH y MD5 como parámetros para formar el túnel, al menos el TP Link no permite niveles tan bajos de seguridad.

Quedó en SHA1, AES256, DH 5, PFS = 2 para fase 1.

Para fase 2:

ESP, SHA1, AES256.

Funciona, no meteré más mano a la wea para no echar a perder la magia.

------------
Actualizo y cierro.
Para formar el túnel al menos en el TP Link, si va el modo cliente-LAN debe existir 2 políticas previamente.

-Politica IPSec con niveles de seguridad superior a AH y MD5, igual un valor de DPD de 30 segundos no es mala idea para evitar que alguien más tome el túnel si es que quién lo abre está lejos, también una PSK que después se debe volver a escribir en una segunda política.

-Politica L2TP para servidor con niveles de seguridad concordantes a la política IPSec anterior, la PSK también debe ser la misma, debe ir encriptado.

Funciona sin mayores sobresaltos, Wireshark me dió un indicio de que algo estaba mal al momento de revisar las negociaciones que hacía el solicitante y el respondedor, no bajaba de SHA1 y AES128 los parámetros a negociar y por defecto se negociaba lifetime de 28800 para ambas fases.

Besitos de polola a todos quiénes ayudaron.

Carbón con caca de gato a quiénes se vinieron a burlar de mi desesperación :sm:.
 
Última edición:
Volver
Arriba