Step by Step Guide to solve n8n webhook blocked by firewall
Who this is for: This guide is for DevOps engineers, SREs, and n8n administrators who need to expose n8n webhook endpoints through firewalls, security groups, or WAFs. We cover this in detail in the n8n Webhook Errors.
Quick Diagnosis
- Identify the firewall (cloud security group, on‑premise firewall, or WAF).
- Allow inbound traffic from n8n’s public IP ranges (or your own IP if self‑hosted) on port 443 (HTTPS) and 80 (HTTP).
- Whitelist the webhook URL in any WAF rule sets (e.g., AWS WAF, Cloudflare).
- Test with
curl -I https://your‑n8n‑instance.com/webhook/your‑workflow-id. - Verify in n8n → Workflow → Executions that the request is received.
Result: The webhook executes instantly, no “blocked by firewall” error in the n8n UI.
1. Why firewalls block n8n webhooks
If you encounter any timeout and rate limit resolve them before continuing with the setup.
| Symptom | Typical root cause | Origin |
|---|---|---|
| “Request failed – network error” in n8n UI | Inbound port 80/443 blocked | Network security group (AWS, GCP, Azure) |
| “Connection timed out” in execution log | Egress rules deny outbound traffic | Self‑hosted VM firewall (iptables, ufw) |
| “403 – Forbidden” from WAF | WAF flags request as malicious | Cloudflare, AWS WAF, Azure Front Door |
EEFA note: Opening ports to the public internet widens the attack surface. Restrict inbound rules to the minimum required CIDR blocks (e.g., n8n’s static IPs or your trusted range) and always use TLS.
2. Locate the firewall that governs your n8n endpoint
If you encounter any retry mechanism failure resolve them before continuing with the setup.
Identify where the rule set lives before you start editing.
| Environment | Typical firewall location | How to view |
|---|---|---|
| AWS EC2 / ECS | Security Group on the instance or load balancer | AWS Console → EC2 → Security Groups |
| Google Cloud Compute | VPC firewall rule | GCP Console → VPC network → Firewall |
| Azure VM / App Service | Network Security Group (NSG) or App Service access restrictions | Azure Portal → NSG or App Service → Networking |
| On‑premise / Docker | Host OS firewall (iptables, ufw) or Docker network policies | sudo iptables -L or ufw status |
| WAF / CDN | Cloudflare, AWS WAF, Azure Front Door | Provider console → Firewall rules / WAF policies |
Tip: If you’re using managed n8n cloud (n8n.io), the firewall is managed by n8n. In that case, the block usually comes from an external corporate firewall or a proxy on the client side.
3. Permit inbound traffic for the webhook
3.1. Open ports 80 & 443 (HTTPS) for the webhook URL
AWS Security Group – allow HTTPS (port 443)
aws ec2 authorize-security-group-ingress \
--group-id sg-0a1b2c3d4e5f6g7h \
--protocol tcp \
--port 443 \
--cidr 203.0.113.0/24 # trusted IP range
AWS Security Group – allow HTTP (port 80)
aws ec2 authorize-security-group-ingress \
--group-id sg-0a1b2c3d4e5f6g7h \
--protocol tcp \
--port 80 \
--cidr 203.0.113.0/24
Ubuntu ufw – allow HTTPS
sudo ufw allow from 203.0.113.0/24 to any port 443 proto tcp
Ubuntu ufw – allow HTTP
sudo ufw allow from 203.0.113.0/24 to any port 80 proto tcp sudo ufw reload
3.2. Whitelist the exact webhook path (optional but recommended)
| Provider | Rule type | Sample rule |
|---|---|---|
| Cloudflare | URL‑Path firewall rule | http.request.uri.path contains "/webhook/" → Allow |
| AWS WAF | String match condition | Field to match: URI Path → Contains: /webhook/ → Allow |
| Azure Front Door | Custom WAF rule | Match variable: RequestUri → Contains "/webhook/" → Allow |
EEFA warning: Do not use a wildcard (/*) in the allow rule; limit it to /webhook/ to prevent abuse.
4. Verify connectivity from the source that triggers the webhook
Run a quick HEAD request to confirm the endpoint is reachable.
curl -I -L https://my-n8n.example.com/webhook/1234abcd
Expected outcome – HTTP 200 or 302 status, with a server header such as nginx/1.24.0. If you see Connection timed out or 403 Forbidden, revisit steps 1‑3.
5. n8n‑specific diagnostics
- Open the workflow → Trigger node → Webhook URL.
- In the Executions tab, click the latest execution.
- Look for “Error: Request failed – network error”.
If the error persists after firewall changes, enable debug logging:
# Add to your .env (or Docker env file) N8N_LOG_LEVEL=debug
Restart the n8n service and inspect the logs for ERR_HTTP_HEADERS_SENT or ECONNREFUSED.
6. Checklist – firewall ready for n8n webhooks
- [ ] Inbound TCP 443 allowed from trusted CIDR(s).
- [ ] Inbound TCP 80 allowed if you serve non‑TLS webhooks.
- [ ] Outbound rules on the client side permit traffic to your n8n host.
- [ ] WAF / CDN rules explicitly allow
/webhook/paths. - [ ] TLS certificate is valid (no expired or self‑signed certs unless trusted).
- [ ] Health check (
curl -I) returns 200/302 within < 1 s. - [ ] n8n logs show “Webhook received” after the test request.
7. Common pitfalls & how to avoid them
| Pitfall | Why it happens | Fix |
|---|---|---|
Using 0.0.0.0/0 to open ports |
Over‑exposes the server | Restrict to the exact IP range of the webhook sender. |
| Forgetting to reload firewall after changes | Rules not applied | Run sudo ufw reload, aws ec2 describe-security-groups, or provider‑specific apply command. |
| Mis‑typed webhook path in WAF rule | Request still blocked | Double‑check the path string; include leading slash. |
| TLS termination at a load balancer but firewall only opens port 80 | HTTPS traffic never reaches n8n | Open **443** on both the load balancer **and** the backend instance. |
Proxy server strips Host header |
n8n cannot match the webhook URL | Ensure the proxy forwards the original Host header (proxy_set_header Host $host;). |
All commands assume you have appropriate permissions on the host or cloud console. Adjust CIDR blocks and resource IDs to match your environment.
