Acceso desde VPN a mi pfsense dentro de red corporativa V2.3
-
Hola
OK. me alegro que se haya resuelto.
Edita el nombre del hilo, y añade [RESUELTO], así el que busque un problema similar lo tiene más facil de encontrar.
Salu2
–-add--
¿Donde creas la ruta en "tu pf"? ¿te refieres a reglas del firewall?¿o a rutas estáticas vía shell?
-
No hace falta hacerla de la Shell, puedes hacerlas desde pfSense en:
System/Routing allí agregas los GW que desees y las rutas estáticas que desees.
Saludos
-
Hola
Ok, puedes añadir Gateways. Pero siempre que he añadido GWs, son para salir a Inet, no para enrutar a la LAN
Mmm, Esa topología no es una red stub.
¿Entonces para que la interfaz LAN del pfSense sepa donde esta 10.10.x.y/z, le tienes que indicar un GW en routing > gateway > 10.10.x.y (el servidor openVPN)?.
No me queda muy claro. Es mas teniendo pfSense ¿para que crear un servidor openVPN, si el pfSense implementa esos tuneles de maravilla?
En fin, a ver si los que postean ponen un diagrama de su red … jaja :)
Salu2
-
No, disculpa que me atreva a decir esto, pero creo que no tienes muy claro como funcionan las redes…
No tengo esa topología, no tengo VPN en otro server, pero es posible que eso exista, y no es descabellado, incluso teniendo pfSense...
Ahora bien, entiendo que el amigo que posteó su problema tiene un pfSense, con su puerto WAN y LAN
WAN: 200.x.x.x
LAN: 172.20.x.x/24 (imaginemos que el CIDR de ese segmento es /24)
Default GW: 200.x.x.1 (por ejemplo)Cuando el pfSense tiene una conexión por 172.20.x.x va a responder por LAN y el Switch se encarga de enviar ese paquete a su destino, ya que tanto el pSense como el Switch conocen la red 172.20.x.x/24
Cuando hay una petición por cualquier red que no sea 172.20.x.x/24, sencillamente el pfSense lo va a mandar por su default GW que en este caso y por razones obvias es el GW de la WAN. y ojo, cuando digo cualquier red, incluye por ejemplo 172.16.x.x 172.19.x.x o cualquier otra privada que te guste :) es por ello que se crean los GW y las rutas.
En este caso, si el segmento 172.20.x.x/24 debe tener su dafault GW un switche con dirección (ejemplo) 172.20.0.1 y BroadCast 172.20.0.255 y Red 172.20.0.0 entonces, configuras un nuevo GW llamado por ejemplo GW_LAN y pones 172.20.0.1
Luego creas rutas estáticas, por ejemplo:
RED Gateway
192.168.0.0/16 GW_LAN
10.0.0.0/8 GW_LAN
172.16.0.0/12 GW_LANEntonces, cuando haya una petición de redes privadas, el pfSense enviará esos paquetes a la 172.20.0.1 y entonces el SW se encargará de mandarlos a donde vayan, de ese modo, el pfSense no los mandará al internet (que obviamente no las conseguirá y no habrá respuesta).
No recomiento para nada hacer esas rutas estáticas tan generales, solo es a una manera de ejemplo para que se vea de manera didactica.
Saludos.
-
Hola
Confused to what part do you not understand that you do NOT set a gateway on your pfsense lan.. If you did its no longer a lan but a WAN..
Pfsense lan IP would be the gateway for your lan clients to get off that LAN..
I think you don't quite grasp what a gateway actually is??
What are you trying to do exactly. Typical setup as muswell explained attached.
pfSense es un firewall perimetral , no se ponen gateways en sus redes lan ..
Otra forma seria o añadir un interfaz para la red 10.x.x.x.x o usar vlans
Salu2
(nota: mi certificado ccna dice que algo de redes sí sé :) )
–- add ---
Las importancia de poner diagramas de red y preguntar con los datos completos (no dejar lugar a la adivinación) es crucial
No se puede confundir una interfaz de una red local con una interfaz de una red WAN (con salida a Inet ,aunque pueda tener direccionamiemnto de capa 3 de red privada, ya que el pfSense a veces no es el router frontera a Inet).
Y se pueden tener redes muy complicadas y muchas interfaces wan y lan, y virtualIPs, etc, pero nunca en una interfaz de una red local (LAN) se pone un GW (es de manual) al menos en pfSense. Que yo sepa :)
-
Eso fue le que hice exactamente pero lo malo fue que el personal de redes no me creo la ruta correcta había un detalle en las ips de mi gw que me hacia no llegarle a mi red de mi servidor vpn que esta actualmente detras de un proxy/firewall con una ip del rango 170.179.0.0/24, por ende al hacer la peticion hacia la web del pf no sabia para donde ir ya que el pf no tenia la red 170.179 declarada por eso no le llegaba a ese segmento.
Cabe destacar que la VPN esta en otro server con otra distro ya que en su momento no se contaba con un personal en ese cargo y alguien ( no se quien) contrato esos servicios con un tercero. Pero ahora estamos retomando este tema y por eso estamos probando varias distros entre ellas pfsense lo que no se es que tan confiable sea para una arquitectura tan grande como algo como 4000 usuarios a nivel nacional.
Esa es mi pregunta jeje saludos
-
Efectivamente, cuando se usa como firewall perímetral, pero en este caso, la openvpn evidentemente está fuera de ese perímetro.
Sí, lo ideal es tener más interfaces, o usar VLANs, sin embargo, mi post era exclusivamente para resolver el problema puntual, las asesorías de redes se facturan aparte ;D
Por otro lado, tengo mis reservas con usar Trunking, sino puedes leer los CVEs. CVE-2008-4963, CVE-2006-4776, CVE-2006-4775, CVE-2006-4774, CVE-2005-4826, CVE-1999-1129
Por otro lado, las topologías de redes pueden ser muy variadas, grandes, etc. y es posible que tengas un pfSense y que no sea precismente el perímetro, como se usa en muchos casos funcionando como Portal Cautivo o Proxy para Navegación, o router/firewall de contingencia con enlaces secundarios… etc.
Cuando comenté lo de que no entendías las redes, era sencillamente porque la regla en el pfSense no iba a resolver nunca el problema, porque el problema de raiz era enrutamiento, y era demasiado evidente. Ahora bien, una vez resuelto el problema de enrutamiento, sí se podría hablar de revisar reglas; pero posteriormente.
Fíjate que el problema efectivamente era enrutamiento :-)
(Nota: No tengo certificado ccna, pero creo que se un poquito de redes :D )
-
Hola
La proxima vez, si especificas desd el principio que tienes al server openVPN en la WAN (desde el punto de vista del pfSense)
Seguro que lo dejabas más claro.No es lo mismo
– server openvpn ---lan -- pfsense --- wan --- inet
que esto
--- lan --- pfsense --- wan 1 ---
|--- wan 2 -- openvpn server ---Saber, no es adivinar :)
Salu2
--- add --
deberias poner [resuelto] en el nombre de tu hilo, es una cortesía que se agradece cuando se busca en el foro (no podemos adivinar si se ha resuelto un problema o no, solo con el nombre del hilo inicial , :) )
-
No puedo especificar una red que no es mía :D solo tomé los datos de quien posteó el problema para intentar ayudar.
Sobre los dos escenarios que planteas, el segundo es como presumí que está, y así lo entendí, por eso mis respuestas; ahora bien, si entendiste que era como el primero, la verdad es que allí creo que no hubiese habido problema, la tabla de enrutamiento de los SW se hubiese encargado de todo, " – server openvpn ---lan -- pfsense --- wan --- inet " <--- así lo describes, y si te das cuenta, entre server openvpn y pfSense está una LAN que habla con los dos... por ende, conoce las rutas de "los dos segmentos"
Pero bue... si es cuestión de mal entendimiento, ciertamente quien postea debe ser más específico para que todo quede claro, al menos poner parte de su estructura de red donde tiene el problema.
Saludos
-
Hola.
Disculpa rodria, pero no iba a ti dirigido mi anterior hilo. No te sientas aludido
He currado en soporte o helpdesk y alucino la de veces que por no explicar claramente un tema se podía resolver algo más rapìdamente. Hay que reaprender a preguntar y dar los datos, "sin rollo" y no ser avaro en datos (al menos los mínimos, interfaces, diagrama o topología lógica de la red simple, etc) nadie lee las mentes, excepto los adivinos, jaja :)
Y sigo insistiendo que para una LAN no se especifican rutas o gw en un pfSense o firewall perimetral.
Lo demás es confundir terminología y llevar a confusión a gente más neófita.Salu2
– add--
Si el firewall de la red es para proteger la red .. ¿Quien pone servidores expuestos a Inet?, :) , es de sentido común, el guardian por delante siempre, y como mucho routers en modo bridge o balanceadores (switches de capa 3 que hacen ese trabajo, etc, en fin, buen jueves (lo que queda ;) )