Cómo resolví el IP Allowlisting obligatorio en Marketing Cloud Engagement siendo freelance

· 12 min de lectura

EN · ES · CA

Una guía paso a paso para consultores que trabajan con varias instancias de MCE, con IP dinámica y desde cualquier sitio.

Por qué lo necesitaba

Salesforce va a hacer obligatorio el IP Allowlisting en modo bloqueo (Log Violations and Deny Access) en todas las cuentas de Marketing Cloud Engagement. Afecta tanto al login de la interfaz como al acceso por API, no hay opt-out y se está aplicando por oleadas hasta enero de 2027. Cada cuenta recibe un email con su fecha. Algunas cuentas pasan a bloqueo el 15 de octubre de 2026.

Ese día, Salesforce aplica una lista inicial de rangos de IP basada en los accesos correctos de los últimos seis meses. Si entras desde una IP que no está en la lista, te bloquea.

Es un problema real si:

  • trabajas con varios clientes, cada uno con su cuenta de MCE,
  • tienes IP dinámica en casa,
  • quieres trabajar desde un hotel, un aeropuerto o un coworking,
  • y no quieres depender de la VPN corporativa de cada cliente.

Mi objetivo era sencillo: una IP fija que pueda dar a todos mis clientes, que funcione desde cualquier sitio y que solo afecte al tráfico de Marketing Cloud.

La solución de un vistazo

Portátil ──(WireGuard)──> Servidor UE, IP fija ──> Marketing Cloud
   │
   └──(directo)──> Todo lo demás (Salesforce core, YouTube...)
  • Un servidor cloud pequeño en la UE con una IPv4 pública fija.
  • Un túnel privado WireGuard entre mi portátil y ese servidor.
  • Un pequeño proxy en el servidor, accesible solo desde dentro del túnel.
  • Un archivo PAC que le dice al navegador: los dominios de Marketing Cloud van por el proxy, todo lo demás va directo.
  • Postman y los scripts de API usan el mismo proxy.

El resultado: Marketing Cloud siempre ve la misma IP. Mi navegación normal, las videollamadas y las orgs de Salesforce core siguen saliendo por mi conexión de siempre.

Antes de empezar

¿Por qué no una VPN comercial? Las IPs de las VPN compartidas cambian y las usan miles de personas. Añadirlas a un allowlist le quita todo el sentido. Además, desde abril de 2026 Salesforce core bloquea las conexiones desde VPN anonimizadoras e IPs de alto riesgo, y puede congelar el usuario. Con este montaje, el tráfico de core nunca pasa por el servidor, así que ese riesgo no existe.

Qué necesitas:

  • Un Mac o un PC con Windows. Yo lo monté en un Mac, así que los pasos principales usan macOS. La parte del servidor es igual para cualquier sistema, y después del paso 6 hay una sección con los equivalentes para Windows.
  • Unas dos horas.
  • Una cuenta en un proveedor cloud. Yo usé Hetzner Cloud (Alemania). OVHcloud o Scaleway también sirven. Elige un servidor en la UE si a tus clientes les importa el RGPD.
  • Soltura básica con el Terminal.

Coste (octubre de 2026): el servidor más pequeño que pude contratar me salió por unos 14,50 € al mes con IVA (servidor más IPv4), facturado por horas y sin permanencia. Como autónomo, es un gasto de la actividad. Hay planes más baratos, pero no tenían disponibilidad cuando lo monté.

Paso 1. Crea una clave SSH en tu Mac

En el Terminal:

ssh-keygen -t ed25519 -C "you@yourdomain.com"
cat ~/.ssh/id_ed25519.pub
  • Pulsa Enter para aceptar la ubicación por defecto. Si te pregunta si quieres sobrescribir una clave existente, contesta n y usa la que ya tienes.
  • Ponle una passphrase y guárdala en tu gestor de contraseñas.
  • Copia la línea que empieza por ssh-ed25519. Es la clave pública y se puede compartir. La privada no sale nunca de tu Mac.

Para no tener que escribir la passphrase cada vez:

ssh-add --apple-use-keychain ~/.ssh/id_ed25519

Paso 2. Crea el servidor

En la consola de tu proveedor:

  1. Tipo: el plan más pequeño de vCPU compartida. No necesitas CPU dedicada; WireGuard apenas consume.
  2. Ubicación: UE.
  3. Imagen: Ubuntu LTS.
  4. Red: activa una IPv4 pública. Es la IP que darás a tus clientes.
  5. Clave SSH: pega tu clave pública.
  6. Crea el servidor y apunta su IPv4.

