This is a small addition to the previous guide I had created earlier.

The previous guide showed how you can add a iptables firewall that will work with your docker containers, while it may not seem complicated, and really it isn’t, it does take a little bit of reading and understanding for it to “click”, at least it did for me.

What this modification will do is modify your iptables rules to allow a dynamic IP to only be allowed access to your secure services. This may not be ideal for everyone, but for me it works great, since I can set it to my home IP address. This means I can only connect via SSH and the docker service via Portainer.

You may say, how do you connect if you are not at home? Well I just VPN to my home connection and then connect to my secure services.

Also if your looking for a way to securely connect to your docker service remotely, check out this awesome guide.

The Problem #

This is by far one of the biggest issues I have had trying to scour the internet looking for a good way to deal with Docker and my hosts firewall. I have spent DAYS souring the internet trying to find someone who has solved this problem, because I know they have solved this problem. If there is one rule I have always lived by with the internet age, if you have come across a problem, it is almost guaranteed someone else had the same problem and came up with a solution.

I have tried using UFW, after all it is called Uncomplicated Fire Wall, you would think it would be uncomplicated. But while the solution I found for my firewall worked on some of my hosts, it didn’t work on all of them. For interest, this was the solution I came across for UFW.

chaifeng/ufw-docker

To fix the Docker and UFW security flaw without disabling iptables - chaifeng/ufw-docker

chaifeng GitHub

Why didn’t the above solution work for me? Well it did work, there was just 1 massive flaw. When I enabled UFW, I was getting timeouts and extremely slow page loads with my Nginx webserver. I tried scouring the web looking for a reason as to why this was happening, and sadly no one had this problem before, or at least it was such an uncommon problem the answer is buried somewhere on the internet. I did say “almost guaranteed” someone else had the same problem.

I like to tinker with new scripts/programs, and I also like to figure out how to do things properly, or at least as proper as can be through reading the manuals and browsing forums/guides.

So this is one thing I had to figure out in order to allow my servers to send e-mail that wouldn’t get bounced back through the various providers, and my goal was to accomplish this, without using SMTP authentication to my Mailcow server in order to send e-mail.

For example, this is how you would configure postfix to relay e-mail to G-Mail.

3 easy steps to configure gmail smtp relay with postfix | GoLinuxCloud

Step by step tutorial to configure postfix using third party gmail smtp relay to send mails to external network. Use SASL with Google 2-Step Authentication

John GoLinuxCloud

I would do a similar type of setup for my Mailcow server, instead of sending/authenticating with G-Mail, I would send my mail directly to my mail server and authenticate that way. While this solution would work for me, I just didn’t like the way it was handled.

This guide is how I accomplished my goal of sending e-mail through my various servers, to relay safely to my Mailcow server. I take no credit for the majority of what is listed here, I merely collected information from various other sites/guides, I will do my best to link to the original guides I used to ensure they get credit.

This guide assumes you have a fully working Mailcow server, with all configurations and DNS completed. It also assumes you are running at least Debian 11. I am running Debian 11 on all my servers, again the commands for other versions of Linux variants are likely similar, but packages/paths are going to be different.