My WAN IP is not considered to be the RED interface, because its color is black. That explains my test results. But atm I don’t understand why’s that . There is something basic I must have missunderstood.
There is a bug in the order of the network scripts. If the outgoung firewall if it is in blocked mode the unbound scripts is running before the allow rules are loaded.
That’s what I expected first, but I’ve changed the source to firewall(any) and target to RED (internet) what I wanted/intented to do. Now it actually works also in outgoing blocked mode. Therefore I can’t confirm that anymore.
Also my tests in allowed mode with rule number 7: “block anything else exept rule 1-6” proved that the rules are already active when services like ntpd or dnssec start.
ok. that does not apply to my situation. Thanks anyway. I always have set it similar to lines 1 to 6 in your ‘Working’ example in one of your previous posts but with ‘Richtlinie: Blockiert’. Because in this Outgoing Firewall Rules Section there are the rules for IPFire itself when it tries to access the internet (updates and such).
Additionally I have everything blocked and only allow some things. In the Firewall Rules Section I have blocked DNS for everyone such that the devices need to contact the unbound DNS only for DNS tasks. But I think I should open the DNS port for the firewall computer’s IP itself so it can access the defined DNS servers during boot time. Need to try that one.
I do exactly the same. That was just set to “allowed” for testing purpose to find out if the rules take effect before or after the services start and they actually do. I setup the outgoing firewall rules a long time ago with an example configuration. Now I had to find out that this was actually not right.
The error ocours also not in all connection types. The outgoing rules are missing at first init because the interface for “red” was not created yet but the main blocking policy is already there.
The wiki should be correct if the firewall was full started. If you try to restart unbound manually after you are already connected you should not get this error if your rules are correct configured.
The fix is not included yet. It should came with core142 if i not mess it up…