SSRF and private IP ranges

[openclaw1reaperhammer]

I have my private n8n server running on a private network (LXC on proxmox to be specific), it is served on https using a self-signed certificate
I want to connect to it using the n8n mcp server from another machine running claude code, on the same private network.
In this scenario I don't see a documented or recommended way to allow this connection to work and bypass the SSRF block?
Can I suggest an update to the https://github.com/czlonkowski/n8n-mcp/blob/main/docs/SELF_HOSTING.md guide is required to cover this scenario?

[openclaw1reaperhammer]

Well... I found the solution, and I feel like it was much harder than necessary due to the lack of documentation on when WEBHOOK_SECURITY_MODE=permissive should be used... as my system would not work with moderate mode.
and the complete lack of documentation on the use case of self-signed certs, and using NODE_TLS_REJECT_UNAUTHORIZED
I understand my issue is for what some may deem a 'non-production' environment, but that's where I do all my testing before putting this stuff into prod, and I don't even let AI touch prod... so I think it's a valid case to document this use case.

[czlonkowski]

Hi @openclaw1reaperhammer would you mind contributing PR to the documentation?

[czlonkowski]

Thanks for the detailed write-up @openclaw1reaperhammer, and glad you got it working.

I dug into the current code to confirm what's happening here:

• The SSRF gate (src/utils/ssrf-protection.ts) runs in three modes, controlled by WEBHOOK_SECURITY_MODE (default strict):
  • strict (default) — blocks localhost + RFC1918 private IPs + cloud metadata
  • moderate — allows localhost, still blocks RFC1918 private IPs + cloud metadata
  • permissive — allows localhost + RFC1918 private IPs, still blocks cloud metadata (169.254.169.254, GCP metadata.google.internal, etc.)
• So for a private-host n8n on something like 10.x / 192.168.x / 172.16–31.x, moderate isn't enough — permissive is the mode that's actually needed. That matches exactly what you found.

On the docs side, you're right: docs/SELF_HOSTING.md currently only documents moderate (for localhost / host.docker.internal) and doesn't cover the permissive use case for private-network instances, nor the self-signed-TLS / NODE_TLS_REJECT_UNAUTHORIZED=0 angle. I agree this is a legitimate non-prod testing scenario worth documenting.

This is an accepted docs task — I'd very much welcome the PR you offered. Keeping the issue open to track it. If you'd rather not write it up, no problem; leave a note here and we'll fold it into the self-hosting docs ourselves.

[w-marco]

To add to to this: I would appreciate a toggle for the WEBHOOK_SECURITY_MODE inside the UI when installing via the bundlet .mcpb package.
I used that for Claude Desktop out of convenience and had to edit manifest.json in the plugin directory to set the EnvVar.

[geraistec]

+1

[reaperhammer]

Thanks for the detailed write-up @openclaw1reaperhammer, and glad you got it working.

I dug into the current code to confirm what's happening here:

• The SSRF gate (src/utils/ssrf-protection.ts) runs in three modes, controlled by WEBHOOK_SECURITY_MODE (default strict):

  • strict (default) — blocks localhost + RFC1918 private IPs + cloud metadata
  • moderate — allows localhost, still blocks RFC1918 private IPs + cloud metadata
  • permissive — allows localhost + RFC1918 private IPs, still blocks cloud metadata (169.254.169.254, GCP metadata.google.internal, etc.)

• So for a private-host n8n on something like 10.x / 192.168.x / 172.16–31.x, moderate isn't enough — permissive is the mode that's actually needed. That matches exactly what you found.

On the docs side, you're right: docs/SELF_HOSTING.md currently only documents moderate (for localhost / host.docker.internal) and doesn't cover the permissive use case for private-network instances, nor the self-signed-TLS / NODE_TLS_REJECT_UNAUTHORIZED=0 angle. I agree this is a legitimate non-prod testing scenario worth documenting.

This is an accepted docs task — I'd very much welcome the PR you offered. Keeping the issue open to track it. If you'd rather not write it up, no problem; leave a note here and we'll fold it into the self-hosting docs ourselves.

I was coming to update the doco and was indeed wondering if you could answer this question first! I think there are several pages in this repo that mention moderate allows RFC1918, where you are saying that is not the case... I will try get around to a PR, but tbh I have stopped using this node -- I have moved away from n8n in general for a few reasons so less of a priority for me right now.

If not obvious that openclaw account is my account :)