Thanks for providing the detailed screenshots and feedback. We completely understand your concerns, the current configuration logic indeed seems unintuitive.
1. The Issue: Stateless vs Stateful
In your commonly used ufw, the firewall is typically "stateful," automatically tracking ESTABLISHED connections. That is: if you actively initiate an outbound request (such as pinging Google or checking for updates), the firewall will automatically allow the corresponding response packets.
In the existing logic of the TOS firewall, it currently operates in stateless mode. When you set "Incoming: All - Deny":
- It not only blocks external attacks.
- It also indiscriminately blocks response packets to requests you initiated.
- Since the IPs for CDN (system updates), DNS, and NTP services are dynamic or widely distributed, once Deny All is enabled, your NAS essentially becomes a "local area network island".
Your rules currently only allow the physical LAN segment (192.168.4.0/22), but:
- Tailscale uses a virtual subnet (typically 100.64.0.0/10) and relies on UDP handshakes.
- Docker containers communicate through bridge networks (such as 172.17.0.0/16).
Recommended Optimization Strategy
To balance security and usability, it's recommended that you adjust your firewall approach, moving from "full IP blocking" to "critical port protection":
Option A: Change "Deny All" to "Deny Specific Sensitive Ports" (Recommended)
Remove the Deny All Incoming at the end and instead deny common high-risk ports for All IPs. This can both prevent external scanning and infiltration, and won't affect internet connections actively initiated by your NAS (such as system updates).
Option B: Manually Complete the "Return Path"
If you insist on using Deny All, you must add the following rules above it:
- Allow Tailscale: 100.64.0.0 / 255.192.0.0 (please adjust according to your actual situation)
- Allow Docker: 172.17.0.0 / 255.255.0.0 (please adjust according to your actual situation)
- Allow DNS Responses: UDP 53 (from All IP)