Después, dos ajustes importantes:

  • Firewall: crea uno que solo permita entrada por TCP 22 (SSH) y UDP 51820 (WireGuard), y aplícalo al servidor.
  • Protege la IP: activa la protección contra borrado de la IPv4 y, si tu proveedor lo permite, desactiva el borrado automático. Si la IP cambia, tendrás que pedir a todos tus clientes que actualicen su allowlist.

Activa también la autenticación en dos pasos en la cuenta del proveedor y guarda bien los códigos de recuperación. Quien controle esa cuenta controla la IP en la que confían tus clientes.

Paso 3. Configura el servidor

Conéctate desde tu Mac:

ssh root@YOUR_SERVER_IP

Y pega este bloque entero. Instala WireGuard y el proxy, aplica un endurecimiento básico y, al final, muestra la configuración para tu portátil.

export DEBIAN_FRONTEND=noninteractive
apt update && apt -y upgrade
apt -y install wireguard tinyproxy unattended-upgrades
dpkg-reconfigure -f noninteractive unattended-upgrades

# SSH with keys only
echo "PasswordAuthentication no" > /etc/ssh/sshd_config.d/99-hardening.conf

# Prefer IPv4 for outgoing connections (your allowlist uses the IPv4)
echo "precedence ::ffff:0:0/96 100" >> /etc/gai.conf

