[laurowyn]

If you want a web GUI, then pfSense or OPNSense are the general go tos.

However, if you're comfortable with CLI and modifying configs in /etc/ then just running a bare metal Alpine Linux box is perfectly doable on a tiny box. iptables/nftables for firewall/NAT, dnsmasq/bind9 for dns, dnsmasq/isc-dhcp for DHCP. I've got a handful of these boxes all interlinked via wireguard, sharing routes via BGP using bird.

Sure, you miss the config verification that VyOS provides, but does mean you learn the underlying tools themselves and that knowledge is portable to any other box running those systems.

Personally, I don't quite understand why VyOS is a standalone distro when it could just be a config generator/checker package. Could even support multiple different underlying tools so if you want to use dnsmasq over bind9, or vice versa, it can provide a unified config interface for them.

[nullify88]

isc-dhcp is EOL. I'd suggest using kea-dhcp from the same ISC. I believe there could be a script or some kind of migration path from isc-dhcp to Kea. I've been using Kea in production with no problems.

https://www.isc.org/blogs/isc-dhcp-eol/

[sofixa]

I really wish there was a better option for a Linux DHCP server. At my past job we were using isc-dhcp and it was absolutely horribly showing it's age (md5 api "keys", bespoke socket-based API "protocol", most things impossible to do via the "API", clustering that didn't really work, etc.). Kea is barely an improvement, with oddities such as being written in C++ and requiring recompiling for plugins, or an extremely weird API. It's obvious is still written by the same old folks who have no idea how software is supposed to work in the 2020s.

We need something modern - easy clustering, modern API, event stream, gRPC-based plugins, etc. (And yes, I have thought about developing it myself, it's on my pile of TODO)

[sp0ck]

One remark. Kea doesn't have some of functionalities provided by ISC-DHCP. If you use a lot of dhcp-eval and make decisions based on different dhcp options content kea is still a no-go since there is no workarround. Usually at ISP level dhcp is one puzzle of much more complicated system.

I tried if few times and every time I stuck on something and messagefrom developers was: this isc-dhcp feature is not supported. This was huge national scale ISP and bypassing those limitations means a lot of $ to adapt surrounding systems providing input to isc-dhcp LDAP DB in its own config style.

[numpad0]

> iptables/nftables for firewall/NAT, dnsmasq/bind9 for dns, dnsmasq/isc-dhcp for DHCP.

or `vbash` in VyOS for all of those :/

[laurowyn]

except vbash drives those tools by generating configs.

But this is my point; why is VyOS a distro when vbash could just be a package available to other distros?

[LeBit]

How do you do zone based firewalls with alpine?

[laurowyn]

define zone based?

If wanting internal and external subnets as "zones", iptables/nftables lets you match against incoming and outgoing interfaces. It would be trivial to make match against an incoming interface and jump to a zone specific chain. This is how I manage private subnets. fw-mark is also useful for setting routing rules. Can change which routing table is used by matching rules in iptables.

If wanting to do more stateful things, I'm not aware of any default package, but setting a rule to send packets to an NFQUEUE and implementing some custom logic on that nfqueue would be rather trivial too. I'm sure eBPFs are useable in there somewhere too, but I've very little experience with them.

Obviously iptables/nftables has its own issues, as seen in recent (and not so recent) posts about it being bypassable with raw sockets, but that tends to be host only and not when used as a gateway.

[LeBit]

> define zone based?

https://support.vyos.io/en/support/solutions/articles/103000...

You create a _zone_. You name it and assign some interfaces to it. For my needs, I only assign 1 interface per zone. Then, you specify with which other zone that zone can receive traffic from. That also comes with the identification of a firewall rulesets to apply to that pair.

So, `'Zone WAN (iface eth0) <- Zone LAN (iface eth1)' => apply fw LAN-TO-WAN`

When you do that, the firewall rules become much simpler to write and maintain.

But, a best practice is to assign every zone to every other zone. This soon becomes a combinatorial nightmare. When you want to add a zone, you have to create 2xN new zone configurations and 2xN new firewall rulesets.

[laurowyn]

So the equivalent of:

iptables -N eth0toeth1; iptables -P eth0toeth1 DROP; iptables -A FORWARD -i eth0 -o eth1 -j eth0toeth1; iptables -A eth0toeth1 -m tcp -p 80 -j ACCEPT; # add any more rules

Or, as you say to avoid exponential combinations, just make a chain for each zone (interface) and explicitly allow specific protocols/ports to target interfaces. Zones with multiple interfaces are just multiple rules to jump to the same zone chain.

[lmz]

You can check awall: https://git.alpinelinux.org/awall/about/ for an abstraction over iptables

[LeBit]

This looks interesting, but nowhere near VyOS abilities and documentation.

I can't even find anything related to policy-based routing (PBR).