(Sorry, Anya … after today, I’ll try to not post anything about computers for three days!) Linux restricts non-root users from opening ports <1024. It’s generally a good idea not to run your services as root. Which means, unfortunately, we end up running a lot of services on nonstandard ports (so frequently that 1389 and 1636 are a quasi-standard port for LDAP and LDAPS, 8080 and 8443 quasi-standard ports for HTTP and HTTPS). But having to remember to add the nonstandard port to a web URL is an annoyance for users — I’ve seen a lot of people fix this by adding a load balanced VIP or NGINX proxy in front of the service to handle port translations. But there is a quick and easy way to handle port translation without any additional equipment. Most Linux hosts have firewalld running, and you can tell the firewall to forward the port for you. In this example, I’m letting my Kibana users access my web service using https://kibana.example.com without needing to append the :5601:
firewall-cmd –permanent –zone=public –add-forward-port=port=443:proto=tcp:toport=5601
Should you decide against the port forwarding, the same command with –remove-forward-port deregisters the rule:
firewall-cmd –zone=public –remove-forward-port=port=443:proto=tcp:toport=5601
I like this approach because it keeps the application running without root privileges while still providing users with a standard HTTPS URL. It seems much simpler than introducing NGINX or another proxy for a basic port translation. Would you recommend firewalld forwarding for production environments, or only for simpler internal services?
This is a practical solution for keeping services on non-root ports while still giving users a cleaner URL. I especially like that it avoids adding another proxy layer just for simple port translation. I’m curious, though: are there any performance or security trade-offs when using firewalld forwarding this way?