Saltar al contenido principal

Responsabilidad en WiFi público: por qué el filtrado de contenido es obligatorio

Esta guía de referencia técnica describe los riesgos legales y operativos de ofrecer un WiFi público sin filtrar, detallando por qué el filtrado de contenido es un requisito de implementación obligatorio para los operadores de establecimientos. Proporciona estrategias de arquitectura accionables, pasos de implementación y tácticas de mitigación de riesgos para proteger las redes contra actividades ilegales, infracciones de derechos de autor e incumplimiento regulatorio. Los operadores de establecimientos y directores de tecnología (CTOs) encontrarán casos de estudio concretos, marcos de decisión y pautas de configuración para implementar un entorno de Guest WiFi defendible y en cumplimiento.

By Iain JewittPublished
📖 7 min de lectura1,531 palabras2 ejemplos resueltos3 preguntas de práctica9 definiciones clave

Video overview

Escucha esta guía

Ver transcripción del podcast
Te damos la bienvenida de nuevo al Reporte Técnico de Purple. Soy tu anfitrión, y hoy abordaremos un tema crítico para cualquier operador de establecimiento, gerente de TI o CTO que gestione redes públicas: la Responsabilidad del WiFi Público y por qué el filtrado de contenido ya no es opcional, sino absolutamente obligatorio. Si operas una red en el sector de la hospitalidad, retail o en un gran recinto público, eres un Proveedor de Servicios de Internet a los ojos de la ley. Y eso significa que asumes riesgos. Hoy iremos directo al grano para analizar los riesgos legales de un WiFi público sin filtrar - desde la piratería hasta el contenido ilegal - y exactamente cómo diseñar una solución para mitigarlos. [SEGMENTO 1: EL CONTEXTO Y EL RIESGO] Comencemos con la realidad sobre el terreno. Al desplegar WiFi para invitados, abres un canal directo al internet. Si ese canal no está filtrado, tu dirección IP es la que queda registrada en cada fragmento de tráfico generado por tus usuarios. Estamos hablando de infracciones de derechos de autor, descargas de torrents, acceso a material de abuso sexual infantil y distribución de malware. Si un usuario descarga una película pirata a través de tu red, la carta de cese y desistimiento del titular de los derechos te llegará a ti. Si un usuario accede a material ilegal, la policía llamará a tu puerta. El marco legal en la mayoría de las jurisdicciones ofrece protecciones de puerto seguro para los ISP, pero únicamente si se toman medidas razonables para prevenir el abuso y se puede identificar al usuario. Sin un registro de auditoría y un filtrado activo, pierdes esa protección. Así de sencillo. [SEGMENTO 2: ANÁLISIS TÉCNICO DETALLADO] Entonces, ¿cómo resolvemos esto técnicamente? Requiere un enfoque por capas. No puedes limitarte a confiar en el filtrado de DNS en el borde de la red y dar el asunto por resuelto. En primer lugar, necesitas una autenticación sólida. Aquí es donde entra tu Captive Portal. Recomendamos firmemente implementar 802.1X siempre que sea posible, o como mínimo, un Captive Portal que requiera credenciales verificables - autenticación por SMS, inicio de sesión con redes sociales o integración con una base de datos de fidelización. Debes asociar una dirección MAC y una asignación de IP a una identidad verificada. Este es tu registro de auditoría. El siguiente paso es el motor de filtrado de contenido. Este debe situarse en línea, generalmente integrado con tu gateway o firewall, o bien suministrarse mediante un servicio de filtrado DNS basado en la nube que se integre con tu plataforma de analíticas de WiFi. El filtro debe categorizar el tráfico de forma dinámica. Necesitas políticas que bloqueen dominios maliciosos conocidos, protocolos de intercambio de archivos P2P como BitTorrent y categorías de contenido para adultos o ilegal. Hablemos de cifrado. Con el auge de DNS sobre HTTPS, los usuarios pueden eludir los filtros DNS estándar. Tu arquitectura debe tener esto en cuenta. Necesitas bloquear los resolvedores de DNS sobre HTTPS conocidos a nivel de firewall para forzar al tráfico a volver a tu DNS administrado, o implementar una inspección profunda de paquetes si tu hardware lo permite, aunque la inspección profunda de paquetes introduce una sobrecarga en el rendimiento.Para implementaciones grandes - como un estadio o una cadena minorista importante - el rendimiento es fundamental. No se puede introducir latencia. El filtrado de DNS basado en la nube, combinado con el almacenamiento en caché local, es por lo general el enfoque más escalable. Compara la solicitud de dominio con una base de datos de amenazas en tiempo real antes de resolver la IP. Si está bloqueada, el usuario recibe una página de redireccionamiento que explica la política. [SEGMENT 3: IMPLEMENTATION RECOMMENDATIONS AND PITFALLS] Pasemos a la implementación. El mayor error que vemos es la mentalidad de configurarlo y olvidarlo. Las bases de datos de inteligencia de amenazas se actualizan constantemente; sus políticas deben ser dinámicas. Otro error común es el exceso de filtrado. Si bloquea aplicaciones de negocios legítimas, saturará su centro de soporte con tickets. Necesita una política granular. Bloquee P2P, bloquee malware, bloquee contenido ilegal. Pero asegúrese de incluir en la lista de permitidos los servicios esenciales. Al realizar la implementación en múltiples sitios, la gestión centralizada no es negociable. Necesita un panel de control único para enviar actualizaciones de políticas a todos los puntos de acceso y gateways de forma simultánea. Aquí es donde una plataforma como WiFi Analytics de Purple se vuelve invaluable - une la identidad, la ubicación y la política. Además, asegúrese de que su registro cumpla con las normativas locales, como el GDPR. Debe conservar los registros de conexión - quién se conectó, cuándo y qué IP se le asignó - pero debe hacerlo de forma segura y sólo durante el periodo de retención legalmente exigido. [SEGMENT 4: RAPID-FIRE Q&A] Respondamos a algunas preguntas comunes. Pregunta uno: ¿El filtrado de contenido ralentiza la red? Si se diseña correctamente utilizando el filtrado de DNS en la nube, la latencia es insignificante - por lo general de menos de 20 milisegundos. La inspección profunda de paquetes ralentizará las cosas, así que utilícela de forma selectiva. Pregunta dos: ¿No pueden los usuarios simplemente usar una VPN? Sí, pueden hacerlo. Y usted puede elegir bloquear puertos VPN conocidos si lo desea. Sin embargo, si un usuario está en una VPN, el tráfico está cifrado y sale desde la IP del proveedor de VPN, no desde la suya. La responsabilidad se traslada al proveedor de VPN. Pregunta tres: ¿La aleatorización de MAC es un problema? Sí, iOS y Android aleatorizan las direcciones MAC. Por esto es que la autenticación basada en sesiones a través del Captive Portal es crítica. Usted autentica la sesión, no sólo el hardware. [SEGMENT 5: SUMMARY AND NEXT STEPS] Para resumir: El WiFi público sin filtrar es un riesgo masivo y sin gestionar. Debe implementar filtrado de contenido y una autenticación robusta para proteger su establecimiento, mantener su estado de puerto seguro y garantizar un entorno seguro para todos los clientes. ¿Sus siguientes pasos? Audite su implementación actual. ¿Está registrando las sesiones de manera adecuada? ¿Está bloqueando P2P y contenido ilegal? Si no es así, es momento de actualizar su arquitectura. Gracias por acompañarnos en esta sesión informativa técnica. Manténgase seguro, y nos vemos la próxima vez.

