I get crazy …
This rule:
I read: The host named Battery from “Firewall Groups/Hosts” is NOT allowed to reach the RED LAN (Internet)
leads to this log:
(192.168.253.23 is Battery from the picture above)
Additional, the address 192.168.253.23 is in the “Banned Address” Field in the Proxy Config.
From my POV this is sufficient to block all traffic from 192.168.253.23 into the Internet.
Where is my fault?
Because none of the two rules ( FW and proxy ) is a default/standard rule, the admin who defined these should answer this question.
?? I add this via this @#$%WebUI. I choose ‘New rule’ and set source, destination, protocol and so on. What did I miss do bring this rule in action?
Even the display in WebUI looks like ‘traffic is not permitted’.
Can you rewrite the rule by putting in the source not the named group “Battery”, but directly 192.168.253.23 IP address and see if now this traffic gets properly dropped/rejected?
Log says that it is dropped.
The WUI log pages only mention the rule, the action is defined in the FW rules.
If you get an entry ‘FORWARDFW ’ the associated rule was active and the action DROP or REJECT ( signaled by the colour ) was done.
Difference of FW rule and ‘Banned Address’ in proxy config:
latter works only on HTTP(S) packets,
the first on all packets.
Surely, but this makes no difference. The log shows ‘FORWARDFW’
The log shows:
Both rules are the first rules in the chain, so I think if the rule match no further rules will be checked for this packet. (The last policy is ‘allowed’, but this should not inverse the rules above.)
I am pretty sure that I have seen log entries with DROP or REJECT in this column.
Sometimes I think I have understand how IPFire works … but than I have a look into this @#$#$ WebUI and all goes wrong.
Ok, goto sleep …
when awake - please click on the pencil icon, take a screenshot of the entire rule page and post.
By default Blue is allowed to access red, as long as the blue access has the mac addresses entered or overruled.
Therefore I believe that entering a firewall rule in the Firewall Rule WUI to stop access from blue to red won’t work as it has already been allowed.
You either need to put the rule in firewall.local in a Custom Chain so that it is run before the normal default rules, or you need to block all traffic going out to red and create the rules that allow only the traffic that you want from blue to red.
The rule stops access.
I’ve tried a similiar rule to cut the internet connection of a SmartTV, if my grandson consumes too much youtube movies.
Only difference is, my TV is on green.
I can confirm this. In my effort to test the firewall functionality, I configured a rule as follows:
Source: 10.1.3.51 (my phone, located in the blue network)
Destination: RED
Protocol: All
Target: Drop
Subsequently, my log displayed:
Sep 16 13:05:50 ipfire kernel: DROP_CTINVALID IN=blue0 OUT= MAC=[..] SRC=10.1.3.51 DST=10.1.3.1 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=56182 DF PROTO=TCP SPT=42400 DPT=800 WINDOW=1542 RES=0x00 ACK PSH FIN URGP=0
Sep 16 13:00:00 ipfire kernel: DROP_CTINVALID IN= OUT=blue0 SRC=10.1.3.1 DST=10.1.3.51 LEN=52 TOS=0x00 PREC=0x00 TTL=64 ID=16160 DF PROTO=TCP SPT=800 DPT=42260 WINDOW=126 RES=0x00 ACK PSH FIN URGP=0
It is worth noting that this only occurs when the proxy is deactivated. When the proxy is engaged, packets are directed to the FORWARDFW chain and then proceed to the red interface, overriding the aforementioned rule.
I suspect the root of @berny’s issue lies in the proxy settings. To validate this theory, I would recommend disabling the proxy and assessing whether traffic is appropriately dropped or rejected. Should this resolve the matter, I suggest that @berny initiate a separate thread addressing the proxy configuration concern and mark this thread as resolved.
Does this not answer the Question?
The “FORWARDFW” is the Chain of opperation.
The fact it is RED in color Signals action DROP or BLOCK.
yes, I think it does. Those are packets directed to the proxy. When the proxy is disabled, the firewall should work as expected.