Author: Skylar.W

You would think that I would be aware of the order of parsing for
firewall rules when placing them into effect at four in the morning…
Apparently not. I apologize for the issues this caused in routing and
I have swapped the rules into the correct order for processing DNS
queries on our network.

If you guys notice that things break, please email me when you first
notice that it is broken! I want to keep the ship afloat and as you
guys can see, without extra eyes on the project, I sometimes make mistakes.

—
Something else we are trying out and seeing how it works out with the DNS
resolver. Under the old method, domains that were blocked would simply be
responded to as 0.0.0.0 which makes the client have to timeout after a
while when loading webpages. On Catos, we are piloting the use of the
NXDOMAIN flag to see if it results in a better user experience when browsing
webpages that may have some of their content blocked by the DNS filtering.

Hey guys,
We made changes to our firewall rules as of today. Going forward,
the project will default to implementing rules that should provide
isolation between subnets. This has been on the road map for a
while but was a back burner task compared to getting the rest of the
network up and running.

We also finally have deployed a network management console internally
that is now handling network usage data for accounting and keeping an
eye on who is doing what on the network. Insight like this is a very
valuable tool that will help us plan future upgrades as well as spot
any potential issues in the network earlier.

Something that was overlooked during the planning and deployment phase
of our network was that we were allowing port 25 and port 465 to be used
on our network and it was something that just slipped our minds for a
long while. This has been corrected as of today. We are now dropping these
ports at the edge and on our wireguard interfaces. Project members are not
allowed to host mail servers on our network. The terms of service and
network management policies have been updated to reflect this change.

In addition, we have brought on a few more project members, which means
a few more /64 subnets have been setup for routing. Pretty cool to see
others taking notice of what we have built out over the past few years!