Messages

Yes I agree that opening up udp443 is 100% going to make you vulnerable to dns over the same UDP port if the same destination IP has both services available on that endpoint. This is always the struggle and compromise, but in some cases it is required that the functionality can take prescience over the possible risk of allowing the traffic. This is the situation I am in since whatsapp traffic must flow, even if it means allowing quic traffic (risk is accepted due to compatibility taking precedence).

As it happens I am when a user makes a whatsapp call, if it has an issue I am now checking the logs at the exact time, finding the IP's and adding then to the whitelist for zenarmor. This is similar to what you would do your side but has the disadvantage of nobody else in the world being able to benefit from my capturing of IP's and sharing that information.  So while eventually after a few months the situation will get resolved or me, nobody else is assisted by this method.

P

Yes I was hoping zenarmor had a list of ips that needed whitlisting because otherwise how can I predict what they are?

While blocking quic (under the media streaming policy) does precent dns over quic from working, it also blocks whatsapp audio calls as they use udp 443 also for their calls. How can I allow whatsapp calls while still blocking quic In general? Unfortunately the current rule is too blunt and instrument so I have had to turn it off as whatsapp audio calls are used on the network. This exposes allowing all quic traffic however.

Kind regards
P

I do this more simply thusly:

1) Outbound NAT rules to redirect port 53 TCP/UDP to Pihole (Log to locate devices trying to bypass your DNS and remove them from your network).
2) Outbound NAT rules to redirect port 853 TCP/UDP to Pihole(Log to locate devices trying to bypass your DNS and remove them from your network).
3) Zenarmor tick rule to block DNS over TLS (Zenarmor has a logging interface automatically)
4) Zenarmor tick rule to block DNS over HTTPS
5) LAN rule to block 8853 UDP out (Dont bother logging any chrome browser will trigger log).
6) LAN rule to block 443 UDP out (Dont bother logging any chrome browser will trigger log).
7) LAN AllowList Alias to allow out CND networks if required
8 ) LAN BlockList Alias to block outbound IP's on lists (LOG THIS RULE SO YOU CAN SEE WHEN IP's BLOCKED):
    https://raw.githubusercontent.com/dibdot/DoH-IP-blocklists/master/doh-ipv4.txt
    https://raw.githubusercontent.com/pallebone/TheGreatWall/master/TheGreatWall_ipv4
    https://raw.githubusercontent.com/oneoffdallas/dohservers/master/iplist.txt
    https://raw.githubusercontent.com/jpgpi250/piholemanual/master/DOHipv4.txt
    https://raw.githubusercontent.com/cbuijs/accomplist/master/doh/plain.black.ip4cidr.list
    List of manual IP's I have found:
    Manual added DOH IP's: 1.1.1.1,1.0.0.1,1.1.1.2,1.0.0.2,1.1.1.3,1.0.0.3,104.17.64.4,104.17.65.4,203.107.1.4,193.161.193.99
    Manual added DOH ranges: 101.36.166.0/24,203.107.1.0/24

Note : AllowList I have had to open so far contains this port/ip combinations:

Allow out port 443: 151.101.66.133, 151.101.2.133, 151.101.130.133, 172.67.75.103, 104.26.2.13, 185.199.108.153, 185.199.109.153, 185.199.110.153, 185.199.111.153, 104.26.3.13, 151.101.194.133, 216.239.34.21, 44.235.246.155, 151.101.65.195, 104.26.4.174, 172.67.70.80, 104.21.39.13, 172.67.170.203, 151.139.128.10, 104.26.5.174, 151.101.1.195, 141.193.213.21, 172.67.212.2, 104.21.85.239, 44.236.72.93, 104.16.132.229, 141.193.213.20, 217.64.148.8, 104.21.68.104, 96.126.123.244, 45.33.20.235, 44.236.48.31, 216.239.36.21, 216.239.38.21, 104.19.155.92, 104.21.15.239, 167.172.139.120, 216.239.32.21, 90.155.62.13, 90.155.62.14, 95.216.25.250, 162.159.138.85, 162.159.137.85 172.224.62.11 172.224.63.11 172.224.63.19 23.227.38.65

Allow out port 123: 69.1.1.251, 129.250.35.250, 129.250.35.251, 162.248.241.94, 194.36.144.87, 95.216.24.230, 45.76.113.31, 94.16.114.254

Allow out port 80: 151.101.66.133, 151.101.194.133, 151.101.2.133, 151.101.130.133, 141.193.213.20, 172.67.70.80, 104.26.4.174, 184.168.131.241, 17.253.85.204, 162.159.138.85, 162.159.137.85

With this combination I have not been able to find a way to bypass the block unless an IP is added to the allowlist (required if you want to access a site that is a CDN).

I occasionally update this page with new IP's or lists I find (the DOH stuff is near the end):
https://github.com/pallebone/PersonalPiholeListsPAllebone

I recently purchased an opnsense appliance for a client.  It appears 1500 dollars was not spent wisely.  it appears 22.7 is not supported on official hardware as their fix for any problem is to reinstall 22.1.  Right now the only email contact i can get to is sales....is there an actual support mailbox at the parent company?

You should be running the business version in a business setting, or doing extensive testing prior to deploying updates yourself. You are given choices to ensure safe upgrade (latest business version is based on 22.1.7 as of this message) or you are given the choice to do this yourself for free (cost is your time). You must choose what is appropriate for your use case. That is fair, considering they are giving you the choice to use the software for free or pay and have them test it on your behalf. We have to be reasonable here. I personally find this arrangement extremely reasonable and cost effective.

Thanks Franco, you are as always, a gentleman, a legend and a force against all chaos in this world.

I guess you are right, then I dont know. I did notice you can also specify a port on the domain overrides by using <ip>@<port> so you can change the port there also.

They do 2 different things. Domain overrides tells unbound to locally resolve the domain to whatever you set there. Query forwarding forwards the query to an upstream dns server or internal dns server that can be administered and have record values change by someone else or you without intervention on the unbound side. There could be many reasons for this eg: someone runs an AD install and needs unbound to be able to resolve dynamically created records that appear via DHCP registration internally etc or any number of reasons like that.

Thanks this was correct and I could find the entries.

Before updating to 22.7 aliases that were of type "URL Table (IPs): with a refresh interval, when updating on the refresh interval would write to the system log "fetched alias <name> from <url>" or something to that effect I dont remember the exact wording. I used this during my daily audits but now it appears this no longer occurs. Where is this information being logged/how can I turn logging back on for the aliases that update. Was this change intentional or a bug? I would like to view the log/when aliases update in some log somewhere, dont mind where but should be exposed in my opinion.

Kind regards
Peter

Thank you, very helpful.

I understand. Is the roadmap in years or months for this? Just want to understand if we are 6 months or 6 years away.

I switched to kmod a while ago and was happily waiting for zenarmor to 'catch up' and eventually be able to support monitoring on the kmod version of wireguards interface. However now I am thinking that will never happen as the kmod version is stripped down and missing stuff that sensei/zenarmor needs to work. Did I imagine that it was possible for the kernel version of wireguard to be supported one day by zenarmor or is that impossible by design and I shoumd be using wireguard go instead?

I posted how I did it via the gui above.

I did it via the gui by selecting:

Enabled - Y
Service - Custom
Protocol - DynDns2
Server - dynupdate.no-ip.com
Username - <as appropriate>
Password - <as appropriate>
Wildcard - N
Hostnames - <as appropriate>
Check IP Method - Interface
Force SSL - Y
Interface to monitor - WAN

Then it worked fine.