Network configuration on production

Hi. Completely new to n8n and very impressed so far. We are testing it in order to move some integrations from other systems but I am quite stuck regarding being sure the network config we have is correct. We can’t get to connect to a few external services and unsure if this is related to not understanding the credential system or network issues:

This includes:

  • is the tunnel option required to open webhooks and other integrations?
  • if the tunnel is not a must, how do I deal with having the admin interface on one port (firewalled) and starting hooks or integrations on a public open one?
  • in case we put n8n in production which ports will be required to access it? Does this depend on the modules being integrated?

If there is any specific documentation I would be most grateful if someone can point me out. Thanks.

Welcome to the community @luison!

is the tunnel option required to open webhooks and other integrations?
Theoretically, a tunnel is never needed if you have n8n properly set up on a server. Only if you want to test (very important test!) n8n locally and you want to use Trigger-Nodes you need a tunnel to make your local n8n web accessible.

if the tunnel is not a must, how do I deal with having the admin interface on one port (firewalled) and starting hooks or integrations on a public open one?
That is currently not possible. Everything runs via the same port. If you need it separate you would have to set up a reverse proxy yourself. You can however simply use the built in basic-oauth to protect the web-interface separately: Introduction | Docs

in case we put n8n in production which ports will be required to access it? Does this depend on the modules being integrated?
That depends on how you configure n8n. By default does n8n use port 5678. But you can configure it to use whatever port you want. The server-setup guide here:

exposes n8n simply via the SSL port 443.

All n8n docs can be found here:

There are additionally some tutorials and blog posts here:

I hope that helps!

Hi @jan. Thanks for prompt reply.

I see then my issues are mainly coming then from understanding and configuring different credentials ;(

In order to improve the basic-oauth could I cap the workflow part of the URL “domain/workflow” in front reverse-proxy as being only part of admin purposes or can that also be used in workflows?

In this case it would be better to have a special rule to make only /webhook/' and '/webhook-test/ web accessible. Better to only expose specifically what you want to have exposed then blocking what you do not want to.

1 Like

Network design for a service is always a complicated beast. I’m working on a deep dive into different ways to put n8n into your network so that it works for you but that is a while off so I’ll give you the short version.

Network Overview
Throughout the post, I will be referring to the following network diagram:


The network is broken up into three different parts all separated by the Network Firewall:

  • Internal Network - These are all your internal servers, workstations, printers, etc.
  • DMZ - These are services that are partially open to the outside world and are accessible to everything one the internal network
  • External Network - This is everything else including everything on the internet and networks connected to the internet

Your specific network may be different from this setup. It could be simpler or significantly more complex but this gives us a good general overview of how networks are often set up.

n8n Accessing Services
n8n will generally be able to access most services inside the network with ease, especially if they are directly connected to the same Internal Network Switch as the n8n Server.

But, there can be some issues when a firewall is put up between n8n and the service that it is attempting to reach. The firewall can be:

  • A software firewall on the n8n server preventing requests from going out
  • A software firewall on the requesting service blocking requests from getting in or responses from getting out
  • A physical firewall in between the n8n server and the service server blocking access or responses
  • A virtual firewall in between the n8n server and the service server blocking access or responses

If there are issues accessing services, firewall settings should be one of the first things that you check.

The other thing that could be part of the issue is network VLANs. This is essentially making network gear such as switches look like they are on more than one network. So, if you do not have the two systems talking, check that they are on the same VLAN.

Now, if the services are on the internet or in the cloud, the same challenges are present. Make sure that there are not firewall rules preventing n8n from accessing the network and ensure that the firewall filters are not blocking the requests or their return.

Webhooks
Now, if you are setting up webhooks, things start to change a bit. Unlike API calls (which are initiated inside your network and usually have permission to leave the network to retrieve information), webhooks start outside the network which is generally blocked by default. In order for webhooks to work properly, you need to poke a hole in your external firewall and allow the request into your n8n server.

The simplest (and probably the most dangerous) is to build your n8n server right on the internet. That way, there is nothing stopping the webhooks request from coming in. There is also nothing stopping all the hackers, crackers and script kiddies from full on attacking your server!

The next option is to leave your n8n server inside your network and forward all requests from outside the network into the n8n server. This option is almost as bad as the previous option as it does little to stop hackers.

The third option is to only allow requests on a single port (e.g. 80, 443) to be port forwarded in to the n8n server. This only allows access on one port and any other services that are running on the n8n server (such as the management interface on 5678) are blocked. To add even more security to this configuration, you can also limit access to these single ports to specific IP addresses on the internet, reducing your risk of random people being able to access n8n. Locking down this option even further, you can do packet inspection of the systems connecting into n8n and reject requests based on the wrong packet type.

Now, to make this even more secure, build a proxy server using something like NGINX and put it in the DMS. You can then redirect all necessary ports to the proxy server which in turn direct the questions to n8n. You can also limit access for webhooks between the proxy server and the n8n server.

Remote Management
Now that you have this more secure setup in place, how will you be able to manage n8n remotely when everything is blocked? Your best bet is to set up a VPN link between the internal network and your remote management system. Once the user logs into the VPN tunnel, they will be able to manage and maintain the n8n server as if they were on site.

Parting Words
I hope this was useful to you and points you in the right direction. If you have any further questions, do not hesitate to ask!

4 Likes