Parte de nuestra serie principal: Guía de seguridad WiFi para empresas

Responsabilidad en WiFi público: por qué el filtrado de contenido es obligatorio

Executive Summary

For IT managers, network architects, and CTOs overseeing public venues, deploying Guest WiFi is a baseline operational requirement. However, providing an open pipe to the internet without robust content filtering exposes the venue to severe legal, financial, and reputational risks. When you provide public internet access, your organisation assumes the role of an Internet Service Provider (ISP). If malicious or illegal traffic — such as copyright infringement, peer-to-peer (P2P) piracy, or Child Sexual Abuse Material (CSAM) — originates from your public IP addresses, the liability often falls on the venue operator.

This guide provides a definitive technical framework for implementing mandatory content filtering. We explore the architecture required to maintain safe harbour protections, ensure regulatory compliance (including GDPR and PCI DSS), and maintain network performance. By integrating robust filtering with WiFi Analytics , venues in Retail , Hospitality , Healthcare , and Transport sectors can mitigate risk while maintaining a seamless guest experience.


Technical Deep-Dive

The primary driver for content filtering is public WiFi legal liability. In most jurisdictions, ISPs and public WiFi providers are protected by "safe harbour" provisions — for example, the Digital Millennium Copyright Act (DMCA) in the US, or the E-Commerce Directive and its successor frameworks in the EU. However, these protections are explicitly conditional. To qualify, providers must demonstrate they have taken reasonable technical steps to prevent illegal activity and can assist law enforcement when required.

