Hello,
I understand that the Orange network was designed to be a DMZ network. Unfortunately I have no use for a DMZ but I do need an IoT network which is separate from Blue and Green.
As I have an additional DNS server, I have moved a few devices on to my Orange network today, but I really need DHCP there and I don’t want to run another DHCP on another device and set up DHCP relay.
So, I was hoping that IPFire might add a feature which would allow the option to change the Orange network from a DMZ to a 3rd network. This means it would have it’s own:
DHCP zone
access to DNS
access to the proxy
Could you please consider this?
I propose it as it would be less work than supporting a 4th network type (although that would also resolve my problem) which a number of people have requested.
While IPFire is flexible and can be customised this makes it complex to rebuild as a user can’t simply restore an IPFire backup to recover an installation.
Actually… DNS and proxy access can be obtained with simple firewall rules…
And for your goal, you can have two blue adapters (with different subnets!), with specific rules for one and not for the other.
Thank you, but I’ve proposed this as I recently learned the hard way that while it’s easy to customise IPFire, doing so makes it very difficult to simply reinstall and restore a backup (I have a KVM VM on a separate partition and other changes to IPFire).
I really want a separate DHCP scope, for Orange, but if IPFire catered for using Orange as either a DMZ or a third network, it would allow for the flexibility a number of people have asked for without the developers needing to cater for another whole network type.
@dnl For submitting a feature request to IPFire, you probably should open a bug report labeled as a feature request directly to the development team. If the team decides against implementation, they will close it with a “won’t fix” status. Otherwise, they may acknowledge it with a low priority, adding it to their “to-do” list for future consideration.
Create firewall rules IMVHO is not actually customize, rather than… configuration for suit network layour needs.
Also, having 2 blue interfaces with related rules i thing might not be defined “unsupported scenario”…
However I feel you, @dnl: it’s not WebGUI-ready to automate backups or procedures for disaster recovery.
I think the IPFire 3.0 supposed to have VLAN tagging. so that might solve your request.
It would make sense if DMZ had it’s own DNS.
but then I discovered Pihole DNS/DHCP. which is pretty easy to setup. and gives you more flexibility with pesky IoT devices.
@dnl What DNS server are you running for your Orange DMZ?
I actually already use a Pi-hole as my primary internal DNS server for all internal networks, but only for DNS (and NTP). I’d prefer to keep IPFire as my central DHCP server at this stage.
PS: The VM I mentioned that I’m running on my IPFire system, is a small Debian VM running Pi-Hole and chronyd as IPFire lacks the features they provide.
No response to my request in Bugzilla, not even an indication that it’s been read yet. Oh well, perhaps I should find the time to investigate creating custom a DHCP scope and the required firewall rules.
I suspect the developers are busy with other things.
There is also not a lot of traffic on the developers email list.
I suspect they are busy with their day jobs to ensure they can continue eating and living somewhere and that currently that is consuming a lot of their time.
Also bear in mind that improvement suggestions will have a lower priority to be dealt with than functional bugs in the bugzilla.
There was an improvement suggestion about being able to disable logging of drop hostile traffic. That was raised in bugzilla in Nov 2022.
I was able to start working on it in Dec 2023 and it is now in Core Update 184 Testing.
There are currently 459 open bug reports in the IPFire bugzilla.
Looking at your improvement suggestion my thought would be that it will not be accepted.
Making orange act as a third network instead of a DMZ effectively means creating a new network zone as the existing DMZ capability has to continue working for all the users who already use its capability.
Backwards compatibility has to be maintained and trying to make an existing zone act as both a DMZ and an additional zone without impacting the security capability expected from a DMZ would make things very complicated.
Trying to add an additional network zone into IPFire-2.x is a lot more difficult than people think due to its historic construction.
That is why IPFire-3.x is being worked on to provide, amongst other things, the capability for multiple zones as desired.
However IPFire-3.x also takes resource and the limited voluntary resource can only be divided so far between the various requirements of IPFire-2.x, IPFire-3.x, Infrastructure, forum, etc, etc
As with any improvement suggestion or bug report in IPFire any forum member can decide to pick up the bug and work on it, test it out on their firewall systems and submit a patch to the developers mailing list.
The wiki has details on how to format the patch submission in line with IPFire’s requirements. https://www.ipfire.org/docs/devel/submit-patches
I want to add some technical thoughts to the excelent explanation of @bonnietwin .
IPFire2 follows the idea of seperate network areas ( now called zones ):
the WAN, untrusted internet, colour RED
the LAN, trusted intranet, controlled by IPFire with subdivisions
wired connection, colour GREEN
wireless connection, colour BLUE
the DMZ, a LAN for devices reachable from outside, colour ORANGE
Throughout the code in IPFire these zones are referenced by their colour ( name ). This implies the associated functionality. Extending the functionality of a zone demands verifying the change at all locations the zone is used.
Another approach for realizing the idea would be to define a third LAN network ( name it GREY ). But this implies changes at all places were LAN is handled from { GREEN, BLUE } to { GREEN, BLUE, GREY }. I think this is a great effort, because all the code has to be revised ( change by someone, verfication by another developer ).
It is possible to do that, but with a much greater active dev community, IMO.
While @bbitsch reasoning has more than some ground to stand, i don’t agree.
Zones are not interfaces nor subnets, zones are “general definitions” of which kind of devices we expect to be there as defaults, but configuring things according to them we can do a lot of working network arrangements.
Default is
GREEN → BLUE → ORANGE → RED
packages flows par default according to arrows, manual config (WUI) is required to allow communication backward.
Green is stronghold, the most defence measure, access-capable and feature rich of the networkw. Any valuable info should be there.
Blue is a nice place to stay, but has less access, less features, less “guard”.
Orange is the fortress wall. You know that they’ll come here, so you must be prepared and be strict on what pass, in which direction.
Red is meadow. Enemies are there.
With these concepts proabably only aqua zone is missing (the network between host and containers) but in any way you can do a lot a correct setups. Because any zone can be used in proper and improper way; improper way is longer and not that smart.
It’s only a matter of
-design network layout
-be dumb, patient and write down every dos an don’ts of the subnets/network adapters
-from dos and donts, write down tests that must go well to say “it works as I would”
-write rules
-test
-verify
-correct rules
-back to test
then… test… test… test… test… did i write enough times… test?
If still doesn’t work, your skillset about how firewall rules work is insufficient, so go back to study someting. (my network toolbox is abysmal, i have to verify, study and feel myself very dumb a lot of times before firewall rules work as I wish).
Network, routing, firewall do what you build to, not automagically what, in the deep of your mind, you wish would.
data flows in IPFire’s standard config are
GREEN <—> RED
BLUE <—> RED
ORANGE <—> RED
with GREEN = wired LAN, BLUE = wireless LAN, ORANGE = DMZ.
It is possible to configure additional paths by WUI or CL.
Many of the steps mentioned are done in the design of IPFire yet, based on the four zones.
Some steps can ( and should ) be formal verified, either by methods by the designer/developer or by revision by other developers.
Because ‘errare humanum est’ ( a lemma of human reasoning ), there must/should be tests also. These tests are best done by users of the software, not involved in development. This latter condition is not really satisfied in the IPFire project. There are many users, which demand only new features but are not willingly even to test these ( if they are implemented ).
After looking at the code base it would be rather daunting to add another ‘zone’.
To get around the limitation of zones I use libvirt/qemu or another system and chain it off of the orange zone. Of course this isn’t the ‘easy button’, but it works.
I track the git repo and go through the build/install/test process on test systems before upgrading the main systems I use. (I’m almost up to speed on how this is all put together.)
Personally, I’d rather let the team work on the next iteration of the project and only fix necessary security updates on the current release.
A device on RED interface cannot initiate connection to any other zone.
A device on ORANGE interface cannot initiate connection to any zone but RED
A device on BLUE interface cannot initiate connection to GREEN but can to other zones.
A device on GREEN can initiate connection to devices in any other zone.
This is the default setup, which do not block the return connections via NAT.
GREEN → BLUE → ORANGE → RED
Factually seems corect to me.
Wow, there’s been a lot of responses to this since I’ve been away!
Thanks @bonnietwin. My suggestion was not to change Orange from being a DMZ by default. It was to add an option for DHCP (and optionally DNS) which would allow users to choose to use Orange for another purpose if they wanted. It is the simplest way I can think of that network flexibility can be added to IPFire without a significant amount of re-work.
Also what’s the problem with having DHCP in a DMZ when static leases are used?
That gives systems on Orange (DMZ) an entry point into the rest of IPFire.
As the DMZ is intended to allow users from the internet to access you want to have it locked up as much as possible from the rest of the firewall system.
Could you please explain your concern with having DHCP in a DMZ? I’m not talking about offering leases out to the internet, only to systems in Orange.
I’m curious as I believe I’ve worked in production environments which used DHCP in DMZs.
Please note that I’m suggesting that it be made an option, not the default. Just like you can change the default to make the Blue network a non-wireless network without MAC address filtering.