The Problem

In that article, nearly at the very end, I was pointing out that a solution was needed for the XMPP traffic on non-Web ports (TCP and UDP other than 80 and 443) to be routed from a cloud VPS to my home server.

I tried some NGINX configuration using its module streams, but it didn’t work, so I will post here how I ended up solving that using Linux’ –the kernel itself– packet filter rules through iptables.

I learned and adapted my solution from the content of this article by Ryan Welch.

At the end of the post, though, I will also post how to configure NGINX to work with TCP and UDP general traffic, just in case we need it later, or maybe you want to try it and tell me what I did wrong.

Solution

As explained before, Linux (NOT GNU/Linux, but just “Linux”, the kernel) has network packet filtering capabilities built-in that can be configured to our needs.

To configure the VPS to do it, SSH into the machine and enable IP forwarding in the kernel:

sudo sysctl -w net.ipv4.ip_forward=1

This may or may not be persitent between boots, depending on your distribution. To be sure, uncomment the line net.ipv4.ip_forward=1 in /etc/sysctl.conf.

Then, you will be able to redirect ports and ranges with sentences like the following:

iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5222 -j DNAT --to-destination <Upstream VPN IP>:5222
iptables -A POSTROUTING -t nat -p tcp -d <Upstream VPN IP> --dport 5222 -j MASQUERADE

And, for ranges of ports:

iptables -A PREROUTING -t nat -p udp -i eth0 -m multiport --dports 49152:65535 -j DNAT --to-destination <Upstream VPN IP>:49152-65535
iptables -A POSTROUTING -t nat -p udp -d <Upstream VPN IP> -m multiport --dports 49152:65535 -j MASQUERADE

You’ll have to change the ports in this example, as well as putting your own remote IP address instead of the <Upstream VPN IP> placeholder.

Add all the forwarding rules corresponding to all the XMPP server ports, where <Upstream VPN IP> would be the Tailscale IP of my home server, the one we were calling potato in the previous article of the series):

iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5222 -j DNAT --to-destination <Upstream VPN IP>:5222
iptables -A POSTROUTING -t nat -p tcp -d <Upstream VPN IP> --dport 5222 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5269 -j DNAT --to-destination <Upstream VPN IP>:5269
iptables -A POSTROUTING -t nat -p tcp -d <Upstream VPN IP> --dport 5269 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5000 -j DNAT --to-destination <Upstream VPN IP>:5000
iptables -A POSTROUTING -t nat -p tcp -d <Upstream VPN IP> --dport 5000 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 3478 -j DNAT --to-destination <Upstream VPN IP>:3478
iptables -A POSTROUTING -t nat -p tcp -d <Upstream VPN IP> --dport 3478 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 3479 -j DNAT --to-destination <Upstream VPN IP>:3479
iptables -A POSTROUTING -t nat -p tcp -d <Upstream VPN IP> --dport 3479 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 --dport 3478 -j DNAT --to-destination <Upstream VPN IP>:3478
iptables -A POSTROUTING -t nat -p udp -d <Upstream VPN IP> --dport 3478 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 --dport 3479 -j DNAT --to-destination <Upstream VPN IP>:3479
iptables -A POSTROUTING -t nat -p udp -d <Upstream VPN IP> --dport 3479 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5349 -j DNAT --to-destination <Upstream VPN IP>:5349
iptables -A POSTROUTING -t nat -p tcp -d <Upstream VPN IP> --dport 5349 -j MASQUERADE
iptables -A PREROUTING -t nat -p tcp -i eth0 --dport 5350 -j DNAT --to-destination <Upstream VPN IP>:5350
iptables -A POSTROUTING -t nat -p tcp -d <Upstream VPN IP> --dport 5350 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 --dport 5349 -j DNAT --to-destination <Upstream VPN IP>:5349
iptables -A POSTROUTING -t nat -p udp -d <Upstream VPN IP> --dport 5349 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 --dport 5350 -j DNAT --to-destination <Upstream VPN IP>:5350
iptables -A POSTROUTING -t nat -p udp -d <Upstream VPN IP> --dport 5350 -j MASQUERADE
iptables -A PREROUTING -t nat -p udp -i eth0 -m multiport --dports 49152:65535 -j DNAT --to-destination <Upstream VPN IP>:49152-65535
iptables -A POSTROUTING -t nat -p udp -d <Upstream VPN IP> -m multiport --dports 49152:65535 -j MASQUERADE

