I did notice a behaviour change when I loaded the current version of IPFire.
What used to have access across colors is now only one way so the other server on the other color saw the request, but the response is blocked.
You have enter the ip in the firewall groups as a firewall host group.
Then add the firewall rules in both directions:
My production system and my vm network of systems both have systems in orange and those are still able to be accessed without any issues in Core Update 191 that both sets of systems are running.
The vm network also has IPFire systems running with Core Update 192 Testing and there again the same access to servers in Orange can still be made without any problems.
If I understand your screenshots correctly, you have a printer that is in another zone. You don’t say which but as your source is defined as Green then the printer must be in Blue or Orange.
In this case you don’t need to create the firewall rule that you have made as this is making an access from green to either Blue or Orange and this is enabled by default.
It is working fine on all of my IPFire systems.
If the traffic got through to the server on the other colour then the response being blocked is not related to IPFire.
IPFire is a Stateful Inspection Firewall. This means that it keeps information on the connections that have been made so that when a response comes back associated with that connection it is automatically allowed through. Therefore you don’t need to have a firewall rule to allow the return traffic as that is done automatically by IPFire.
https://www.ipfire.org/docs/configuration/firewall/introduction#stateful-inspection-firewall
In my testing the destination was defined as a host from its IP in the Firewall Groups page.
I can’t reproduce what you are describing.
Well I was trying to illustrate one device on orange, but I actually have multiple devices on orange with its access to red blocked.
So I have a Firewall Network Group with the name devices:
Then I used that firewall group to apply the rules:
The default is for Orange to Red being Open, unless you have changed the default firewall behaviour
https://www.ipfire.org/docs/configuration/firewall/default-policy#default-firewall-behaviour
If you have not changed that default firewall rule and devices on orange are unable to access red then I believe you must have created firewall rules that are blocking that.
All my devices on orange are able to access the internet without any blocking.
The firewall rule that you are showing is devices on orange to the green subnet and if your action is to accept then any of those devices on orange can then access devices on the green subnet but that has nothing to do with the ability of machines on the green subnet to access those devices on the orange subnet. That rule is not needed for machines on green to access those devices on orange.
So if the devices you want to access are in orange and the machines that want to access those devices are in green then you don’t need any of those firewall rules and the default settings will allow you to access them.
I can access the server I have in my orange zone from my green zone without needing any additional firewall rule(s).
Yes I did add firewall rules to block orange.
On my old machine that ran version 188 thru 190, If I blocked red with a firewall rule I had to add the rules
orange to green for it to work correct. With the new version I downloaded and installed in the supermicro server I completed building in January, I have to use the firewall groups instead, because the previous rules didn’t work that I ran on the older version.
Current firewall rules with all devices on orange with a firewall group called ‘devices’.
older version, that had a wireless doorbell camera on blue:
Orange only accesses green if red is not blocked on orange.
This is clearly not a fresh install of IPFire as downloaded. It looks like it has been modified for development purposes.
There is no Gold zone in IPFire.
I would suggest doing a fresh install and checking out the situation then to ensure that any modifications of the firewall code fore this Gold Zone has not caused a problem.
Using the firewall groups for defining PC’s by their IP’s ends up with the same result in the same rule. Anything in the firewall groups will be added to an iptables rule(s) in IP format.
You can check this to see if the iptable rule is different or not between the two situations by looking at the WUI menu Firewall - iptables and then select the appropriate chain to look at the rule you have created when using an IP address directly in the firewall rule table or by using a firewall group that has the same IP defined in it.
EDIT:
I just checked this last bit and the iptables rule is the same in both cases, whether I used a firewall group containing the host IP or if I used the host IP directly in the rule creation table.
This topic is different from the one that these posts were previously in, so to keep them separate I have split them off into their own post thread.
Oh that was a pic from a proposed zone I will be making, that I am going to work on in the dev channels this coming up week.
Its a new install downloaded and installed in the beginning of January.
All that is an is an illustration that I created by opening up the dev tools in firefox and added the html code, so nothing was changed on the server.
I noticed it didn’t behave the same as the older installs the instant I configured the new system manually.
I am unable to duplicate the sort of symptoms you are describing.
I have a vm setup with a server running on orange and the default access to red from orange, which I confirmed by running
ping -c4 81.3.27.38
pings were correctly received (the IP is for ipfire.org)
I then created a firewall rule blocking the whole orange subnet from accessing the red interface.
The same ping command then came back with 100% packet loss.
I the accessed the server on my orange subnet from a machine on the green subnet and it successfully accessed the server. The access from green to orange was not changed by blocking all orange from accessing red.
This was with an IPFire running CU191.
maybe there is something different in your install than the iso download on the web site.
All I did to this is install it, configure the zones and added those firewall rules and groups.
I can do it all over again, but its probably going to be the same unless someone changed the iso download. Since this version was 190 and update to 191, I will install 191 from the web site.
I had tested it on a system that had been updated to CU191 from CU190 and prior to that CU189, CU188…
So I have just done three fresh installs of CU189, CU190 & CU191 and in all three cases the only thing I did was add a rule to block the orange subnet from accessing red and in all three cases I could access the server in my orange subnet from a machine in the green subnet with just the default settings. No additional firewall rule needed or added beyond the default settings.
So I cannot reproduce the first step that you are describing, that blocking orange from accessing red causes green to no longer be able to access orange.
Try repeating it without doing any zone configuration and only adding the rule to block from orange to red. Then see if you still have the same effect.
When I downloaded the three iso’s I also checked the sha256sum for each one to confirm that the download was correct.
My iso is for the x86_64 architecture.
Maybe I didn’t understand you correctly previously. I had thought that you were saying that if you blocked orange to red then you could not access orange from green but the above seems to be saying that if you blocked orange to red then you had to add rules for orange to be able to access green. However you would have to do that anyway whether orange can access red or is blocked.
The default for orange to green is blocked unless you create a pinhole.
Could you please clarify specifically what set of conditions give you specifically what problem.
This picture is showing that your devices group is not in orange. If it was then the block would show as orange as in this screenshot
Can you show a screenshot of your hosts definition for devices.
Your previous screenshots only show the host group for printer and the network group for orange.
I was able to get mine to show grey by having the IP address of the device not in the orange subnet. So I suspect that you have a typo in an IP(s) in your group definition of devices.
I just tested it out and if you have a host group with multiple machines in that group then only one of those hosts needs to have an IP that has a typo and is not in the orange subnet for the devices group to be coloured grey rather than orange in a firewall rule.
I was wrong. I made sure all entries in the host group were from orange but still when the host group is used in the firewall it still shows up as grey. It only shows as orange when you use a single host that is part of the orange subnet.
So the fact that your devices entry is showing grey does not mean that there is an IP that is not in the orange subnet.
I think it would definitely be good to have a re-definition of exactly what the issue is so that I can try and reproduce it.
So you just want to test the base install of the red + green + blue + orange networks. One interface each?
on the orange, I’ll reduce that to a HP printer statically set.
This would test the rules set without the interfaces I bridge.
There might be something different with squid and bridged interfaces.
Is iptables version current? Because there was something a while back associated with conntrack that negated firewall rules.
It was updated to the latest version, 1.8.11, in CU191.
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=d353dd36018227e7cdadb3b35b551dbd7b6ec69c
It’s mentioned in the CU191 release announcement.
https://www.ipfire.org/blog/ipfire-2-29-core-update-191-released
Yes. That is what I have been doing.
Can you also confirm is the problem you are experiencing that green to orange access fails when you block orange to red or that orange to green access fails when you block orange to red?
Reading back through the thread it is not 100% clear.
I have been testing green to orange access when orange to red has been blocked.
After reading through your inputs again, I was not 100% sure I had understood the specific issue that you are experiencing. It would be good for me to understand this correctly so I can test the right combination of settings.
Ok, installed ipfire 191 on a different ssd. Configured the networks in install and accessed a printer on orange, Worked.
Added Red → orange drop and Orange->red drop.
I have access to orange to green.
Double checked the behaviour of 190 by swapping back the ssd, and disabling the rules:
green to orange works
enabled orange->red drop and red->orange drop
green to orange stops working.
So the OS I installed on Jan 3 had the iptables issue I’m assuming and why I had to patch the path.
Thanks. I will now add the other interfaces to green and check the 191 install again. If that is ok, I will add the host names. Then last, configure the DHCP on blue. I will verify green->orange traffic at every change and report back.
everything works like it should.
The only thing that is different is vnstat limitation warning of 1000Mb limit on boot, which it says I have to edit vnstat.conf. The 190 install never gave me that warning on boot.
You should change this in your default installs to
BandwidthDetection 0
MaxBandwidth 0
so max bandwidth can fallow link speed as my link speed is 10Gb on all my ports but red.
EDIT, NEW PROBLEM !!! : I didn’t check my wireless, now the access point does not have internet access, but assigns wireless devices an ip address in the correct pool. Rebooting access point and devices do not fix the problem.
Also Kernel needs to be 6.12.13 or greater. 6.6.63 has 27 issues that were solved.
https://www.ipfire.org/docs/configuration/firewall/accesstoblue
With the dhcp page set up for blue subnet you will get an IP but without the Blue Access page setup you will not be able to get internet access.
Core Update 192 Testing has 6.12.13
https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=89c366f3557f2b6e9ab99a93d2f33980cdd566c6