Hacker News Reader

Comment by justinclift | Hacker News Reader

Unfortunately, the firewall offering that Hetzner provides for their dedicated servers is IPv4 only.

So, if you're using software on the server which mucks around with firewall rules (eg using OS provided firewall on the server isn't good enough), then you're sad out of luck.

And their current IPv4 firewall has a 10 rule limit per server, which can't be raised. Mind boggling. :(

I've asked Hetzner if they have any plans to extend their firewall to include IPv6 support, or raise the # of firewall rules, but they have no plans to at this stage. :( :( :(

View on HN

For this reason I've setup a OpnSense VM on my dedicated Hetzner server where all inbound and outbound IPv4/IPv6 traffic has to go through, it acts as a gateway for the host itself and my other VMs. OpnSense itself is a pretty powerful firewall with tons of other features.

Of course you'll lose access to your server if the OpnSense VM breaks or doesn't boot up for whatever reasons after an update or so, but after 2 years I haven't had any problems. But in case something goes wrong Hetzner offers some nice recovery options, even if you don't have internet access to you server you can access your volumes in some kind of VM and get access to it via a VNC like interface (I had to use this feature a few times during the initial setup which consisted of a lot of trial and error I locked myself out a few times).

I wouldn't run this setup for anything mission critical of course, it's way too hacky and an official firewall solution would be better, but for my personal purposes as a "home lab" like setup it works perfectly fine so far.

Seems like an edge case. 99% will be happy with the OS firewall.

There's also the option to spin up a tiny VM with pfSense/OPNsense and have it act as a bastion, is there not? Or would it introduce too much latency?

From my experience their cloud offerings are much slower network wise than the dedicated ones.

Until they learn that Docker adds iptable rules on their own and open every port automatically.

Every port on the machine, or every port on the container?

The container's ports that you explicitly expose.

E.g. `docker run -p 8080:80 nginx` will expose the container's port 80 as port 8080 on the host. That port will be open whether or not the host has a firewall configured to block 8080.

You can do `docker run -p 127.0.0.1:8080:80 nginx` to only have the port on the host accessible on the loopback interface (for example if you have a reverse proxy on the host, proxying to 127.0.0.1:8080).

I've been bitten by this, was a pain in the ass to figure out that something was messing with the iptables rules.

Not quite. It's easier to define one set of rules for the entire server group (Projects in Hetzner terminology) and forget about it than to manage OS firewalls individually.

To be clear, these weird firewall limitations are not related to cloud firewalls. Cloud limits are much more generous.

What software that anyone actually uses does this, except for docker (which has well documented ways of using it properly that are tragically not the default)?

> well documented ways of using it properly that are tragically not the default

Docker is the stand out case from my point of view, and the ways it breaks networking seems to randomly change from version to version without warning nor consistency.

What are the well documented ways of using it properly, that avoid this weird behaviour from Docker?

Exposing ports breaks every security model in your firewall, which is why you should expose ports explicitly to localhost and if you want to expose them to the outside world you use a routing application (e.g. haproxy). I think that is the most obvious one. The fact that it messes with your iptables rules in a way that is frankly not very transparent is something that cannot be fixed, except by not using docker :)

> Exposing ports breaks every security model in your firewall

Of course. That's why we do only bind them to localhost, and tend to use nginx to proxy from that to the outside world (for web apps anyway).

That being said, I've still seen Docker do dumb stuff with port mapping, and seen it change behaviour between "minor" version updates. Though that was a while (few years) ago now.

> ... except by not using docker

Kind of stuck with it for now, and having to work around it's crappiness. ;)

Reply on news.ycombinator.com