Test the set up, and when everything works, save the iptables rules by sudo iptables-save > /etc/iptables/rules.v4 so that these rules are applied at every boot of the VPS.

In his article, Ryan adds more considerations for things like congestion control and such. Check it out to know more and apply whatever suits your needs.

Bonus: NGINX With Generic TCP/UDP Traffic

Take this with a pinch of salt: as I stated at the beginning of the post, this didn’t work for me and my XMPP server of choice, Snikket. However, according to NGINX’ documentation, this is the way it is configured for handling non-Web traffic.

Install libnginx-mod-stream to support UDP and TCP reverse proxies.

Modify /etc/nginx/nginx.conf to add a stream block:

stream {
        include /etc/nginx/streams-enabled/*;
}

Then, create the directories following the existing schema NGINX has for webs: sudo mkdir -p /etc/nginx/streams-available /etc/nginx/streams-enabled

Create an /etc/nginx/streams-available/tcpudpservice.example.com.conf with rules like the following:

# TCP Port (non-HTTP traffic):
server {
        listen 5222;
        proxy_pass <Upstream VPN IP>:5222;
}

# ...

# UDP Port:
server {
        listen 3478 udp;
        proxy_pass <Upstream VPN IP>:3478;
}

# ...

# Ranges are accepted, too. In this case, note the
# use of $server_port in the proxy_pass sentence.

server {
        listen 49152-65535 udp;
        proxy_pass <Upstream VPN IP>:$server_port;
}

In the case of defining very large range of ports, such as the ranges that Snikket proposes for XMPP audio and video services in multi-users configurations, NGINX will throw an error due to having too many files open. Snikket expects to be able to establish 16384 UDP connections.

If you want to solve this instead of reducing the range of UDP ports, we must increase the LimitNOFILE parameter of NGINX in systemd by doing sudo systemctl edit nginx.service. This will open an editor for a drop-in extension to the service unit.

Write the following and save the file:

[Service]
LimitNOFILE=65535

Then, in the preamble of the /etc/nginx/nginx.conf (outside of any http, events or stream), add a line worker_rlimit_nofile with a value less than 65535 (30000 will work for the Snikket case), and increase the worker_connections inside events:

...
include /etc/nginx/modules-enabled/*.conf;

worker_rlimit_nofile 30000;

events {
        # worker_connections 768;
        # 3 times 8192 will suffice   
        worker_connections 24576;
        # multi_accept on;
}

...

As I said before, this configuration did not work with XMPP, but it can be useful for other use cases.

This text shows the steps to follow to connect an NGINX reverse proxy installed on a server A, and provide access through it to services hosted in a different machine, B. If the machines are in different locations or networks, we can solve the connectivity in several ways, one of them being a VPN.

In my personal case, this allows me to install NGINX on a VPS and use it to expose services hosted at my home server, “barcas”. To connect the two machines and allow NGINX to reach the upstream services, I have used Tailscale.

This post continues the series that started with “Changes to My Network, Sponsored by XMPP”. If you’re wondering why would we do that, or what value brings this configuration, please check read that one first.

Solution

You’ll need the following:

1. A VPS server rented from your provider of choice, to which you can access through SSH.
2. A server at your home, with at least one service accepting HTTP connections, let’s say, through the port 5000. (0.0.0.0:5000). I will call this host potato in the remainder of this post, just for the sake of brevity and readability.
3. A free Tailscale account. In general, we could do this with any VPN provider and even one self-hosted by us, preferably providing service based on WireGuard, as it is more performant than OpenVPN.
4. Optionally, or probably for this post to be meaningful, we should have a domain with their DNS records pointing to the VPS of point #1.

For the rest of the article I will assume that the hosts (the VPS and potato) have installed an Ubuntu LTS Server, such as 24.04.

If there were no issues you should have all this up and running in about 20 minutes.

Home Server

We’ll log into (the) potato, where our service is waiting for requests behind port 5000.

Install Tailscale and authenticate potato against our account. This will give potato an IP address within the VPN:

# Tailscale install commands are not reproduced, as they can 
# change at any point in time.

sudo tailscale up
# Follow the instructions

# Enable Tailscale as a system service, permanently running
sudo systemctl enable tailscaled --now

# Obtain and write down the IP address at the tailnet.
tailscale ip -4
100.85.67.22

At Tailscale’s dashboard we can see the host’s local name, and also the IP address returned by the last command.

We can also configure the host so that we don’t have to re-authenticate it into the VPN, disabling the expiry of the key used to authenticate the machine to Tailscale.

Optionally, we can also enable “MagicDNS” to be able to refer to the hosts by a domain name instead of by an IP address, with no local configuration to do in the machines.

Once the machine is already in Tailscale, we must open port 5000 in the potato’s firewall, if we hadn’t done so yet, so that it can receive requests from the VPS through that port.

sudo iptables -A INPUT -p tcp -m tcp --dport 5000 -j ACCEPT

Regarding this:

1. If your machine doesn’t have iptables-persistent installed, this is a good moment to install it so that we can save the firewall rules to be applied automatically at boot time.

sudo apt install iptables-persistent 
sudo iptables-save > /etc/iptables/rules.v4

2. I personally open the ports in all the network interfaces, not only in Tailscale’s.
   • As I won’t have that port open in the router, I am not doing anything that would leave me overly exposed.
   • This way I don’t need to always use Tailscale to perform tests on potato from home.
   • Each case is different: you should decide what to do with your firewall depending on how critical the service you’re configuring is, and how sensitive the data it manages is.

VPS

Connect to the VPS through SSH and install a reverse proxy. Even if we’re not going to have more than one web (80, 443) service listening, configuring, understanding and managing an HTTP reverse proxy is way easier than handle IP redirects and their relevant firewall DNAT rules.

I use NGINX.

sudo apt update && sudo apt install nginx

Install Tailscale and follow all the steps we did with potato. Write down the VPS’ IP address in “the tailnet”, for example 100.85.77.36.

Get a Let’s Encrypt certificate your your domain, with CertBot. For this:

• We must have already configured the DNS records of our domain, example.com, to point to the public IP of the VPS (not its IP at Tailscale) we’re working on.
• We may have to stop NGINX (sudo systemctl stop nginx) before, depending on our domain provider and their CertBot plugins available, if any.

sudo certbot certonly --standalone -d example.com
...
...
Successfully received certificate.
Certificate saved at: /etc/letsencrypt/live/example.com/fullchain.pem;
Key is saved at:      /etc/letsencrypt/live/example.com/privkey.pem;
...
...

Configure now the service in the reverse proxy, writing the IP of potato in Tailscale in the proxy_pass directive. For this, we’ll create a configuration file under /etc/nginx/sites-available/, for example example.com.conf for an https://example.com website.

upstream exampleweb {
        # Replace [IP or host name] for your 'potato' value
        # **in Tailscale**.
        # 100.85.67.22 in the post's example.
        server [IP or host name]:5000;
        keepalive 64;
}

server {
        server_name example.com;
        listen 80;

        location / {
                return 301 https://$host$request_uri;
        }
}

server {
        server_name example.com;
        listen 443 ssl http2;

        # Other SSL stuff goes here
        ssl_protocols TLSv1.2 TLSv1.3;
        ssl_ciphers HIGH:!MEDIUM:!LOW:!aNULL:!NULL:!SHA;
        ssl_prefer_server_ciphers on;
        ssl_session_cache shared:SSL:10m;
        ssl_session_tickets off;

        ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

        location / {
                # The final `/` is important.
                proxy_pass http://exampleweb/;
                add_header X-Frame-Options SAMEORIGIN;
                add_header X-XSS-Protection "1; mode=block";
                proxy_redirect off;
                proxy_buffering off;
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header X-Forwarded-Port $server_port;
                proxy_read_timeout 90;
        }
}

We’ll create now a symbolic link to this file under /etc/nginx/sites-enabled, test NGINX’ configuration and, if all goes well, reload it.

cd /etc/nginx/sites-enabled/
sudo ln -s ../sites-available/example.com.conf
sudo nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
# If we had to stop NGINX to get the certificate, we start it up; 
# otherwise:
sudo systemctl reload nginx

At this point we should be able to interact with our service at potato through https://example.com.

Troubleshooting

• This thing doesn’t render anything, the service seems to be not replying. If there is activity in NGINX’ logs in the VPS (sudo tail -f /var/log/nginx/access.log), and the request is abandoned after a time out, there are a few possible causes for this in my limited experience. At potato:
  • The service upstream we want to access from NGINX is not working, and we have to start it up.
  • the service upstream is exposed through port 5000 of a specific network interface, instead of 0.0.0.0 (which means all network interfaces of potato), and other than Tailscale’s; for example, 127.0.0.1,
  • or we did something wrong in the firewall and the request is being rejected in that way.
• NGINX’ settings are OK (sudo nginx -t says 👍), but NGINX doesn’t start or dies when you reload the configuration. The most frequent cause is that NGINX can’t reach or find the upstream at potato, the one pointed by the proxy_pass directive.
  • We may have a typo in the proxy_pass,
  • NGINX may have tried to reach potato before Tailscale’s tunnel was up, for example if this happens upon a VPS reboot,
  • maybe Tailscale is down in any of the two hosts.
  • This cause can be checked by looking for a host not found in upstream in the output of sudo systemctl status nginx:

nginx.service - A high performance web server and a reverse proxy server
     Loaded: loaded (/usr/lib/systemd/system/nginx.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/nginx.service.d
             └─override.conf
     Active: active (running) since Fri 2025-08-29 11:05:51 UTC; 3 days ago
       Docs: man:nginx(8)
    Process: 1154 ExecStartPre=/usr/sbin/nginx -t -q -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 1156 ExecStart=/usr/sbin/nginx -g daemon on; master_process on; (code=exited, status=0/SUCCESS)
    Process: 58676 ExecReload=/usr/sbin/nginx -g daemon on; master_process on; -s reload (code=exited, status=1/FAILURE)
   Main PID: 1157 (nginx)
      Tasks: 3 (limit: 1110)
     Memory: 46.9M (peak: 200.2M)
        CPU: 29min 57.349s
     CGroup: /system.slice/nginx.service
             ├─1157 "nginx: master process /usr/sbin/nginx -g daemon on; master_process on;"
             ├─1158 "nginx: worker process"
             └─1159 "nginx: cache manager process"

...
Sep 02 05:32:49 vps-hostingprovider nginx[58676]: 2025/09/02 05:32:49 [emerg] 58676#58676: host not found in upstream "100.85.77.22" in /etc/nginx/sites-enabled/example.com.conf>
Sep 02 05:32:49 vps-hostingprovider systemd[1]: nginx.service: Control process exited, code=exited, status=1/FAILURE
Sep 02 05:32:49 vps-hostingprovider systemd[1]: Reload failed for nginx.service - A high performance web server and a reverse proxy server.
lines 1-28/28 (END)

• We get an HTTP Status Code 502. This means that, while NGINX is doing well, the upstream service we’re trying to reach at potato’s port 500 is throwing errors.
  • If you go and do a test from the potato and goes well, almost for sure this is a matter of trusted proxies. To describe the problem in depth and correctly is outside of the scope of this post, but in summary the point is that you must tell your application that the VPS that is hosting the reverse proxy, a machine other than potato, is trustworthy. This is done by configuring VPS’ IP address in Tailscale as a trusted proxy. Check your specific web application logs to confirm this hypothesis.
  • This is not a problem, but a rather interesting security feature.
  • For example, this happened to me with both my Mastodon instance and Nextcloud. In both cases, each application’s documentation had the solution for it: Mastodon – trusted proxies, Nextcloud – trusted proxies
  • Depending on how the service we’re trying to fix is written, you may have to set a trusted proxy using an IP or you may be able to set a domain name, or either. Don’t desist if it doesn’t work at first try.

In this one, I’m going to tell you what those problems are, why they arise, why I want to solve them, and how I’ve solved them, but from a design point of view for now. You won’t find a set of commands to solve all this, but rather some context about what I’m trying to solve; detailed instructions will come in the future.

Until now, all my services hosted “underneath my printer” were Web services, that is, based on communications through ports 80 and 443 (HTTP and HTTPs). These ports were enough to connect all my services with my devices or my browser, or with other servers in the case of my Mastodon instance. To serve so many services behind the same ports, I use NGINX as a reverse proxy:

Unlike my other services, XMPP uses more TCP and UDP ports than 80 and 443: 5000, 5222, 5269, etc. In the case of Snikket, as many or all other alternatives might as well, ports 80 and 443 are also used to provide a web control panel and to manage users and chat rooms.

In principle, the easiest configuration for installing Snikket would be as follows:

• Configure ports 80 and 443 in NGINX to be able to use Snikket’s user and conversation control panel.
• Configure direct access to all other Snikket ports: 5222, 5269, etc. Here is the complete list. As they are not shared amongst other services, reverse-proxying them is not needed.
• Configure the DNS for my XMPP service with my domain provider, which is Cloudflare.

This configuration, which would look good at first glance, looks like the following:

However, there is a problem that is not obvious, and the above configuration does not work out of the box. The Cloudflare security features that are available to free accounts in the form of “the Cloudflare proxy” only support ports 80 and 443. With the Cloudflare proxy enabled, all non-web traffic (80 and 443) was discarded, so none of the ports involved in XMPP conversations reached my server.

Disabling the Cloudflare proxy for the Snikket subdomain configuration makes everything work, and looks like this:

Disabling Cloudflare’s proxy is not ideal because it exposes the server’s IP address to the rest of the internet. My server is at home, so a DDoS attack that, by pure chance, included the IP address assigned to me by my internet service provider would bring down my entire home network. That would prevent us from working or studying from home and would probably cause problems with my service provider.

An alternative to this is to hire a cheap server from any cloud hosting provider (a VPS) and move all my NGINX configuration to it, connecting this cloud server to my home server via a VPN (the free Tailscale account works very well and is more than enough).

• The cloud hosting provider would protect my server because the exposed IP would be theirs, not my home’s, and these types of companies protect their infrastructure from attacks, at least at the network level. Behind the XMPP ports there is no content, just a messaging service that also encrypts traffic, so there is no problem with losing the security and anti-bot layer that Cloudflare provides for these ports.
• Connecting the VPS to my server via a VPN is perfect for this case because it hides the IP address of my home network, saving me from having to configure it in the DNS control panel and also from having to open ports on my router. In addition, for all traffic between the VPS and my server, a layer of encryption would be applied to protect it in case it was not already encrypted.

Why move only the NGINX configuration and not all services? For reasons of resources and price: to run NGINX and a series of firewall rules, the requirements we need are minimal. A server with 1 GB of RAM and a CPU is more than enough, and that costs between 3 and 6€ per month. If I moved everything², I would need between 8 and 16 GB of RAM, much more storage, CPU power, a backup solution, etc. All of this would cost me around 40€ or more per month. Since I have a server at home where I can run the services, moving everything to the VPS would be an unnecessary expense in my case.

So, it seems that hiring a simple VPS to have NGINX configured there and connecting it to the home server via Tailscale would solve my problems at a very low cost (3 to 6€ per month).

The only additional complication with this method is that we need to have some mechanism to redirect traffic from the XMPP ports (several ports such as 5222, 5269, etc. on TCP and UDP) from the server we hire to our server (at home or wherever). In the end, I solved it by configuring the VPS to do IP forwarding and then setting up a series of DNAT³ rules on its firewall.

We will look at the configuration of all the elements in more detail in future posts.