> While it may seem appealing, I would highly recommend against installing loads of software right on the router, and instead forward traffic to a device in a DMZ or VLAN.

Why not? I use an old gaming PC as a "router" (machine exposed to the WAN), and run dozens of services on it besides the firewall/NAT (iptables). Among others: email, Web server, multiple game servers, and many internal services (DNS, hostapd, loads of Docker containers).

▲

zymhan an hour ago | parent | next [-]

As others stated, installing software can change the state of your firewall configuration, or start a service listening on 0.0.0.0:8080 for example.

▲

benlivengood 4 hours ago | parent | prev | next [-]

You need more careful firewall rules on any device with IP forwarding enabled, and it can be hard to remember exactly when forwarding, NATint, etc. happen with relation to the incoming/outgoing firewall rules.

E.g. is your pf-based load balancer running its rules before or after the global filtering rules? And if they're running first are they SNATing incoming traffic so the LAN rules allow the traffic through or does it need explicit exceptions for external IPs to traverse to a LAN endpoint?

If you're comfortable with more advanced networking then it's fine to run it all on one box. If you just want to open ports for internal LAN services then that is a very canned and well-supported feature for a gateway firewall.

E.g. see AirSnitch which resulted in large part from mixing too many complex networking rules in single devices.

▲

yabones 4 hours ago | parent | prev | next [-]

A classic example is Docker inserting its firewall rules before everything else, causing any "published" ports to be wide open even if a firewall ruleset was configured. They might have fixed this, or doubled down on their design choice. Either way, that kind of complexity can really bite you if you're not careful.

https://docs.docker.com/engine/network/#published-ports

	▲	drnick1 3 hours ago \| parent [-]
		Yes, this is a well-known pitfall. It's important not to bind containers to 0.0.0.0 for this reason, unless they are actually intended to be public.

▲

alias_neo 5 hours ago | parent | prev [-]

> Why not?

It seems like you weren't really asking, but I'll answer anyway.

It's bad security practice, and opens up your network to attack and/or compromise, you're massively increasing the attack surface, and a compromise of one of those components leaves the attacker sat on your edge router, at which point your entire network is fair game.

Generally speaking you shouldn't expose anything on your edge router / firewall, it's a safety barrier.

You can sit things behind it in a "DMZ" and port-forward and isolate them etc so that there's no packets terminating on the actual edge device itself.m, that lowers the risk of a full network level compromise.

Chances are you might be fine and never have a problem, but it's still recommended against.

	▲	drnick1 3 hours ago \| parent [-]
		It was a genuine question, and while you reiterate the author's point about this being "bad security practice," neither you nor the author explain why this is the case. I don't believe physical separation really buys you much here. At most, if may reduce downtime if you do indeed get pwned, but I think that you can achieve the same objective through a combination of containers, VMs, and UNIX users. And running multiple, somewhat redundant machines also has obvious downsides such as increased power consumption, increased maintenance burden, additional space and cabling, etc.