Without an audit trail and active filtering, a venue cannot prove it took reasonable steps, which nullifies safe harbour protections entirely. This is particularly critical for public sector deployments, where accountability requirements are even more stringent. For context on how public sector digital infrastructure is evolving, see Purple Appoints Iain Fox as VP Growth – Public Sector to Drive Digital Inclusion and Smart City Innovation .

The three primary legal risk vectors for unfiltered networks are:

Risk Vector Legal Exposure Example Consequence
Copyright Infringement (P2P) Civil liability, cease and desist orders Rights holder sues the venue for facilitating infringement
CSAM Distribution Criminal prosecution Police investigation, licence revocation
GDPR Non-Compliance Regulatory fines up to 4% of global turnover ICO enforcement action for inadequate logging

Architecture of a Filtered Network

Effective content filtering requires a multi-layered architecture. No single control is sufficient. The following layers must work in concert:

Layer 1 — Authentication (Captive Portal): Before network access is granted, users must authenticate. This ties a device (MAC address) and an IP lease to a verified identity via SMS, email, or social login. This is the foundation of your audit trail. For more on why this record-keeping is critical, see Explain what is audit trail for IT Security in 2026 .

Layer 2 — DNS Filtering Engine: The most scalable approach for high-throughput environments is cloud-based DNS filtering. When a user requests a domain, the DNS resolver checks the request against a real-time threat intelligence database. If the domain is categorized as malicious or illegal — malware, adult content, piracy trackers — the resolution is blocked and the user is redirected to a policy-compliant block page.

Layer 3 — Application Layer Gateway (Firewall): DNS filtering alone is insufficient. Users can bypass DNS filters using direct IP connections or encrypted DNS (DNS over HTTPS — DoH). The network gateway must block known DoH resolvers and restrict specific protocols, particularly P2P protocols like BitTorrent, which are the primary vector for copyright infringement on public networks.

Responsabilidad en WiFi público: por qué el filtrado de contenido es obligatorio - content filtering architecture

Layer 4 — Logging and Audit Trail: All session data — authenticated identity, MAC address, assigned IP, timestamps, and session duration — must be logged securely and retained for the legally mandated period. This data must be accessible to law enforcement on request without compromising other users' data under GDPR principles.

Addressing the DoH Problem

DNS over HTTPS (DoH) is the single biggest technical challenge for content filtering in 2025 and beyond. Modern browsers — including Chrome, Firefox, and Edge — can be configured to use DoH by default, routing DNS queries over HTTPS to resolvers like Cloudflare (1.1.1.1) or Google (8.8.8.8). This completely bypasses your managed DNS filtering layer.

The mitigation strategy has two components:

  1. Blocklist known DoH resolver IPs at the firewall level. Maintain an updated list of known DoH endpoints and block outbound HTTPS traffic to those specific IPs.
  2. Intercept and redirect all port 53 traffic to your managed DNS resolver using firewall NAT rules, preventing manual DNS override by guests.

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.

Implementation Guide

Deploying a robust filtering solution requires careful planning to balance security with user experience. The following steps apply to venues of all scales, from a single-site hotel to a multi-location Retail chain.

