Secure DNS Configuration with Firewall in front of Mailcow

encrypt3d

Hi, I recently moved my mailcow instance to a new VPS so it runs independently from other services.

The new VPS is behind a firewall that I want to use to block spam traffic before it reaches the VPS.

I added all the required (TCP) rules for incoming traffic to the VPS. There is no outbound filtering rule, so outbound traffic is not filtered at all.
Example:
{firewall configuration?}

However, mailcow-unbound sends DNS queries over UDP to the internet, and because of UDP being stateless the firewall doesn’t know that it should allow those UDP packets back in and thus blocks them.

I see two possible solutions:

1) Which I currently use:
Allow incoming UDP traffic with source port 53 to the UDP ports used by Unbound (see https://docs.mailcow.email/getstarted/prerequisite-system/#important-for-hetzner-firewalls).

The downside of this being a lot of open ports, which I wanted to avoid as much as possible.

2) Use a local DNS resolver (for example the VPS provider’s resolver) and forward queries to it (see https://docs.mailcow.email/manual-guides/Unbound/u_e-unbound-fwd/).
Using method 2 with the override/forwarding method skips Unbound, so my understanding is that DNSSEC validation would no longer be performed by Unbound. Is that correct?

3) Using the Override config from 2 combined with a local DNS Resolver running on the Host machine doing the DNSSEC validation and using some other Protocol than UDP for upstream requests.

Which method is the most secure option in your opinion?

esackbauer

encrypt3d The downside of this being a lot of open ports, which I wanted to avoid as much as possible.

Mailcow and its docker iptable rules already block those ports which are not needed.

mlcwuser

encrypt3d However, mailcow-unbound sends DNS queries over UDP to the internet, and because of UDP being stateless the firewall doesn’t know that it should allow those UDP packets back in and thus blocks them.

😲

Sorry, but I’ve never heard a modern firewall doing that per default. What type of firewall is that?

Every stateful firewall I’m aware of, whether it’s based on iptables/nftables or pf, uses connection tracking. This means that if the firewall sees and tracks an outgoing connection, it will usually expect a corresponding response and automatically allow it back in. This also applies to UDP traffic, even though UDP itself is stateless.

encrypt3d

mlcwuser Interesting. I didn’t know something like that exists for UDP. I am talking about the Netcup (a German VPS provider) Firewall.

mlcwuser

I’m not an expert on how connection tracking works exactly, but I don’t think you need to allow port 53 inbound for Mailcow to work, and if you do, there’s probably another problem that needs to be addressed.

Have you asked Netcup why outbound DNS requests via UDP aren’t working? If it really is due to their firewall, there may be some timeout issues, i.e., the firewall closes the connection too quickly, or the response takes longer than the tracking in the firewall maintains its pseudo state for stateless connections, but even if that were the case, I would probably look for the problem somewhere else first.

I mean, it’s not only Mailcow that sends DNS requests via port 53/UDP; every operating system does that for literally every request sent out to the internet. For example, Linux distros when you update the package repositories. I’ve never heard of having to open port 53 inbound on a VPS provider’s firewall for that. ;-)

Long story short, I think the problem lies elsewhere and not in Netcunp’s firewall.

encrypt3d

mlcwuser Netcup states in their Firewall documentation that for UDP it is required to open the corresponding “answer” UDP ports. https://helpcenter.netcup.com/en/wiki/server/firewall

I will ask their support if I understood that correctly. For the host system I got DNS resolution working by defining their local DNS servers in my static IP configuration.

mlcwuser

Hmm, interesting.

I see two things here that differ in Mailcow from the host’s DNS:

Unbound is a recursive resolver that queries authoritative DNS servers directly, rather than forwarding queries to another resolver such as Netcup’s or a public one like Google, Cloudflare, or Quad9. Still, it seems strange to me that you would have to explicitly allow anything inbound on the firewall for this to work.

Netcup’s DNS resolvers are, of course, inside their network, i.e. ‘behind’ the firewall. This would explain why things using those work, which could indicate that their firewall does indeed not properly perform connection tracking for stateless protocols such as UDP, which I find quite strange in itself. 😉

But as I said, I’m no expert, but I’ve also never heard of this in relation to a VPS provider before, as well as with well-known SMB firewalls such as UniFi, OPNsense, pfSense or IP Tables/NFtables on Linux. I mean heck, even with NAT in cheap home routers UDP connections just work ;-)

encrypt3d

mlcwuser

I found this thread on their forum, confirming the theory that their firewall does not do any UDP connection tracking (for whatever reasons). Germany likes doing things differently I guess.

https://forum.netcup.de/administration-of-a-server-vserver/vserver-server-kvm-server/21371-netcup-firewall-configuration/

So I guess I’ll leave it as it is right now with those ports open and maybe fiddle around with replacing the entire VPS’s dns resolution with dnscrypt-proxy or something similar. Thanks for your help!

encrypt3d

I found another useful thread:
https://community.mailcow.email/d/1446-auflosung-der-domains-uber-unbound-nicht-moglich

Where adding tcp-upstream: yes to (mailcow)-unbound’s config was suggested, which seems to be what is needed here. Since it forces all upstream requests trough TCP, which is being connection tracked by the Netcup Firewall.
I will try if this causes any unexpected side-effects.

https://unbound.docs.nlnetlabs.nl/en/latest/manpages/unbound.conf.html#unbound-conf-tcp-upstream