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