Step 1: Define the Acceptable Use Policy

Establish a clear Acceptable Use Policy (AUP) that guests must accept at the captive portal. The technical filtering policy must mirror the AUP. At a minimum, block: known malware and phishing domains; CSAM (integrate with databases such as the Internet Watch Foundation blocklist); P2P file-sharing protocols; and adult content for family-appropriate venues.

Step 2: Configure the Captive Portal and Authentication

Ensure the captive portal mandates authentication. Anonymous access is the enemy of the audit trail. Implement session limits and ensure DHCP lease times are optimised for high-turnover environments. For Hospitality deployments, integrate with the Property Management System (PMS) to authenticate guests against their booking reference.

Step 3: Deploy DNS Filtering and Gateway Rules

Integrate a cloud DNS filtering service. Configure the network gateway to intercept all outbound DNS requests on port 53 and force them through the approved filtering service. Implement firewall rules to block known DoH endpoints. Configure application-layer rules to drop P2P protocol traffic.

Step 4: Whitelist Critical Services

Ensure critical venue services are whitelisted before go-live. If your venue uses location services or navigation tools — for example, Purple Launches Offline Maps Mode for Seamless, Secure Navigation to WiFi Hotspots — ensure the relevant endpoints are accessible. Also prepare support teams for common post-deployment issues; filtering can occasionally cause connectivity anomalies, as discussed in Solving the Connected but No Internet Error on Guest WiFi .

Step 5: Test and Validate

Before going live, conduct a structured test: attempt to access known blocked categories from a guest device, verify the block page is displayed, verify the audit log captures the session, and confirm legitimate traffic is unaffected.


Best Practices

Responsabilidad en WiFi público: por qué el filtrado de contenido es obligatorio - liability comparison chart

Dynamic Threat Intelligence: Static blocklists are obsolete within hours of publication. Ensure your filtering engine uses real-time, continuously updated threat intelligence to categorize new domains as they emerge. Threat actors register new domains daily specifically to evade static lists.

Granular Policy Control: Avoid blanket bans that disrupt legitimate business. Blocking all video streaming may be appropriate for a corporate office network but would be entirely inappropriate for a hotel. Define policies per SSID, per venue type, or per time of day where the platform supports it.

Encrypted Traffic Management: As TLS 1.3 and DoH become standard, relying solely on DNS is insufficient. Evaluate hardware capable of Server Name Indication (SNI) inspection as a middle ground between full DPI and DNS-only filtering. SNI inspection reads the unencrypted server name in the TLS handshake without decrypting the payload, offering category-level blocking with minimal throughput impact.

Compliance Logging: Maintain connection logs — MAC address, assigned IP, timestamp, authenticated identity — in compliance with local data retention laws. Under GDPR, do not log full browsing history; log only connection metadata. Ensure logs are encrypted at rest and access-controlled.


Troubleshooting & Risk Mitigation

Common Failure Modes

The DoH Bypass: Guests using modern browsers configured to use DNS over HTTPS will bypass standard DNS filters. Mitigation: Maintain an updated blocklist of DoH provider IPs at the firewall level and redirect all port 53 traffic via NAT.

MAC Randomization: Modern iOS and Android devices randomize MAC addresses per SSID, breaking traditional device tracking. Mitigation: Rely on session-based authentication tied to the captive portal login, rather than persistent MAC tracking. The session ID, not the MAC, becomes the audit key.

Over-Filtering and False Positives: Aggressive filtering blocks legitimate traffic, generating helpdesk tickets and degrading the guest experience. Mitigation: Implement a rapid whitelist review process. Monitor blocked domain logs weekly and whitelist confirmed false positives within 24 hours.

Policy Drift Across Sites: In multi-site deployments, manually managed policies diverge over time. Site A may have an outdated blocklist while Site B is current. Mitigation: Enforce centralised, cloud-managed policy distribution with version control. All sites must pull from the same policy baseline.


ROI & Business Impact

The Return on Investment (ROI) for content filtering is primarily measured in risk avoidance. A single copyright infringement lawsuit or ICO enforcement action can cost tens of thousands of pounds — far exceeding the annual cost of a filtering solution. The table below illustrates the cost differential:

