Greetings, all. I’ve looked around for similar issues without finding any, so apologies if my problem is answered on page 1 of an introductory document.
I used a different router/firewall distribution for about twenty years, and finally jumped ship when its WUI broke down under the stress of being asked to remember five static addresses. I fear that system is collapsing under the weight and complexity of its ambition to be a complete workgroup server. IPFire looks like a much more focused and elegant solution, and so far I am very happy with the design.
Except when I try to make the leap from two interfaces to three, that is. I am trying to host a web server in a DMZ. Twice I have attempted to set it up, and twice it has brought down the rest of the network.
One the first attempt, I started with hardware for only the GREEN and RED interfaces installed. After that proved itself for a couple of days, I installed another NIC and bound it to the ORANGE network through the “setup” program. The moment I created the Firewall rule to permit traffic inbound to the web server, the RED interface stopped accepting packets, and refused to take DHCP information upon boot.
I managed to get back to a RED/GREEN configuration and all was well for another 24 hours. Tonight I took a slightly different approach to RED/GREEN/ORANGE: The third NIC was already installed and had be unused during the RED/GREEN phase. I used ‘setup’ to switch to a RED/GREEN/ORANGE model again, and at first all seemed well.
I tested interaction with the web server in the DMZ, and it was so easy that I wonder whether the firewall was even up. Then I took a break and watched some streaming TV. About an hour after I’d switched on the RED/GREEN/ORANGE configuration, a message popped up in the middle of our show, explaining that the Apple TV could no longer find the internet. I rushed back down and reverted to RED/GREEN, and that seems to have solved the problem.
The question is, is it worth trying to troubleshoot the three-interface problem? How should I proceed?
Both problems are highly unusual. I have had a web server in orange for years and never remotely dealt with either situations. I also do not remember either many posts here describing this kind of loss of connectivity.
To answer your question, IPFire is a small project written by competent people that has achieved a very solid and usable product. At the cost of a User Interface that suffers a bit the small size of the active pool of contributors. Also, network routing is a complex topic. Therefore it requires time and willingness on the part of the user to learn some basic skills of Linux-based system and network administration.
The first thing you should do when something like the problems you have described emerges is to go to the system logs and figure out what went wrong.
This forum will assist you if you want to do that.
Thank you for your response. It is clear to me that people are having success with IPFire, and to me the interface seems well-suited to its purpose. I am sure that I’ve bumped into a corner case involving some combination of hardware, procedure, and/or environment. I am not averse to learning some things along the way.
I set this problem before the community hoping that, because the procedure I’d followed was simple, perhaps the problem was relatively common. It appears that this is not the case.
It seems likely that I’ll have to go to the logs at some point, but right now the amount of information that I’d have to sort through is daunting, especially since I don’t really know when the problem started. Perhaps I should start by asking this: is it reasonable for me to begin with a two-interface system and then add a third? Or should I start with all three interfaces up, be sure that RED and GREEN are stable, and then start using ORANGE?
I have another bit of bad luck in that two of my NICs appear identical during setup. Before I change anything, I’m going to record the MAC addresses for each.
That worked! For the benefit of those who may find this message later: changing network configuration without reinstalling IPFire can be very risky, and as of now I don’t recommend it. I’m new to IPFire and perhaps the problem is my hardware. But I searched the documentation and this forum and all I could find was a warning that I understood as “be careful when using ‘setup’ to change network configuration after installation.”
In the future I may learn of situations where it is a good idea to do that, but as of now I will not change the active networks, or add, remove any network cards without reinstalling IPFire.
That is an unfortunate limitation, if it exists, but at least the installation is fast and simple.
I did this for friend when he changed provider and went from fiber to VDSL. The hardware was the same, but the tipe of internet connection (from DHCP to VDSL) required a new run of the setup program. It worked well.
That’s good to know. It makes sense that the setup program must have some good use after installation, or it would not have been made available.
I need to do some learning about the ORANGE/DMZ network. I thought that all communication with it from any network would be blocked unless one permitted it through firewall rules; but every computer on the GREEN network has no trouble reaching the web server. HTTP, SSH, and ping all get through. I do hope that internet access to the ORANGE network is blocked!
Hmm. I’m creating a rule similar to this one on the Wiki. The diagram on this page appears to suggest that ORANGE is protected by the firewall. I assumed (perhaps incorrectly) that meant it was protected by the default DROP policies.
Here is the result, along with my version of that cheat sheet. Looking closely at the documentation again, and in light of your note, it appears that I should add a third rule to drop everything that doesn’t match the first two. Is that more or less correct?
(EDIT: as soon as I get the certificate in there, I’ll be deactivating the HTTP rule.)
(UPDATE: the provider of my certificate says that port 80 should be left open.)
Thanks very much for bringing it up. I’m now sure I misread the documentation and didn’t realize the exposure. I’m not certain I understand what you mean by “they are locking you out.” Perhaps it was a reference to the original topic? Where activating ORANGE after installation had disastrous consequences? At any rate, I think it’s working now. (I’ll really know after getting SSL working.)
Yes it is. You may have misinterpreted what some of the other posters said. They were answering your question about green being able to access all the other zones without any firewall rules as default.
From that you can see that the Internet (Red) cannot access any of the other zones, green, blue or orange, unless a port forward rule is written.
To make things easier for beginners, but still secure, the default access from green to all other zones is set to open.
Once familiar with the firewall and setting up rules you can change the default Forward policy from allowed to blocked. This would then result in every zone not being able to access any other zone unless a firewall rule is written for it. In the default zone ruleset table this would make every open entry changed to closed unless a firewall rule was defined for the required traffic. Also Blue would then need both the Blue Access page set up and firewall rules defined also.
This requires some experience and is why it is not the default as installed. Most people probably stay with the default for ever. All commercial firewall/router boxes have that as their default and on them you cannot usually change that unlike as with IPFire. https://wiki.ipfire.org/configuration/firewall/default-policy#forward
Thank you for clearing that up. Now that I’m becoming slightly familiar with IPFire, it is working very well for me. I must say I’m impressed with both the product the community around it.
