Si utiliza un servidor alterno (proxy) BorderManager® para redireccionar las peticiones al servidor iFolder, tenga en cuenta que las cargas en el servidor iFolder son muy lentas.
Este problema se puede solucionar introduciendo en la consola del servidor BorderManger lo que se indica a continuación:
set tcp delayed ack=off
Si los ajustes del servidor alterno (proxy) del Cliente iFolder fallan, éste último intenta conectarse directamente (desviándose del servidor alterno (proxy)).
Cuando se utiliza un servidor alterno (proxy) autenticado, los usuarios internos (privados) pueden acceder sin proporcionar las credenciales de autenticación si el reenvío de IP está habilitado. Para evitarlo, cerciórese de que el reenvío IP está inhabilitado en el servidor alterno (proxy).
Cuando la autenticación del servidor alterno (proxy) está habilitada, el puerto de escucha por defecto es el 443. Si iFolder 2.1 y BorderManager están en ejecución en el mismo servidor y la autenticación del servidor alterno (proxy) está habilitada, iFolder o BorderManager deberán escuchar con otro puerto.
Si iFolder se ejecuta en un segmento privado y el acceso público está permitido (mediante NAT), la configuración del servidor iFolder tiene especificada una dirección de acceso pública. Todas las peticiones a la dirección privada se reenvían a esta dirección pública. Cuando intente acceder a iFolder desde el segmento privado, el usuario encuentra el problema de retrobucle de NAT y la conexión falla.
La solución consiste en utilizar un nombre DNS como dirección de acceso de usuario en la configuración del servidor iFolder y resolver este nombre en la dirección pública para los usuarios públicos y en la dirección privada para los usuarios internos.