With adam:ONE® muscle version 4.11 and later, one single set of firewall rules is designed to simplify administration. Going forward, all device permissions and policies can be handled at https://dashboard.adamnet.works.
The rules seen below can be automatically created by following the adam:ONE® installation instructions at adamnet.io/pfsense and running adamone-setup configure in an ssh session.
This article is to offer detail on each firewall rule and why they are needed. Furthermore, each LAN segment and/or VLAN requires the same set of rules as follows:
- Prior to adam:ONE® muscle software version 4.11, this rule allowed endpoints to receive a RSET packet upon attempting to reach a block https destination, which, in turn, the adamnet.io/extension uses to redirect to a friendly block page. As of 4.11, this rule is no longer required. It must be disabled in order for MyTools to function via https, or you wish to use DNS Encryption (DoH) for internal use.
- DoT is another DNS Encryption protocol in use primarily by open source and commoditized IoT devices which offer secure DNS by default. This rule is required in case your account is entitled and has DNS Encryption enabled in the dashboard.
- Legacy DNS operates on UDP and TCP port 53 so this rule is essential for adam:ONE® to be available to this LAN segment to answer legacy DNS queries. It is important to note that even RFC 9462 relies on legacy DNS.
- Some operating systems’ connectivity check relies on being able to get a ping response from the gateway.
- By default,
mytools.management(as well asadam1.tools) listens on port 80 for block page purposes, which redirect to https if enabled on the dashboard. - mDNS data is helpful in adding label/names to the dashboard, as names are easier to identify than IP addresses.
- mDNS exists for IPv6 also
- Some devices advertise their names via NetBIOS which may be used for device naming in the dashboard.
- In the event that endpoints attempt to use DNS other than adam:ONE® block such queries (in the words of Dr. Paul Vixie: “My network, My rules”).
- The rule that allows allow packets tagged with
adamone_passto proceed - the tagging is the process by which DTTS® works. - When no rule above has passed traffic, reject it and log it. Such traffic is in violation of DTTS®. It is important to note that if the dashboard has DTTS® setting disabled, all traffic is passed.
- The original IPv4 rule created by pfSense® on the default LAN interface. This must be disabled or deleted. Otherwise there’s no point in the other rules above.
- The original IPv6 rule created by pfSense® on the default LAN interface. This must be disabled or deleted. Otherwise there’s no point in the other rules above.
Note that the firewall rules created by adamone-setup configure script create the non-ghosted rules above but not the separators/comment lines. Those were added for clarity in this documentation only.
Important note on TCP port 443 services
There should be no rule allowing or rejecting TCP port 443 to this firewall or outbound any longer. This is because of mixed use cases. For example:
- TCP port 443 to “This Firewall” is required when offering encrypted DNS by way of DNS-over-HTTPS
- TCP port 443 to “This Firewall” must be rejected when a DNS-based destination is blocked by policy
- TCP port 443 outbound must be rejected when not resolved by DNS (due to DTTS®)
- TCP port 443 outbound must be allowed when successfully resolved by DNS
The above differing cases are managed by anmuscle when running and hence no firewall rule can exist for the stack to function as designed.
For cases opting out of DTTS® (Don’t Talk To Strangers®)
If DTTS® is not going to be used at all, consider adding separators and a rule like this, which will need to be enabled in order to prevent segment-to-segment traffic (DTTS® will do this by default, if enabled, so not needed):
Note that legacy installations prior to 4.11 will not exactly match the above rules, but they can be manually adjusted to match the above.
Any other necessary rules
The goal of the adam:ONE® stack regarding this standard set of rules is to be able to rely exclusively on the dashboard to create enablers. The only time additional rules may be required is if protocols other than TCP, UDP and ICMP are required. For example, if you need to pass ESP or GRE traffic, rules will need to be added near the top as those protocols are not supported by Enablers.