Cost Item Unfiltered Network Filtered Network
Annual filtering solution cost £0 £2,000–£15,000 (scale-dependent)
Copyright infringement settlement £10,000–£100,000+ £0 (mitigated)
GDPR fine (inadequate logging) Up to 4% global turnover £0 (compliant)
Reputational damage / brand impact Significant Minimal
Network performance (P2P removed) Degraded Improved

Furthermore, filtering improves overall network performance. By blocking bandwidth-heavy P2P traffic and malware botnets, you preserve throughput for legitimate guests, improving the user experience and reducing infrastructure strain. When combined with a robust WiFi Analytics platform, the network transforms from an unmanaged liability into a secure, data-generating asset that drives measurable business outcomes.

Definiciones clave

Safe Harbour

Disposiciones legales que protegen a los proveedores de servicios de internet y a los operadores de red de la responsabilidad por las acciones de sus usuarios, siempre que tomen medidas técnicas razonables para prevenir el abuso y puedan colaborar con las autoridades judiciales.

El escudo legal principal para los operadores de establecimientos. El filtrado de contenido y el registro de auditoría son las condiciones técnicas que mantienen el estado de Safe Harbour.

Captive

Una página web que los usuarios deben ver e interactuar con ella antes de que se les conceda acceso a una red pública, utilizada para la autenticación, la aceptación de la AUP y el inicio de la sesión.

El mecanismo principal para establecer la identidad del usuario y crear un registro de auditoría. Sin este, el acceso anónimo hace que el puerto seguro sea insostenible.

Filtrado DNS

El proceso de bloquear el acceso a ciertos sitios web o direcciones IP al interceptar y evaluar las solicitudes del Domain Name System (DNS) contra una base de datos de inteligencia de amenazas antes de resolver la dirección IP.

El método más eficiente y de baja latencia para bloquear contenido malicioso o inapropiado a escala. Adecuado para entornos de alto rendimiento sin requerir hardware DPI.

Registro de auditoría

Un registro cronológico y a prueba de alteraciones de los eventos de la red, que incluye la autenticación del usuario, las asignaciones de concesión de IP, las horas de inicio y finalización de la sesión y la identidad autenticada.

Requerido para responder a las solicitudes de las fuerzas del orden, demostrar el cumplimiento normativo y probar que se tomaron medidas razonables para evitar actividades ilegales.

Inspección profunda de paquetes (DPI)

Filtrado avanzado de paquetes de red que examina la carga útil de datos de un paquete a medida que pasa por un punto de inspección, lo que permite la identificación y el control a nivel de aplicación.

Proporciona el control más granular pero requiere una potencia de procesamiento significativa y puede reducir el rendimiento de la red. Es mejor utilizarlo de forma selectiva para la detección de protocolos de alto riesgo.

DNS sobre HTTPS (DoH)

Un protocolo para realizar la resolución DNS remota a través del protocolo HTTPS, cifrando la consulta DNS para evitar la interceptación o manipulación por parte de los operadores de red.

El principal mecanismo de evasión que debilita el filtrado exclusivo de DNS. Debe bloquearse a nivel de firewall manteniendo una lista de bloqueo de direcciones IP de resolución DoH conocidas.

Peer-to-Peer (P2P)

Un modelo de comunicaciones descentralizado donde cada nodo participante tiene capacidades equivalentes, comúnmente utilizado para compartir archivos a través de protocolos como BitTorrent.

El principal vector de infracción de derechos de autor en redes públicas. Debe bloquearse tanto en la capa de DNS como en la de aplicación (reglas de protocolo/puerto del firewall) para una mitigación eficaz.

Aleatorización de MAC

Una función de privacidad en los sistemas operativos modernos (iOS 14+, Android 10+) que utiliza una dirección MAC aleatoria al conectarse a redes WiFi, lo que evita el seguimiento persistente de los dispositivos.

Rompe el seguimiento de dispositivos tradicional basado en MAC, lo que obliga a los operadores de red a confiar en la autenticación basada en sesiones a través del Captive Portal como el identificador de auditoría principal.