SERVER_IP=$(curl -4 -s https://ifconfig.me)

# WireGuard keys and config
mkdir -p /etc/wireguard && cd /etc/wireguard
( umask 077
  wg genkey | tee server.key | wg pubkey > server.pub
  wg genkey | tee laptop.key | wg pubkey > laptop.pub
  cat > wg0.conf <<EOF
[Interface]
Address = 10.8.0.1/24
ListenPort = 51820
PrivateKey = $(cat server.key)

[Peer]
PublicKey = $(cat laptop.pub)
AllowedIPs = 10.8.0.2/32
EOF
)
systemctl enable --now wg-quick@wg0

# Proxy, only listening inside the tunnel
cat > /etc/tinyproxy/tinyproxy.conf <<EOF
User tinyproxy
Group tinyproxy
Port 8888
Listen 10.8.0.1
Timeout 600
LogLevel Info
MaxClients 50
Allow 10.8.0.0/24
ConnectPort 443
EOF
mkdir -p /etc/systemd/system/tinyproxy.service.d
printf "[Unit]\nAfter=wg-quick@wg0.service\nRequires=wg-quick@wg0.service\n" \
  > /etc/systemd/system/tinyproxy.service.d/override.conf

# PAC file, served only inside the tunnel
mkdir -p /srv/pac
cat > /srv/pac/mc.pac <<'EOF'
function FindProxyForURL(url, host) {
  if (dnsDomainIs(host, ".exacttarget.com") ||
      dnsDomainIs(host, ".marketingcloudapis.com") ||
      dnsDomainIs(host, ".marketingcloudapps.com") ||
      dnsDomainIs(host, ".exct.net")) {
    return "PROXY 10.8.0.1:8888";
  }
  return "DIRECT";
}
EOF
chmod 755 /srv/pac && chmod 644 /srv/pac/mc.pac

cat > /etc/systemd/system/pac-server.service <<'EOF'
[Unit]
Description=PAC file server
After=wg-quick@wg0.service
Requires=wg-quick@wg0.service

[Service]
ExecStart=/usr/bin/python3 -m http.server 8080 --bind 10.8.0.1 --directory /srv/pac
User=nobody
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable --now tinyproxy pac-server
systemctl restart tinyproxy

echo "=========== CONFIG FOR THE WIREGUARD APP ON YOUR MAC ==========="
cat <<EOF
[Interface]
PrivateKey = $(cat /etc/wireguard/laptop.key)
Address = 10.8.0.2/32

[Peer]
PublicKey = $(cat /etc/wireguard/server.pub)
Endpoint = ${SERVER_IP}:51820
AllowedIPs = 10.8.0.1/32
PersistentKeepalive = 25
EOF

Importante: el bloque que aparece al final contiene la clave privada de tu portátil. Cópialo directamente en la app de WireGuard (siguiente paso). No lo pegues en un chat, un ticket ni un email. Si lo haces por error, genera un par de claves nuevo.

Cuando lo tengas en la app, borra la copia del servidor:

rm /etc/wireguard/laptop.key

Paso 4. Configura WireGuard en tu Mac

  1. Instala WireGuard desde la Mac App Store.
  2. Pulsa la flechita junto al + (abajo a la izquierda) y elige Añadir túnel vacío. No uses "Importar desde archivo", que te pide un archivo.
  3. Borra el contenido por defecto y pega el bloque entero del paso anterior, con las secciones [Interface] y [Peer].
  4. Ponle nombre, activa Bajo demanda para Wi-Fi y Ethernet con Cualquier SSID, y guarda.
  5. Actívalo. Si macOS te pide permiso para añadir una configuración VPN, acéptalo.

Por qué importa AllowedIPs = 10.8.0.1/32: solo el tráfico hacia el proxy pasa por el túnel. Nada más. Por eso puede estar activo siempre sin afectar a tu conexión.

Comprueba que funciona:

curl -x http://10.8.0.1:8888 https://ifconfig.me/ip

Debería devolver la IPv4 de tu servidor. En el servidor, wg show debería mostrar tu peer con un latest handshake reciente.

Paso 5. Envía solo Marketing Cloud por el servidor

En las versiones recientes de macOS, los ajustes de proxy que cambias desde Wi-Fi → Detalles pueden quedarse ligados solo a la red actual. Para que funcione en cualquier Wi-Fi, configúralo por interfaz desde el Terminal.

Primero, lista tus interfaces:

networksetup -listallnetworkservices

Después, aplica el archivo PAC a las que uses (Wi-Fi, tu adaptador Ethernet USB o Thunderbolt, iPhone USB...). No lo apliques al propio túnel de WireGuard ni a Thunderbolt Bridge.

for svc in "Wi-Fi" "USB 10/100/1000 LAN" "iPhone USB"; do
  sudo networksetup -setautoproxyurl "$svc" http://10.8.0.1:8080/mc.pac
  sudo networksetup -setautoproxystate "$svc" on
  echo "== $svc"; networksetup -getautoproxyurl "$svc"
done

Ajusta los nombres a los de tu lista. Cada una debería mostrar la URL del PAC y Enabled: Yes. Reinicia el navegador (Cmd+Q).

Los portales cautivos (Wi-Fi de hotel o aeropuerto con página de acceso) no son un problema: hasta que el túnel conecta, el archivo PAC no está accesible y el Mac navega directo. En cuanto el túnel está activo, Marketing Cloud pasa por el servidor.

Paso 6. Postman y scripts

Postman no usa archivos PAC. En la app de escritorio:

Settings → Proxy

  • Desactiva "Use the system proxy".
  • Activa "Use custom proxy configuration".
  • Proxy type: HTTP y HTTPS.
  • Proxy server: 10.8.0.1, puerto 8888 (no 8080, que es el del servidor del PAC).
  • Proxy bypass: localhost,127.0.0.1

Todo el tráfico de Postman irá por el servidor. No pasa nada: el volumen es mínimo.

Para tus propios scripts:

export HTTPS_PROXY=http://10.8.0.1:8888

Si usas Windows en lugar de un Mac

Yo lo monté en un Mac. Los pasos para Windows siguen exactamente la misma lógica, pero no los he ejecutado yo, así que avísame si en tu equipo algo es distinto. Los pasos 2, 3 y 8 (servidor y MCE) no cambian.

Paso 1 (clave SSH). Windows 10 y 11 incluyen OpenSSH. En PowerShell:

ssh-keygen -t ed25519 -C "you@yourdomain.com"
type $env:USERPROFILE\.ssh\id_ed25519.pub

Copia la línea que empieza por ssh-ed25519 y úsala en el paso 2. Para conectarte al servidor en el paso 3, usa ssh root@YOUR_SERVER_IP desde PowerShell.

Paso 4 (WireGuard).

  1. Descarga WireGuard para Windows desde la web oficial, wireguard.com.
  2. Pulsa la flecha junto a Add Tunnel y elige Add empty tunnel.
  3. Borra el contenido por defecto, pega el bloque entero del paso 3 ([Interface] y [Peer]), ponle nombre y guarda.
  4. Si ves la opción Block untunneled traffic (kill-switch), asegúrate de que está desmarcada. Si no, bloquearía todo lo que no pase por el túnel.
  5. Pulsa Activate. En Windows, el túnel funciona como servicio y sigue activo después de reiniciar.

Paso 5 (archivo PAC). Esta parte es más sencilla que en Mac, porque en Windows el ajuste se aplica a todas las redes a la vez:

  1. Ve a Configuración → Red e Internet → Proxy.
  2. En Usar script de configuración, actívalo.
  3. Dirección del script: http://10.8.0.1:8080/mc.pac
  4. Guarda.

Chrome y Edge usan este ajuste directamente. En Firefox, comprueba que en Ajustes → Configuración de red esté marcado Usar la configuración del proxy del sistema.

Paso 6 (Postman y scripts). Postman se configura exactamente igual. Para scripts en PowerShell:

$env:HTTPS_PROXY = "http://10.8.0.1:8888"

Comprobación. En PowerShell, usa curl.exe (con .exe, porque curl a secas puede ser un alias de otro comando):

curl.exe -x http://10.8.0.1:8888 https://ifconfig.me/ip

Debería devolver la IPv4 de tu servidor.

Paso 7. Comprueba que todo funciona

  1. Abre https://ifconfig.me en el navegador. Debería mostrar tu IP normal, no la del servidor.
  2. En el servidor, observa el proxy: journalctl -u tinyproxy -f
  3. Abre https://mc.exacttarget.com. Deberías ver líneas CONNECT hacia dominios de exacttarget.com y marketingcloudapps.com.
  4. En Postman, GET https://ifconfig.me/ip debería devolver la IP del servidor.

En MCE, la página de ajustes del allowlist también muestra tu IP actual. Debería ser la del servidor.

Paso 8. Añade la IP en cada cuenta de MCE

  • Añade la IPv4 de tu servidor al allowlist de cada cuenta, como rango de una sola IP (inicio y fin iguales).
  • No actives tú el modo bloqueo antes de tu fecha, y no aceptes a ciegas los rangos recomendados. Salesforce pide esperar a después de la fecha para cambiar la configuración.
  • El día de tu fecha, comprueba que tu IP sigue en la lista después de que Salesforce aplique su configuración, y revisa el Access Log para confirmar que tus accesos llegan desde la IP del servidor.
  • En las cuentas que gestiona otra persona, envía tu IP a su administrador con antelación.

Plan B: si algún día te quedas fuera

Desactiva el túnel en la app de WireGuard. Sin túnel, el archivo PAC no se carga y el navegador sale directo con tu IP normal. Si has entrado desde casa con frecuencia, esa IP probablemente esté en la lista inicial de Salesforce. Entra, vuelve a añadir la IP del servidor y activa de nuevo el túnel.

Además, pide a cada cliente que tenga un segundo administrador que entre desde una IP fija de oficina. Ser el único administrador es un riesgo, con o sin este cambio.

Notas de seguridad

  • El tráfico de Marketing Cloud ya va cifrado con HTTPS de extremo a extremo. El servidor solo reenvía tráfico cifrado: no puede leer tus datos y no guarda nada.
  • El riesgo real es que alguien tome el control del servidor, porque tus clientes confían en su IP. Por eso: SSH solo con clave, firewall cerrado salvo WireGuard y SSH, actualizaciones de seguridad automáticas, ningún otro servicio en el servidor y autenticación en dos pasos en la cuenta del proveedor.
  • Elige una ubicación en la UE y acepta el contrato de encargado del tratamiento de tu proveedor, para poder responder a las preguntas de tus clientes sobre el RGPD.

Lo que me falló (para que no te falle a ti)

  • Mi tráfico salía por IPv6. La primera prueba devolvió la IPv6 del servidor en lugar de la IPv4. La línea de gai.conf del paso 3 lo soluciona.
  • El archivo PAC devolvía un 404. Los archivos creados después de un umask 077 solo los podía leer root. Las líneas chmod del paso 3 lo solucionan.
  • El túnel se quedaba en "Reiniciando". Al editar el túnel, borré sin querer la sección [Peer]. Tienen que estar las dos secciones.
  • Postman devolvía "Unsupported method CONNECT". Había puesto el puerto 8080 (servidor del PAC) en lugar del 8888 (proxy).
  • Los ajustes de proxy solo se aplicaban a una Wi-Fi. Usa networksetup por interfaz, como en el paso 5.

Reflexión final

Sigo pensando que la seguridad de una plataforma no debería depender de la configuración de red de cada cliente, y que el allowlisting debería ser una opción más, no la única. Pero el bloqueo ya está aquí y, con un poco de preparación, no tiene por qué impedirte trabajar.

Si tu cuenta está en una de las primeras oleadas, no esperes al último día. Revisa tu lista de IPs ahora.

Pep Aguiló, arquitecto freelance de Salesforce Marketing Cloud, trabajando con Marketing Cloud desde 2013.

Precios y disponibilidad de proveedores a octubre de 2026. Este montaje es el que me funciona a mí; revísalo teniendo en cuenta los requisitos de seguridad de tus clientes.

← Volver al blog