NextDNS CLI on Firewalla revisited (working DHCP host resolution in NextDNS logs)
I ended up rolling my own solution after running into issues with another post here regarding setting up NextDNS CLI on a Firewalla -- I was having problems where setup-router=true wasn't working for me, causing dnsmasq and NextDNS CLI to fight over port 53.
Below is what is working for me on my Firewalla Purple (box v1.974), including device identification in NextDNS logs:
Update:
Nice [un]install scripts provided by Michael Bierman here: https://github.com/mbierman/Firewalla-NextDNS-CLI-install
#!/bin/bash
# install & configure NextDNS CLI on startup of Firewalla
# file goes in: /home/pi/.firewalla/config/post_main.d/
# DNS over HTTPS must be disabled in Firewalla app
# install NextDNS CLI
sudo wget -qO /usr/share/keyrings/nextdns.gpg https://repo.nextdns.io/nextdns.gpg
echo "deb [signed-by=/usr/share/keyrings/nextdns.gpg] https://repo.nextdns.io/deb stable main" | sudo tee /etc/apt/sources.list.d/nextdns.list
unalias apt
sudo apt update
sudo apt install nextdns
# replace -config 123456 with your own NextDNS config ID
# replace 10.10.12.1 with your Firewalla local lan IP
# enable NextDNS caching: https://github.com/nextdns/nextdns/wiki/Cache-Configuration
# set discovery-dns to IP of Firewalla local DNS
# set NextDNS CLI to listen on local network IP (instead of 127.0.0.1 -- allows DHCP host resolution in NextDNS logs)
# define listen port instead of relying on -setup-router
sudo nextdns install -config 123456 -report-client-info -cache-size=10MB -max-ttl=5s -discovery-dns 10.10.12.1 -listen 10.10.12.1:5555
# alternate command to implement conditional configuration: https://github.com/nextdns/nextdns/wiki/Conditional-Configuration
# replace 192.168.122.0/24=abcdef with your own additional network and NextDNS config ID
# sudo nextdns install -config 192.168.122.0/24=abcdef -config 123456 -report-client-info -cache-size=10MB -max-ttl=5s -discovery-dns 10.10.12.1 -listen 10.10.12.1:5555
# Add dnsmasq integration to enable client reporting in NextDNS logs: https://github.com/nextdns/nextdns/wiki/DNSMasq-Integration
cat > /home/pi/.firewalla/config/dnsmasq/mynextdns.conf << EOF
server=10.10.12.1#5555
add-mac
add-subnet=32,128
EOF
# restart Firewalla DNS service
sudo systemctl restart firerouter_dns.service
NextDNS CLI seems to hijack all DNS requests, hence the alternate config option (I created a new NextDNS config to use with devices on one of my VLANs). The DNS servers I specified in the VLAN network config were being ignored (devices show the DNS servers specified by the VLAN config, but NextDNS was still logging/blocking DNS requests to these devices).
Note that NextDNS seems to truncate device names after the first period. You can replace spaces with hyphens or remove them altogether in the Firewalla app for a more informational device name in the NextDNS logs (Firewalla converts spaces in devices names to periods).
There's more I'm probably forgetting to note, but I'm running out of time and have to go prep some food for tomorrow's 4th family celebration. I will update at a later time if something comes to mind, or if there's questions.
-
I would assume that if NextDNS isn't running as expected (i.e., "something is wrong"), the network clients would experience general DNS failures, no? That was the behavior I experienced when I concluded the NextDNS service itself was having a case of the hiccups. I haven't killed NextDNS on purpose to test this theory (it would have to be off-hours as I don't want to deal with the complaints -- especially if I take more than a couple of minutes to restore service because I broke something).
Going by the NextDNS logs you posted, it looks like a simple service restart to me (service goes down on command and restarts immediately). Have you combed over the syslogs during those times to see if there's more pertinent messages?
Is it possible your script is getting a false negative when checking the status of NextDNS service?
[edit -- We seem to be posting over each other :) ]
If DNS resolution isn't failing when your monitor script says NextDNS is down, it definitely seems like a false report of the service being down. Can you temporarily disable the "restart on failure" feature of your monitoring script and see if anything changes? -
@Brian,
I just ran the command directly, "sudo nextdns status". There's not much way to screw that up—even for me. :)
Since it seems to recover quickly the answer to your question may be, "no". Why? there's some caching going on. If nextdns is restarting within a few seconds or less (as it seems to be) then clients might not notice it. Still doesn't make me very happy about using the service that goes down so often.
Have you combed over the syslogs during those times to see if there's more pertinent messages?
Yes, but perhaps I didn't know what to look for. Any suggestions?
-
Since you got me digging, I found something interesting in syslog:
Oct 4 17:45:01 localhost pi: Firewalla checkpoint every 5 mins
Oct 4 17:46:08 localhost nextdns[15977]: Connected 208.89.60.14:443 (con=28ms tls=37ms, TCP, TLS13)
Oct 4 17:47:27 localhost nextdns[15977]: Connected 208.89.60.14:443 (con=30ms tls=41ms, TCP, TLS13)
Oct 4 17:47:50 localhost systemd[1]: Reloading FireRouter DNS.
Oct 4 17:47:50 localhost systemd[1]: Reloaded FireRouter DNS.
Oct 4 17:47:57 localhost systemd[1]: Reloading FireRouter DNS.
Oct 4 17:47:57 localhost systemd[1]: Reloaded FireRouter DNS.
Oct 4 17:50:01 localhost pi: Firewalla checkpoint every 5 mins
Oct 4 17:51:16 localhost nextdns[15977]: Connected 208.89.60.14:443 (con=29ms tls=38ms, TCP, TLS13)
Oct 4 17:52:08 localhost nextdns[15977]: Connected 208.89.60.14:443 (con=29ms tls=35ms, TCP, TLS13)
Oct 4 17:52:50 localhost systemd[1]: Reloading FireRouter DNS.
Oct 4 17:52:50 localhost systemd[1]: Reloaded FireRouter DNS.
Oct 4 17:52:57 localhost systemd[1]: Reloading FireRouter DNS.
Oct 4 17:52:57 localhost systemd[1]: Reloaded FireRouter DNS.
Oct 4 17:55:01 localhost pi: Firewalla checkpoint every 5 mins
Oct 4 17:55:10 localhost nextdns[15977]: Connected 208.89.60.14:443 (con=0ms tls=0ms, TCP, )
Oct 4 17:56:23 localhost nextdns[15977]: Connected 208.89.60.14:443 (con=29ms tls=36ms, TCP, TLS13)
Oct 4 17:57:44 localhost systemd[1]: Reloading FireRouter DNS.
Oct 4 17:57:44 localhost systemd[1]: Reloaded FireRouter DNS.
Oct 4 17:57:55 localhost systemd[1]: Reloading FireRouter DNS.
Oct 4 17:57:55 localhost systemd[1]: Reloaded FireRouter DNS.
Oct 4 18:00:01 localhost pi: Firewalla checkpoint every 5 minsAnd sure enough, a "nextdns status" that coincided with one of these "reloads" caused a "not installed" response.
root@Firewalla:/var/log# grep "Reloading FireRouter DNS" syslog | more
Oct 2 00:02:50 localhost systemd[1]: Reloading FireRouter DNS.
Oct 2 00:03:00 localhost systemd[1]: Reloading FireRouter DNS.
Oct 2 00:07:48 localhost systemd[1]: Reloading FireRouter DNS.
Oct 2 00:07:56 localhost systemd[1]: Reloading FireRouter DNS.
Oct 2 00:12:50 localhost systemd[1]: Reloading FireRouter DNS.
Oct 2 00:13:00 localhost systemd[1]: Reloading FireRouter DNS.
Oct 2 00:17:44 localhost systemd[1]: Reloading FireRouter DNS.
Oct 2 00:17:54 localhost systemd[1]: Reloading FireRouter DNS.
Oct 2 00:18:43 localhost systemd[1]: Reloading FireRouter DNS.
Oct 2 00:22:44 localhost systemd[1]: Reloading FireRouter DNS.
Oct 2 00:22:54 localhost systemd[1]: Reloading FireRouter DNS.
...So, there's a scheduled job telling firewalla to do maintenance and reload/restart things (every 5 mins for me). Would have to ping Firewalla support for more information as to why. I may do just that when I get a chance (feel free to do so as well and report back, if you please), since restarting "FireRouter DNS" twice (with a ~10 second pause?) every 5 minutes doesn't seem very efficient.
-
FWIW - after trying this for a couple weeks and seeing all sorts of odd behavior, I abandoned the idea for now and just did this with a couple Pi's I had laying around:
https://pbxbook.com/other/pstubby.html
It's noticeably faster. I'm surprised how much so.
-
It only shows which Pihole server made the request, but you can still use your main NextDNS profile and assocated rules, etc. To see the per device insight, you have to look at the Pihole server and unless you're using Pihole DHCP (which I'm not) you'll need to custom label known IPs you're interested in seeing. They do have a feature that you can forward name requests to the Firewalla, but Firewalla rejects such request and I've never been able to get this to work.
I'd prefer to use NextDNS on the Firewalla, but after issues for the weeks I was using it, it wasn't worth it. I have also used NextDNS Cli on a couple local machines and get all the features, but thought I'd play with Pihole. I do think it's noticeable faster which I can't image a slightly faster DNS lookup making a difference, but it sure feels like it.
-
@Brian,
I tried modifying my script to first check to make sure firerouter is running before checking nextDNS.
sudo systemctl status firerouter | grep "Active: active (running)"
That hasn't seemed to make any difference. Maybe that isn't the best test. I notice that sometimes I get this which I think means that the sudo nextdns status will fail even though FireRouter is running.
pi@firewalla:/data/logs (Gold) $ sudo systemctl status firerouter
● firerouter.service - FireRouter
Loaded: loaded (/etc/systemd/system/firerouter.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2022-10-06 11:41:40 PDT; 24h ago
Main PID: 29137 (bash)
Tasks: 20 (limit: 4529)
CGroup: /system.slice/firerouter.service
├─29137 /bin/bash -c /home/pi/firerouter/bin/node bin/main.js 2>&1 | tee -a /home/pi/.forever/router.log &>/dev/null
├─29139 /bin/bash /home/pi/firerouter/bin/node bin/main.js
├─29140 tee -a /home/pi/.forever/router.log
├─29620 FireRouter
├─30549 ifplugd -pq -a -i eth0 -f -u 5 -d 5
├─30562 ifplugd -pq -a -i eth1 -f -u 5 -d 5
├─30575 ifplugd -pq -a -i eth2 -f -u 5 -d 5
├─30588 ifplugd -pq -a -i eth3 -f -u 5 -d 5
├─30591 sudo tail -F /var/log/rtw.log
└─30592 tail -F /var/log/rtw.log
Oct 07 12:03:06 firewalla sudo[4446]: pam_unix(sudo:session): session closed for user root
Oct 07 12:03:19 firewalla sudo[5365]: pi : TTY=unknown ; PWD=/home/pi/firerouter/service ; USER=root ; COMMAND=/bin/ping -n -q -m 102 -c 8 -W 3 -i 1 8.8.8.8
Oct 07 12:03:19 firewalla sudo[5365]: pam_unix(sudo:session): session opened for user root by (uid=0)
Oct 07 12:03:19 firewalla sudo[5371]: pi : TTY=unknown ; PWD=/home/pi/firerouter/service ; USER=root ; COMMAND=/bin/ping -n -q -m 102 -c 8 -W 3 -i 1 9.9.9.9
Oct 07 12:03:19 firewalla sudo[5371]: pam_unix(sudo:session): session opened for user root by (uid=0)
Oct 07 12:03:19 firewalla sudo[5374]: pi : TTY=unknown ; PWD=/home/pi/firerouter/service ; USER=root ; COMMAND=/bin/ping -n -q -m 102 -c 8 -W 3 -i 1 1.1.1.1
Oct 07 12:03:19 firewalla sudo[5374]: pam_unix(sudo:session): session opened for user root by (uid=0)
Oct 07 12:03:26 firewalla sudo[5365]: pam_unix(sudo:session): session closed for user root
Oct 07 12:03:26 firewalla sudo[5371]: pam_unix(sudo:session): session closed for user root
Oct 07 12:03:26 firewalla sudo[5374]: pam_unix(sudo:session): session closed for user rootand other times I get:
pi@firewalla:/data (Gold) $ sudo systemctl status firerouter
● firerouter.service - FireRouter
Loaded: loaded (/etc/systemd/system/firerouter.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2022-10-06 11:41:40 PDT; 24h ago
Main PID: 29137 (bash)
Tasks: 35 (limit: 4529)
CGroup: /system.slice/firerouter.service
├─ 8256 /bin/sh -c sudo ping -n -q -m 102 -c 8 -W 3 -i 1 8.8.8.8 | grep "received" | awk '{print $4}'
├─ 8257 sudo ping -n -q -m 102 -c 8 -W 3 -i 1 8.8.8.8
├─ 8258 grep received
├─ 8259 awk {print $4}
├─ 8260 /bin/sh -c sudo ping -n -q -m 102 -c 8 -W 3 -i 1 9.9.9.9 | grep "received" | awk '{print $4}'
├─ 8262 /bin/sh -c sudo ping -n -q -m 102 -c 8 -W 3 -i 1 1.1.1.1 | grep "received" | awk '{print $4}'
├─ 8263 sudo ping -n -q -m 102 -c 8 -W 3 -i 1 9.9.9.9
├─ 8264 grep received
├─ 8265 awk {print $4}
├─ 8266 sudo ping -n -q -m 102 -c 8 -W 3 -i 1 1.1.1.1
├─ 8267 grep received
├─ 8268 awk {print $4}
├─ 8269 ping -n -q -m 102 -c 8 -W 3 -i 1 1.1.1.1
├─ 8270 ping -n -q -m 102 -c 8 -W 3 -i 1 8.8.8.8
├─ 8275 ping -n -q -m 102 -c 8 -W 3 -i 1 9.9.9.9
├─29137 /bin/bash -c /home/pi/firerouter/bin/node bin/main.js 2>&1 | tee -a /home/pi/.forever/router.log &>/dev/null
├─29139 /bin/bash /home/pi/firerouter/bin/node bin/main.js
├─29140 tee -a /home/pi/.forever/router.log
├─29620 FireRouter
├─30549 ifplugd -pq -a -i eth0 -f -u 5 -d 5
├─30562 ifplugd -pq -a -i eth1 -f -u 5 -d 5
├─30575 ifplugd -pq -a -i eth2 -f -u 5 -d 5
├─30588 ifplugd -pq -a -i eth3 -f -u 5 -d 5
├─30591 sudo tail -F /var/log/rtw.log
└─30592 tail -F /var/log/rtw.log
Oct 07 12:32:09 firewalla sudo[7810]: pam_unix(sudo:session): session opened for user root by (uid=0)
Oct 07 12:32:16 firewalla sudo[7804]: pam_unix(sudo:session): session closed for user root
Oct 07 12:32:16 firewalla sudo[7810]: pam_unix(sudo:session): session closed for user root
Oct 07 12:32:16 firewalla sudo[7813]: pam_unix(sudo:session): session closed for user root
Oct 07 12:32:29 firewalla sudo[8266]: pi : TTY=unknown ; PWD=/home/pi/firerouter/service ; USER=root ; COMMAND=/bin/ping -n -q -m 102 -c 8 -W 3 -i 1 1.1.1.1
Oct 07 12:32:29 firewalla sudo[8266]: pam_unix(sudo:session): session opened for user root by (uid=0)
Oct 07 12:32:29 firewalla sudo[8257]: pi : TTY=unknown ; PWD=/home/pi/firerouter/service ; USER=root ; COMMAND=/bin/ping -n -q -m 102 -c 8 -W 3 -i 1 8.8.8.8
Oct 07 12:32:29 firewalla sudo[8257]: pam_unix(sudo:session): session opened for user root by (uid=0)
Oct 07 12:32:29 firewalla sudo[8263]: pi : TTY=unknown ; PWD=/home/pi/firerouter/service ; USER=root ; COMMAND=/bin/ping -n -q -m 102 -c 8 -W 3 -i 1 9.9.9.9
Oct 07 12:32:29 firewalla sudo[8263]: pam_unix(sudo:session): session opened for user root by (uid=0)which seems to allow the sudo nextdns status to succeed.
I suppose I could just trust that nextDNS is running but I don't love that answer.
-
There's so much going on in these things, I couldn't tell you what would be a reliable way to monitor a process status. Maybe add in a sleep/wait routine for a short while on the first detected service failure, then check again to confirm before responding with a "down" message?
In my older age, I find myself leaning more towards the KISS principle. NextDNS has been working 99% reliably (no linux service related issues that I'm aware of), so I just leave it be. If it were to fail/crash/whatever, I'd know pretty quick as the DNS resolve errors would be fairly evident.
Not too long ago I was encountering an issue where my firewalla was becoming unresponsive for a good 10-15 minutes about once a week (basically taking the entire network down with it). Being an intermittent issue, it was annoying to say the least. I finally tracked it down to a corrupted filesystem on the SD card I was using in the firewalla to serve a Unifi controller docker container. Since I only run a handful of APs for wireless access, and while the stats are nice but not necessary, I ditched the whole idea of running the controller on the firewalla. Now I just fire up the Windows version of the controller if/when I need to tweak something on the APs and the firewalla is back to being happy.
-
Just wondering: wouldn't a simple nslookup check on the IP/port that nextdns is listening on be a good health probe?
Since nextdns cli does not seem to be completely stable yet I am still debating:
1) Use the 2 regular ipv4 nextdns servers in LAN dhcp settings (or use FW IP 192.168.1.1 and set nextdns dns on WAN)
2) Use nextdns as DOH in FW, which will reroute all dns lookups to nextdns
3) Set my nas IP in dns settings in LAN dhcp (nextdns cli installed on NAS), bypassing dns in FW completely
Using options 1 and 2 I will loose client specific logging in nextdns, but I hardly ever use it anyway, and I could see fqdn's in Flows on FW. I'm not too worried about having DOH or not. I am currently using option 1 with nextdns on WAN and LAN dhcp dns on the FW IP.
BTW: While on option 3) I shortly noticed a dns issues on my PC a few days ago, but I'm not sure if this was caused by nextdns or an issue my NAS or wifi.
Still if the nextdns cli would run reliably on FW it would be my pereferred option! Like I said it has been working fine on my Syno NAS for almost a year.
-
@JeeHaa
Personally, I would say NextDNS CLI on the Firewalla (Purple in my case) is stable. I've only run into two DNS issues in the past couple months and I couldn't attribute either of those to the service on the Firewalla. By the time I started digging around to diagnose the issue, it was resolved so I didn't proceed further (I suspect one issue was ISP related, and the other seemed to coincide with what seemed like a complete NextDNS service outage but I cannot confirm that). I've never had to touch the NextDNS service on my box since setting it up.
I work from a home office and am online for a minimum of 60+ hours a week. The same Firewalla also provides service for home entertainment (i.e., streaming TV/movies/music) so that's at least an additional 20+ hours a week.
-
@Brian Thanks, I'll see if I can set it up using Michaels script! Just have to wait for a quiet time to prevent the rest of the family from experiencing issues. :)
Does installing Nextdns disable FW DNS Booster and/or related functionality, or is that taken care of by the dnsmasq part (don't see any reference to that in the uninstall script btw)?
-
@Brian
There's so much going on in these things, I couldn't tell you what would be a reliable way to monitor a process status. Maybe add in a sleep/wait routine for a short while on the first detected service failure, then check again to confirm before responding with a "down" message?
There is a lot going on.
First I had a sleep retry in the script followed by a restart nextdns. That was showing a failure at random times but almost always was successful after the restart.
Then I looked through some of Firewalla scripts and thought o.k. ifsudo systemctl status firerouter
reports it is up, good chance I can then test
sudo nexdns status
But that was not reliable either.
but your idea is slightly different. Test, if NOT up wait and then try again. I had immediately restarted nextdns. I'll give it a try and report back.
So far nextdns does seem stable so maybe I'm making things more complicated than it needs to be. -
Looks like my previous post had to be manually approved, so it was probably not visible for others until now.
But nextdns has been running on the Purple for the last 3d, and I have not experienced any issues from a functional perspective so far. :)
Note: I have seen the "nextdns status" command fail on my NAS on several occasions in the past as well, but nextdns was always still resolving at that time. So that command is probably not the most reliable probe.
-
@JeeHaa
The reason I didn't use setup-router is it was causing problems for me. It worked the first few times I was playing with NextDNS CLI, but then it wanted to clobber dnsmasq on port 53 for some reason (from my understanding, setup-router is supposed to move the local DNS client to a different port). No matter what I tried, I couldn't get things working with setup-router after the first few attempts. That's why in my config NextDNS CLI listens on port 5555 and dnsmasq is specifically told to route DNS requests through the NextDNS IP/port.
Since we're manually setting up NextDNS CLI IP/port and reconfiguring dnsmasq, auto-activate isn't necessary.
-
@JeeHaa Thanks. Great feedback. Changes made and update posted.
sudo apt install ca-certificates
This didn't used to be a problem, but I noticed this when I reinstalled recently. Not sure why this is necessary but I don't think it hurts either.
RE: /24 I tried to make this clearer. Short of having a bunch of prompts to have people enter info, some user config is necessary. I tried to make it more "bullet proof". Suggestions welcome.
vi is already installed on Firewalla but I added a note to tell users and fixed the instructions so they don't try to use curl after editing the file.
Unfortunately,
sudo nextdns status
does not play well with Firewalla because they manage their DNS process and restart it randomly. Try as I might I have not found a 100% solid way of knowing if nextdns is running but it does seem to be pretty robust.
Have a great weekend. -
Thanks for the update, I think these changes make it an even better out-of-the-box experience, with client info working! I'm really happy that nextdns seems to be as stable on Purple as it was on my NAS! :)
I am still not entirely sure what the optimal cache-max-age and max-ttl settings would be on this setup (in combination with dnsmasq of FW) , but looking at comparable setup on Ubiquity routers the settings of 0 for nextdns may do the trick.
[Update] Just a fyi: Nextdns has been running 100% stable on my NAS over the last month.
-
Hi so apologies and I feel like a boneheaded but total admitted novice at this, but I’ve tried the install a few ways including Michael’s script “thank you by the way your GitHub is a n00bs paradise. But nextdns runs just fine then I’ll do a port scan after on and see that port 53 is suddenly open….am I doing something wrong?
-
Just a FYI: after having reset my Blue a while ago and having used Nextdns configured in the built-in Firewalla DOH (client name in Nextdns log is always Firewalla), I decided today it was time to revisit the script and install the NextDns Cli to profit from client names in the Nextdns logging again.
I downloaded the script, added the Nextdns Id + FW IP and it worked flawlessly. :)
Will be keeping an eye on stability for the next few days...[Update] After 9 days still no issues at all.
[Update 2] One more week later and I just noticed that my PC (configured to use the FW IP as dns from dhcp as expected) somehow was using Cloudflare (configured on the WAN interface) instead of Nextdns according to test.nextdns.io, and I have no clue why. nextdns status was running, and I saw the cache entries increasing from other clinets. I decided to disable the Nextdns service on FW for now, and just configure the Ipv4 nextdns servers on WAN (so no client names in the Nextdns log any more, but no hassle).
-
Randomly I stop getting client names in the NextDNS cloud logs. A restart of the FW NextDNS service does the trick to reset it. Is there a safe way to do an auto restart, like once a day at midnight? I figure the monitoring piece is still not reliable, so a quick daily restart might head off issues?
-
Hey guys, I have a question regarding using the script provided by Michael Bierman and assigning specific devices on the network with different NextDNS profiles. I noticed the following in the documentation:
Note you can set up different devices using different NextDNS configurations including VPN connections. For example, I have Apple TVs in a different nextDNS configration so I can tune them. Simply add a line like this:
-config macaddress=nextdnsconfiguration ID \
I'm confused on where to add -config macaddress=nextdnsconfiguration ID \. I've already added my LAN IP and main NextDNS ID which has been working fine, but how do I add these additional mac address associated configs? If someone could write out an example, that would be awesome. Thanks!
-
Hi All!
I have been using this NextDNS CLI setup for years, it has been perfect!
Until today... my box updated itself to 1.979 and now it's not working as intended. It works. But every request shows as coming from my "Fallback" profile.I have 4 different networks, my install command looks something like:
sudo nextdns install -config 10.0.101.1/24=aaaaaa -config 10.0.102.1/24=bbbbbb -config 10.0.100.1/24=cccccc -config ffffff -report-client-info -cache-size=10MB -max-ttl=5s -discovery-dns 10.99.0.1 -listen 10.99.0.1:5555
Yet, now everything shows as my fallback profile and only from my Discovery IP.
No client information or recognition is working. I have done some basic testing and troubleshooting, NextDNS is running without errors, config command looks right.
Anyone else with issues? It feels like the new box version has broken something. Likely with the new VLAN flow detection incoming, maybe.Thank you for any help!
-
@Raymond,
I have some partial success. With the following I can get the IP of the devcie to the nextDNS logs. Note "config" has changed to "profile"
sudo nextdns install \
-profile=fff \
-hardened-privacy=false \
-use-hosts=false \
-log-queries=true \
-bogus-priv=false \
-report-client-info=true \
-discovery-dns $IP \
-cache-size=10MB \
-max-ttl=5s \
-listen $IP:5555It seems that the discovery DNS IP and listen IP work equally if they are 127.0.0.1 or or the LAN IP of the firewalla.
I am trying to get some help from nextDNS but as usual, they are largely unresponsive. I don't know why the device name is not going upstream. -
@Michael,
Thank you very much for your replies, you have set me on a path to improvement.
The following commands have me operational again. BUT, I am also still seeing "Device #2DDAA" which is quite annoying, as something has clearly changed from Firewalla OS point of view. The change from listening/discovery IP of one of my LAN IPs to localhost IP resolved most issues, so definitely looks like some default intra-VLAN security coming from Firewalla, as no settings have been changed from me, just a reboot and upgrade broke it.EDIT: The only device name that DOES appear in the logs is "Firewalla" and if you do a:
cat /etc/hosts
The only reply is:
127.0.0.1 localhost Firewalla
Which seems too much of a coincidence to not be linked. But this is outcome is the same whether "use-hosts" is set to true or false and with "discovery-ip" set to a LAN IP, localhost IP or unset.
sudo nextdns install \
-profile 10.0.101.0/24=AAAAAA \
-profile 10.0.102.0/24=BBBBBB \
-profile 10.0.100.0/24=CCCCCC \
-profile DDDDDD \
-report-client-info=true \
-log-queries=true \
-cache-size=10MB \
-max-ttl=5s \
-discovery-dns 127.0.0.1 \
-listen 127.0.0.1:5555
cat > /home/pi/.firewalla/config/dnsmasq/mynextdns.conf << EOF
server=127.0.0.1#5555
add-mac
add-subnet=32,128
EOF -
Yes, all correct Raymond. I'm not sure if it is something Firewalla did or nextDNS. Their github repo seemed to have recently changed some stuff around dnsmasq. The device name was surely nice. Having the IP is something but I'm not as happy.
I don't think /etc/hosts was ever an issue. Dnsmasq is where the hostinfo came from. I'm not sure why it isn't picked up anymore.
Please sign in to leave a comment.
Comments
70 comments