Un bug de macOS 14 Sonoma impide que funcione la app de Mullvad VPN

• En la beta y la versión candidata de macOS 14 Sonoma, el firewall PF no logra filtrar correctamente el tráfico, por lo que la app de Mullvad VPN no funciona con normalidad
• Si ciertas opciones como compartir red local están activadas, esto puede provocar fugas de tráfico, por lo que Mullvad considera difícil garantizar funcionalidad y seguridad en macOS 14
• Mullvad investigó el problema desde la sexta beta y lo reportó a Apple, pero el bug sigue presente en betas posteriores y en la versión candidata
• Revisaron si era posible evitarlo con un parche en la propia app, pero no encontraron una solución segura; en esencia, hace falta una corrección del firewall por parte de Apple
• Los usuarios que dependen del filtrado de PF o de apps relacionadas deben tener cuidado al actualizar a macOS 14, y si el bug sigue presente, lo más seguro es quedarse en macOS 13 Ventura

---

Problema del firewall PF en macOS 14 Sonoma

• Durante el periodo beta de macOS 14 Sonoma, Apple introdujo un bug en packet filter (PF), el firewall de macOS
• Debido a este bug, la app de Mullvad VPN no funciona y, si ciertas opciones están activadas, pueden producirse fugas de tráfico
  • Como ejemplo se menciona compartir red local
• Mullvad investigó el problema después de la sexta beta de macOS 14 y reportó el bug a Apple
• El mismo problema siguió presente en betas posteriores de macOS 14 y en la versión candidata
• Evaluaron si podían parchear solo la app de VPN para mantener tanto el funcionamiento como la seguridad en macOS 14, pero concluyeron que por ahora no hay una buena solución
• El alcance del problema no se limita a la app de Mullvad VPN
  • Las reglas del firewall no se aplican correctamente al tráfico de red
  • Puede pasar tráfico que no debería estar permitido
  • Los usuarios que dependen del filtrado de PF o las apps que lo usan en segundo plano deben tener cuidado al actualizar a macOS 14
• macOS 14 Sonoma está programado para lanzarse el 26 de septiembre, y si el bug sigue presente, se recomienda que los usuarios de Mullvad permanezcan en macOS 13 Ventura hasta que haya una corrección

Pasos de reproducción y resultado real

• Es posible reproducir el problema en macOS 14, y este experimento elimina las reglas del firewall cargadas en PF
• En la terminal, se crea una interfaz virtual de registro y se monitorea el tráfico que coincida con las reglas que se agregarán después

sudo ifconfig pflog1 create
sudo tcpdump -nnn -e -ttt -i pflog1

• En el archivo pfrules, se escriben las siguientes reglas del firewall

pass quick log (all, to pflog1) inet from any to 127.0.0.1
block drop quick log (all, to pflog1)

• En otra terminal, se activa PF y se cargan las reglas

sudo pfctl -e
sudo pfctl -f pfrules

• Se envía un ping al servidor web de mullvad.net

ping 45.83.223.209

• El resultado esperado es que el ping sea bloqueado porque no coincide con la condición de la única regla pass, y que el tráfico quede registrado en pflog1 como coincidente con la regla block
• En la práctica, el ping sale a Internet y vuelve con respuesta, y el tráfico no queda registrado en pflog1
• Después del experimento, se desactiva el firewall y se eliminan todas las reglas

sudo pfctl -d
sudo pfctl -f /etc/pf.conf

[GN⁺]

Opiniones en Hacker News

• El mismo bug de PF también está rompiendo una de las funciones de red de OrbStack.
  Me costó creerlo cuando acoté la causa hasta aquí, pero parece que no soy el único al que le pasa. Espero que lo arreglen sí o sí antes del lanzamiento estable.
  Recién ayer pude reportarlo a Apple; parece una regresión bastante reciente, probablemente desde alrededor de la beta 6.
  Se supone que PF es un firewall donde se aplica la última regla que coincide, pero macOS parece comportarse casi como si aplicara la primera regla coincidente. Una regla block al principio sobrescribe reglas pass de otros anchors incluso sin quick, lo que obviamente causa problemas.

  • “De verdad espero” no alcanza. Esto tiene que arreglarse antes del lanzamiento.
    Si la versión estable sale así, sería inaceptable y, para mí personalmente, sería una razón para dejar Mac OS. Si quieren que se use para trabajo serio, no pueden sacar un producto con una regresión como esta.