Indicación del nombre del servidor (SNI)

Una extensión del protocolo TLS que permite al cliente indicar a qué nombre de host se está conectando durante el saludo TLS, antes de que se establezca la sesión cifrada.

Permite el bloqueo de contenido a nivel de categoría en el tráfico HTTPS sin descifrar completamente la carga útil, ofreciendo un punto medio entre el filtrado exclusivo de DNS y el DPI completo.

Ejemplos resueltos

Un hotel de 200 habitaciones recibe notificaciones automáticas de infracción de derechos de autor de su proveedor de servicios de internet porque los huéspedes descargan películas por torrent a través del Guest WiFi abierto. Actualmente, el hotel utiliza una red básica WPA2-PSK sin Captive Portal y sin filtrado de contenido.

Paso 1: Eliminar la clave PSK compartida y reemplazarla con un SSID abierto protegido por un Captive Portal. Paso 2: Requerir que los huéspedes se autentiquen usando su número de habitación y apellido mediante la integración con el sistema de gestión hotelera (PMS), o a través de verificación por SMS o correo electrónico. Paso 3: Implementar un servicio de filtrado de DNS basado en la nube integrado con la puerta de enlace de red, habilitando el bloqueo de las categorías "P2P/Intercambio de archivos" y "Software malicioso". Paso 4: Configurar el firewall de la puerta de enlace para bloquear todo el tráfico saliente en los puertos estándar de BitTorrent (6881 a 6889 TCP/UDP) y bloquear los dominios de seguimiento de torrents conocidos a través del filtro de DNS. Paso 5: Implementar reglas de NAT para interceptar todo el tráfico del puerto 53 y redirigirlo al servidor de resolución de DNS gestionado. Paso 6: Habilitar el registro de sesiones para capturar la dirección MAC, la IP asignada, la identidad autenticada y las marcas de tiempo de todas las sesiones.

Comentario del examinador: Este enfoque establece de inmediato un registro de auditoría al vincular cada sesión de red con la identidad verificada de un huésped. Bloquear P2P tanto a nivel de DNS como de puerto proporciona una defensa en profundidad contra la piratería, abordando directamente las notificaciones del proveedor de servicios de internet y restableciendo la protección de Safe Harbour. La integración con el PMS es fundamental en el sector hotelero, ya que elimina el acceso anónimo sin añadir fricciones para los huéspedes legítimos.

Una gran cadena de tiendas minoristas está implementando Guest WiFi en 500 sucursales. Necesitan garantizar el cumplimiento de políticas aptas para toda la familia y evitar la distribución de software malicioso, pero no pueden costear hardware de inspección profunda de paquetes (DPI) de alta latencia en cada sucursal. También requieren una aplicación de políticas coherente en todos los sitios.

Paso 1: Implementar una arquitectura de WiFi en la nube gestionada de forma centralizada con un controlador en la nube que administre los puntos de acceso de las 500 sucursales. Paso 2: Implementar una solución de filtrado de DNS en la nube aplicada a nivel de SSID, configurada de manera centralizada y distribuida a todos los sitios de forma simultánea. Paso 3: Configurar la política centralmente para bloquear las categorías "Contenido para adultos", "Software malicioso", "Suplantación de identidad (Phishing)" y "P2P". Paso 4: Usar el controlador en la nube para aplicar reglas de NAT que redirijan todo el tráfico del puerto 53 al servidor de resolución de DNS gestionado en cada sitio. Paso 5: Configurar un agregador de registros centralizado para recopilar los registros de sesión de los 500 sitios en una única plataforma de gestión de eventos e información de seguridad (SIEM) o de gestión de registros para informes de cumplimiento.

Comentario del examinador: Para entornos de retail altamente distribuidos, el filtrado de DNS en la nube centralizado es la única solución escalable. Introduce una latencia insignificante (normalmente inferior a 20 ms), lo cual es fundamental para los entornos de retail donde la experiencia del cliente es primordial. La gestión de políticas centralizada elimina las variaciones de políticas entre los sitios y garantiza una postura de cumplimiento única. La ausencia de hardware DPI local en cada sucursal reduce significativamente tanto los gastos de capital como los costos operativos de mantenimiento continuo.

