Carpetas compartidas en entornos Windows
-
Hola
Tengo VPN funcionando correctamente con el siguiente escenario.
Servidor OpenVPN
- Modo servidor: Acceso remoto (SSL/TLS)
- Protocolo: TCP
- Modo dispositivo: Tunel
- Interface: WAN
- Puerto local: 1194
Configuración tunel
- Red tunel IPV4: 172.168.1.0/24
- Red LAN IPV4: 192.168.2.0/24
Reglas firewall
WAN: IPv4 TCP * * WAN address 1194 (OpenVPN) * none
openVPN: IPv4 * * * * * * nonePuedo hacer las siguientes funciones:
- Pingear a 192.168.2.X (desde clientes remotos en 172.168.1.X)
- Pingear a 172.168.1.X (desde clientes en 192.168.2.X)
- Acceder a servidor Apache web en 192.168.2.X (desde clientes remotos en 172.168.1.X)
- Acceder a servidor mySQL en 192.168.2.X (desde clientes remotos en 172.168.1.X).
Que hice:
- Activar Compartir impresoras y archivos en clientes remotos (172.168.1.X)
- Desactivar firewall para conexion TAP9 en clientes remotos (172.168.1.X)
Que no puedo:
- Acceder a carpetas compartidas en clientes remotos y no remotos.
Por ejemplo
(donde temp es el nombre de la carpeta compartida)\192.168.2.X\temp (desde clientes remotos en 172.168.1.X)
ó
\172.168.1.X\temp (desde clientes en 192.168.2.X)Si bien he estado mirando en foro acerca de problemas similares al mio no puedo dar con la solución.
-
http://forum.pfsense.org/index.php/topic,59116.msg318295.html#msg318295
Y estar seguro de que tus reglas admiten compartición de archivos Windows (también llamada Samba o CIFS).
http://www.bellera.cat/josep/pfsense/alies_cs.html (ver alias samba).
De todas maneras eso no irá muy rápido (internet, encriptación vpn…)
-
Hola
He seguido las instrucciones de los 2 links arriba mencionados pero el problema persiste.
¿ Al intentar acceder al recurso compartido \172.168.1.X\temp queda registro en logs de Windows ó pfsense del motívo por el cuál no pudo cumplirse con la instrucción indicada ?
-
Los Windows suelen tener el firewall activado, limitando la compartición de archivos/impresoras a su subred.
Prueba desactivando el cortafuegos de Windows.
Si funciona, lo ajustas para que admita compartición de archivos/impresoras desde las subredes en cuestión. Y lo activas de nuevo.
-
No relacionado directamente con tu problema, pero tienes alguna razon en especial para usar OpenVPN sobre TCP? Sobre UDP anda bastante mejor, sobre todo si la conexion no es de lo más confiable del mundo
-
Buenas
He probado con ambos protocolos, he leido respecto a que TCP entrega los paquetes si o si, respecto a UDP que no se preocupa si no llega alguno de ellos.
Entiendo que mi problema es más un tema del entorno Windows.¿Alguien me podria explicar si incluyendo en Opciones Avanzadas, pesta Servidor,
route 172.168.1.0/24 255.255.255.0;push "route 192.168.2.0 255.255.0.0";route 192.168.1.0/24 255.255.0.0
ayudaría en algo a mi problema?172.168.1.0= red túnel
192.168.2.0= red detrás pfSense en el igual sitio fisico
192.168.1.0= red pcs detrás del túnel en ubicación remota. -
Hola.
Creo que udp es mejor por cuestiones de desempeño.
Por otro lado , en los logs de firewall se puede ver que tráfico está siendo descartado.
Te sugiero que coloques una regla en el firewall que explícitamente permita el tráfico que quieres pasar entre las dos redes y especifiques que este tráfico se registré en el log.
Sí tienes antivirus con firewall integrado, hay que agregar la re remota como de confianza.
Saludos
Athiel
-
Respecto a lo de TCP y UDP, considera que estas encapsulando tráfico TCP sobre protocolo UDP. Si se pierde un paquete, el TCP "de adentro" es el encargado de retransmitirlo. Si usas la VPN sobre TCP se estaría retransmitiendo 2 veces, lo que ocasiona la pérdida de rendimiento.
Respecto a tu problema en particular, si hay otro tráfico que pasa a través de la red y la regla de OpenVPN esta puesta para permitir todo, entonces el problema no es pfSense. Es algo de la configuración de los clientes. El default gateway de los mismos es el mismo pfSense que maneja la VPN?
Considera también que tienes que usar necesariamente la IP y no el hostname para acceder a los recursos compartidos, ya que la resolución de nombres NetBIOS no funciona en subredes separadas
-
En los clientes remotos de la VPN la puerta de enlace no tiene valores, si te refieres a default gateway. PFsense tiene cargado dyndns ya que mi proveedor ISP tiene IP dinámica. Intendo acceder a las carpetas compartidas a través de su IP por ejemplo \172.168.1.X\carpeta compartida desde el explorador de Windows sin conseguirlo por el momento.
-
Perdón, escribí cualquier cosa. Esto tiene que ser un problema de la configuración de las PCs que hacen de servidores de archivos. La puerta de enlace de estas PCs es el pfSense?
-
En los clientes remotos con Windows XP solo tiene activado Compartir impresoras y archivos en sus respectivas propiedades de conexion de red y he probado en activado y desactivado el firewall para esa conexion en particular.
Puerta de enlace veo que no le asigna ninguna PFsense instalado remotamente. -
Esta bien, pensé que era al revés (que los servidores de archivos estaban en la red local y los querías acceder desde los clientes remotos). En cualquier caso no parece ser un problema de pfSense
-
¿Alguien me podria explicar si incluyendo en Opciones Avanzadas, pesta Servidor,
route 172.168.1.0/24 255.255.255.0;push "route 192.168.2.0 255.255.0.0";route 192.168.1.0/24 255.255.0.0
ayudaría en algo a mi problema?172.168.1.0= red túnel
192.168.2.0= red detrás pfSense en el igual sitio fisico
192.168.1.0= red pcs detrás del túnel en ubicación remota.Si los ping y los tracert van y vienen desde ambos lados, no es un problema de enrutamiento.
Además, las rutas que dices ya las establece la propia conexión OpenVPN. En Diagnostics - Routes puedes ver las rutas que tiene pfSense. Mediante el comando route puedes ver en los Windows sus rutas.
Sólo se me ocurre que tengas un problema de permisos (reglas) en pfSense o en el cortafuegos de los equipos Windows.
O que interfiera tener activado IPv6 en las interfases. Algunos usuarios han manifestado (en algunos casos) problemas con IPv6. Si no es necesario, probar qué pasa desactivándolo.