• Me gusta que el artículo sea muy conciso e informativo, y que incluso incluya pasos simples para reproducir el bug.
  Me cae bien Mullvad.
  Como comentario al margen, macOS ha tenido en general muchos bugs raros de firewall en los últimos lanzamientos, y me pregunto por qué tuvieron que rehacer esa parte del firewall.

  • La reescritura seguramente estuvo influida por la migración forzada, al pasar de Catalina a Big Sur, desde las extensiones de kernel hacia System Extensions en espacio de usuario, especialmente NetworkExtension: https://developer.apple.com/documentation/networkextension
  • Si te preocupan este tipo de bugs en la plataforma del sistema operativo local, también podrías considerar abstraer tu punto de acceso local con un navegador remoto.
    Sin importar cuál sea tu máquina local y tu sistema operativo, puedes enrutar la navegación a través de un servidor dedicado. No encapsula toda la conexión de red, solo la navegación, pero dentro de ese alcance cambia la dirección IP, oculta la ubicación y añade protección contra zero-days del navegador.
    En BrowserBox seguimos agregando funciones que respetan y protegen la privacidad y mejoran toda la experiencia. Es open source, así que también puedes modificarlo como quieras. Si no te gusta AGPL-3.0, también hay licencia comercial: https://github.com/dosyago/BrowserBoxPro
    Si no te gusta el open source y prefieres la comodidad de una empresa grande, parece que Mullvad también tiene Mullvad Browser, que hace algo parecido.
  • Habría estado aún mejor si incluyera también el número de rdar/Feedback.
  • macOS intentó evolucionar su stack de red durante años, pero cuando aparecían regresiones solían revertir los cambios.
    Artículo antiguo relacionado: https://9to5mac.com/2015/05/26/apple-drops-discoveryd-in-lat...

• Este código de reproducción se ve realmente bien.

  • Que sea simple está bien, pero me gusta especialmente que incluya también la etapa de limpieza. Es algo que suele faltar en este tipo de pasos de reproducción.
  • Me parece que simplemente configura una regla de firewall sencilla e intenta hacer una consulta que viola esa regla.
    Claro, ese es el alcance del bug, pero no me parece que esta prueba sea especialmente sofisticada ni hermosa.

• No sé si está relacionado, pero después de las dos últimas actualizaciones de macOS la red dejó de funcionar.
  Podía conectarme a Wi‑Fi, Ethernet y hotspot, pero ninguna conexión real funcionaba, ni en el navegador ni con ping, y ni siquiera podía llegar al router.
  En ambas ocasiones, con solo abrir una vez la app de Mullvad VPN, todo volvió a funcionar. No sé por qué abrir la app solucionaba el problema.

  • La app de VPN modifica la tabla de ruteo, así que parece que, hasta que ejecutabas la app de VPN, el tráfico se estaba enrutando hacia una interfaz inexistente.

• No está del todo relacionado, pero también existe otro bug viejo: el bug de 11 años de Popen() en macOS: https://news.ycombinator.com/item?id=37238433

  • Si es tu bug, conviene enviar también un Feedback junto con el parche. El proyecto open source normalmente no acepta PR.

• Como referencia, con Mullvad.app tuve problemas de conexión, pero al ejecutar la configuración de Mullvad WireGuard desde Wireguard.app funcionó bien.

• Ahora entiendo por qué, tras instalar la beta más reciente de Sonoma, no pude hacer funcionar Mullvad de ninguna manera.
  Me alegra que Mullvad esté trabajando en una solución alternativa. Esta mañana incluso pensé en hacer downgrade a Ventura, pero ahora siento que efectivamente era mi problema.

  • No dice que estén trabajando en una solución alternativa. Dice que los usuarios no deben actualizar a Sonoma hasta que Apple corrija el bug.
  • La combinación tailscale/mullvad parece que todavía funcionaría. Podría ser una solución alternativa razonable hasta que Apple lo arregle.

• Me alegra que Mullvad esté aumentando la presión pública sobre este problema. Este bug definitivamente se notaba y era bastante preocupante.

  • ¿Esto ya se conocía en otros lados? Parece que Mullvad lo reportó después de la sexta beta, y para ese momento ya estaba bastante cerca de la RC.
    En el texto original dice: “we have investigated this issue after the 6th beta was released and reported the bug to Apple”.

• En mi caso, la solución fue descargar la configuración de WireGuard y usar la app Wireguard.

  • ¿Pero la app de Wireguard no hace que se filtren datos y es menos segura que la app de Mullvad?
  • Solo es una solución si no pones reglas de firewall PostUp y PostDown en la configuración de WireGuard. Entonces difícilmente pueda llamarse solución.

• Pregunta: si no se crea pflog1, ¿pf funciona como se espera?
  Si tcpdump no registra nada que salga por pflog1, eso parece significar que los datos no se están enviando a pflog1. Entonces implicaría que el problema está en una etapa anterior.
  ¿pflog1 estaba conectado y levantado? Antes había que conectar y levantar la interfaz manualmente. ¿MacOS lo hace automáticamente?
  Por supuesto, aislar esto no es trabajo de quien reporta el bug. Pero en algún momento el ingeniero responsable va a hacer estas preguntas, así que conviene tener las respuestas preparadas.

  • ¿Hay algo que se pueda agregar a los pasos de reproducción como workaround? Por ejemplo, como dices, conectar y levantar la interfaz después de cargar las pfrules.
  • Después, para eliminar la interfaz adicional, también hay que hacer esto:
    ifconfig pflog1 destroy