Ignoring broken upstream name servers / DNSSEC has been set to permessive mode

At the startup I get the message: Ignoring broken upstream name servers

I don’t know what it’s trying to tell me by that.

After about 5 minutes of waiting that it goes on I get the message: DNSSEC has been set to permessive mode

Looks like I have that problem already for a long time, but I did a clean reinstall and I still get it :roll_eyes:.

I also find the drop output in the fw log but that shouldn’t happen:

192… IP is the right IP for RED / WAN interface.

I did some further tests and I’m kind of confused:

Not working:

Working:

Why is that?

Aah when I had a look in the connection overview I got it because of the colors used there:

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 :face_with_raised_eyebrow:. There is something basic I must have missunderstood.

Oh noooooooooo I messed up with the source and destination directions! :grimacing:

Got it now. Never mind! :expressionless:

Hi,

what was the solution now? I have the same problem.

Cheers

Gremlin

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.

run

mv /etc/init.d/networking/red.up/05-update-dns-forwarders /etc/init.d/networking/red.up/22-update-dns-forwarders

to change the order.

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.

Hi,

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).

At least according to the Wiki:

https://wiki.ipfire.org/configuration/firewall/rules/processing

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.

Thanks for your reply.

Cheers

Gremlin

Howdy, Arne. Has the script rename made its way into a release?

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…

Hi,

yes, right now I need to restart unbound after boot. Then all is working.

A fix is coming? That is great.

Cheers

Gremlin

Fix is in git. But i have seen and edited a typo in my previous post. The correct cmd to move is:

mv /etc/init.d/networking/red.up/05-update-dns-forwarders /etc/init.d/networking/red.up/22-update-dns-forwarders

Hi Arne,

thanks. I just changed the file name from 05-update-dns-forwarders to 22-update-dns-forwarders via WinSCP. Will see the result during the next reboot :grin:

Cheers

Gremlin