Preguntas de práctica

Q1. ¿Su establecimiento está actualizando su Guest WiFi. El arquitecto de red propone eliminar el Captive Portal para crear una experiencia de usuario más fluida, confiando únicamente en un filtro DNS en la nube para bloquear el contenido inapropiado. ¿Cuál es el principal riesgo legal de este enfoque y qué recomendaría en su lugar?

Sugerencia: Considere qué sucede si las fuerzas del orden solicitan información sobre una dirección IP específica utilizada en un momento determinado.

Ver respuesta modelo

La eliminación del Captive Portal elimina la capa de autenticación, lo que significa que no existe un registro de auditoría que vincule una sesión de red con una identidad de usuario específica. Aunque el filtro DNS bloqueará los sitios dañinos conocidos, si un usuario lo evade o comete un acto ilegal que el filtro no detecta, el establecimiento no podrá identificar al usuario. Esto anula las protecciones de puerto seguro, dejando al establecimiento con total responsabilidad. La recomendación es conservar el Captive Portal con autenticación obligatoria y utilizar el filtro DNS como una capa complementaria, no como un sustituto de la verificación de identidad.

Q2. Un usuario se queja de que no puede acceder a una VPN corporativa legítima mientras está conectado a su WiFi de invitados con filtrado. Revisa los registros y ve que la conexión se está interrumpiendo en la puerta de enlace, no a nivel de DNS. ¿Cuáles son las dos causas más probables y cómo resolvería cada una?

Sugerencia: Piense en cómo los firewalls manejan el tráfico cifrado y los puertos no estándar, y cómo funcionan los protocolos VPN.

Ver respuesta modelo

Causa 1: El firewall tiene una política de salida demasiado restrictiva que bloquea los puertos específicos utilizados por el protocolo VPN; por ejemplo, UDP 500 y UDP 4500 para IKEv2/IPsec, o TCP/UDP 1194 para OpenVPN. Resolución: Incluir los puertos VPN estándar en la lista de permitidos para el tráfico de salida mientras se monitorea en busca de abusos. Causa 2: Un motor de DPI está descartando el tráfico del túnel cifrado porque no puede inspeccionar la carga útil y está configurado para bloquear sesiones cifradas no reconocidas. Resolución: Crear una excepción a nivel de aplicación para los protocolos VPN conocidos o desactivar DPI para el tráfico en los puertos VPN estándar.

Q3. Ha implementado una solución sólida de filtrado DNS en la nube en toda la red de su establecimiento, pero su tablero de analíticas de WiFi muestra un consumo de ancho de banda significativo compatible con el tráfico de BitTorrent. ¿Cómo es esto posible si el filtrado DNS está activo y qué controles adicionales necesita implementar?

Sugerencia: El DNS solo resuelve nombres a direcciones IP. Considere cómo el software P2P descubre y se conecta a los pares después del contacto inicial con el rastreador.

Ver respuesta modelo

BitTorrent y otros protocolos P2P utilizan DNS solo para el descubrimiento inicial del rastreador. Una vez que se descubren los pares, el cliente se conecta a ellos directamente a través de la dirección IP, omitiendo por completo el DNS. El filtrado DNS por sí solo no puede detener la transferencia de datos entre pares una vez establecida la conexión inicial. Para resolver esto, debe configurar el firewall de la puerta de enlace de red para bloquear los protocolos P2P utilizando el filtrado de capa de aplicación o bloqueando los rangos de puertos de BitTorrent conocidos (6881 a 6889 TCP/UDP) y el protocolo DHT (UDP 6881). Además, considere habilitar la limitación de ancho de banda para cualquier tráfico P2P restante que utilice puertos no estándar.

¿Tiene preguntas sobre su configuración específica?

Nuestro equipo trabaja con gestores de espacios, responsables de TI e ingenieros de redes en 80 000 establecimientos. Reserve una llamada de 20 minutos y le mostraremos cómo lo resolvieron otros profesionales como usted.