Continuing the discussion from Use one NIC and VLANs:
If I may,
(For those opposing and, meant respectfully, of course)
I think that opposing the router-on-a-stick approach make various assumptions. One key assumption is that IPFire will only be used as a firewall which limits the project’s exposure greatly. Case in point, five different platforms, only one directly connects public to private IP space:
Furthermore, alleging the possibility misconfiguration, improper/incapable hardware may be misconstrued as the assumption of an incompetent user, which, I think if they are going to the trouble of deploying a custom firewall it’s safe to say they are aware of the consequences and they feel competent enough to do so, so, there’s a chance for users to take offense on this.
There are several reasons why people might be interested in IPFire other than the firewall, personally I need filtering by ASN without needing to know the client’s DNS queries, I’m not sure if that’s available on IPFire, I never got to that point. Its filtering capabilities were never a concern of mine because I never intended to use it as a firewall. What caught my attention from it is that it’s a Linux system with a package manager which would make infinitely extendable and flexible—I thought.
And the reason I never got there is because you can’t install with only one physical interface, there’s no placeholders/dummy interfaces available, it seems. And even if they were, zones would be another problem, they’re too opinionated (and seem to accept not other opinions.)
Why does the LAN/green zone gets unrestricted outbound access automatically? Malware (or worse: software updates) behaves like MDM: it attacks from the inside—it phones home.
Access should be granted on a needed basis, per host groups, which coincidentally was the feature that I liked the most about IPFire.
I only allow traffic on TCP ports 80 and 443. That’s it. And that’s heavily filtered at layer 3 according to source and destination address. All network services are served within the network, NTP, DHCP, LDAP, SMTP, SNMP, etc, thus they are all blocked from crossing out—not by a rule but by default. Some, like NTP are natted back to local servers. DHCP is relayed, it doesn’t need a special type of network.
In other words, the way BLUE zones work (I’m still reading the docs though) which is why I can’t understand what’s the logic for it to be recommended for Wi-Fi? That makes no sense. Why would you segregate your wireless clients from the wired clients if all of them are your clients?
If you need segregation, you segregate by client system/use type, not by media access type, e.g; servers vs general users and media devices vs real-time applications. For starters, the separation of broadcast domain of wireless and wired clients breaks multicast, thus remote apps, AirPlay, Chromecast, etc now needs an expensive (in traffic) repeater or DNS-SD/Avahi. If you run VRRP you’ll have a storm in no time.
Segregating wired from wireless is as pointless as segregating IoT devices on their own network but not from the Internet. As if devices universally known to be setup creating their own network (i.e. ad-hoc) because they lack support for the Enterprise versions or WPA could not attack the same way once compromised.
In my network, for instance, no firewall is the main firewall, because traffic is routed loosely by type, internal subnets are handled by a switch and have filtering between them they’re segregated for QoS reasons mostly sometimes just to force the traffic into a gateway which then redirects the web part of it to a reverse-proxy to inject security headers to counter possible trackers in self-hosted web apps for example, another router connects different types of tunneled clients, another connects to the Internet which in turn connects to a remote gateway with the public IP addresses the traffic is actually sourced from and it’s all routed by OSPF; so what you call the link between the remote gateway and the local gateway, it’s technically both a WAN and a LAN and a few more VLANs, there’s no zone except maybe BLUE that fits best. But wireless clients are both on the same VLAN as wired clients and also on the same VLAN of other wireless networks both on the same AP and other APs. They’re chosen dynamically using RADIUS, VLANs themselves are created dynamically on switches using GVRP which is something available on the cheapest of my switches. This I think rules out BLUE the way it’s recommended.
One of my Hurricane Electric leases used a remote address but the firewall that has it already has another Hurricane Electric GIF of its own. Public IP addresses can’t have more than one GIF, so the traffic is forwarded all the way down, without NAT in IPv4. It might be over OpenVPN or GRE over yet another GIF because it’s OSPF—routes are dynamic—I wouldn’t even know what type of zone would that fit!
And we still haven’t gotten to offline publicly available servers and Active Directory + DNS routing.
I understand the arguments given for different interfaces, I do. They have all the merits given, that’s certainly not up for debate. But I think it IPFire would gain by loosening that restriction a little. It’s too inflexible.
Users should be taught to learn to deal with a default block firewall, like pfSense and OPNsense do. They do it pretty smart too, the first interface, the WAN has the firewall disabled, it’s enabled when the second interface is added, this doesn’t need to be physical or child of physical, it can be a tunnel. It will receive a set of rules to allow all traffic from that subnet per stack. After the third interface though, they don’t receive this rule anymore, but, again, users seeking more than a hot-cold config are expected to do some research and learn that traffic must be accepted explicitly and at these stages as well, it is recommended to removed the automatically generated accept all rules for more targeted rules. At least on pfSense, OPNsense is more laisser-faire with its documentation, to put it in a way.
From the firewalls I’ve used, VyOS resembles IPFire the closest; it’s based on Linux, it uses zones as well and has a defaults to accept when there are no rules, but the first thing that’s taught to the user on VyOS is to create a rule to change the filtering to default block and zones aren’t predefined behaviors but rather just groups of something.
Protecting so much the users from themselves if how we end up in those annoying certificate warnings and forced MFA.
Generally no, but… maybe you weren’t looking… 