Firewall Rules re: Blog August 18 - "nothing works"


Per Peter’s idea for hardening have change “forward firewall” and “outgoing firewall” policies to “blocked”, rebooted and of course nothing works. Have added OUTGOING RULES DNS, NTP, ICMP, HTTPS, and WHOIS per the ipFire Blog of August 18.

Still Access is “nothing works.” Is there something missing?

Any of the rules hits some rows on log?

I’ve returned the Configuration to Allow, immediately after getting Nothing. Which to Block

Hi,

Still Access is “nothing works.” Is there something missing?

yes: You have created firewall rules for outgoing traffic generated by IPFire itself, but you are missing firewall rules allowing traffic generated by clients behind IPFire.

This makes a huge difference in terms of a firewall.

In your case, you could use IPFire’s web proxy and should be able to reach most web sites (if you allow port 80 for plaintext HTTP as well), since the proxy is running on IPFire itself and therefore outgoing firewall rules apply to its traffic, not forwarding ones.

The blog post (reference: it is located here) did not contain any further hints regarding concrete firewall rules for forwarding traffic:

Since further firewall rules depend on your network, we can only provide you with some common Best Practices for creating and maintaining them […]

Answering your second question: Yes, both “forward” and “outgoing” default firewall behaviour need to set to “block” for the configuration explained in the blog post.

Thanks, and best regards,
Peter Müller

You have created firewall rules for outgoing traffic generated by IPFire itself, but you are missing firewall rules allowing traffic generated by clients behind IPFire.

Then SOURCE Interface BLUE : DESTINATION RED communicated with ipFire because it is “Interface”? I’ve fiddled various Rules not addressing Interface, to allow clients but still Nothing. One Rule allowed All Protocols just to pass the Block Rule yet that didn’t work. Another Rule limited Protocol TCP Source 80 Destination 80, using your example of allowing HTTP, yet that didn’t work.

What else is try?

Hi,

Then SOURCE Interface BLUE : DESTINATION RED communicated with ipFire because it is “Interface”?

yes, this refers to the BLUE interface of IPFire itself, not the BLUE network.

One Rule allowed All Protocols just to pass the Block Rule yet that didn’t work. Another Rule limited Protocol TCP Source 80 Destination 80, using your example of allowing HTTP, yet that didn’t work.

The source of this rules must be set to the BLUE network, this is critical. To sum it up, this rule should work by allowing any traffic from the BLUE network to the RED one (i. e. the internet):

Source: Standard networks -> BLUE
Destination: Standard networks -> RED
Protocol: All

Thanks, and best regards,
Peter Müller

Educational but still Nothing. Firewall and DNS. Something missing?

Hi,

the first two rules look good. You should be able to run ping 8.8.8.8 or similar and get a response back.

I misunderstood your posts regarding the source interface of the outgoing firewall rules. Please set their source interface to RED instead (caveat: due to bug #11932, you have to use “any” as the source interface for the DNS rule) and try again.

Thanks, and best regards,
Peter Müller

Peter the Great. Thus far that works. IPS will likely not update tomorrow. The FW Logs however show an endless chain of DNS TLS at 853 of each Server and dropped. Is DNS over TLS not working?

Hi,

Thus far that works.

I see, thanks for reporting back. :slight_smile:

IPS will likely not update tomorrow.

Why? Downloading new rulesets via HTTPS is possible according to your screenshot.

Is DNS over TLS not working?

Seems like it. Could you post the configuration of your DNS firewall rules again?

Thanks, and best regards,
Peter Müller

Blockquote

Why? Downloading new rulesets via HTTPS is possible according to your screenshot.

The problem may be the NTP isn’t updating, and according to the readings the correct Time is required for DNS over TLS. Is that right?

The image is only a snippet, its been No Time since implementing the Block. And DNS firewall Rule:

Ah. Forgot to mention that ipFire only connects through BLUE. That might effect your Opinion, the configuration looked alright. I’ve got the Time fixed, but need to wait until to tomorrow to confirm.
11 Hours later. IPS and Time update normally. However, DNS fails. Which Rule or is the problem the Order of the Rules?


Hi,

the source of outgoing firewall rule 2. As I mentioned, please try “any” instead.

Thanks, and best regards,
Peter Müller

The change made a difference. Is it correct?

A IP/DNS Check showed zero servers and 100 errors.

And the Firewall Log found port 853 blocked.

While there are Browser improvements, for instance YouTube is now playing the DNS over TLS appears not used.

Hi,

you changed the destination of the firewall rule. I was referring to it’s source.

Thanks, and best regards,
Peter Müller

Changed the Rule to Source, Since your instructions used the word Any, adjusted the Destination to Any.


The IP/DNS Checker

And the LOG. Doesn’t respond correctly. Connection to the Web is acceptable. But not DNS over TLS.
And a strange 1.2.3.4. What’s missing?

Current Firewall. Same Results. Using Any as the Source for DNS moved the Rule from Outward to Incoming - trying to utilize Peter’s solution. What’s missing.

Maybe it works, maybe not. The DNS checker finds 5 of the 7 DNS Over TLS but reports 63 Errors. And to accomplish getting the DNS required un-expectant Firewall Rules Would a person familiar with ipFire Firewall examine the collection of Rules.

Hi,

I am closing this topic since the original poster apparently does not have any idea about what he is doing, refuses to provide meaningful log messages and to read the documentation by himself.

Thanks, and best regards,
Peter Müller

2 Likes