Google Linux Networking

NextDNS + EdgeRouter + Redirecting DNS requests

Realised I haven’t updated this in a long while (life happened).

Couple of weeks ago I started to play with NextDNS — and I really recommend anyone that’s something privacy minded and cares about the stuff happening on their network.

I’ve set up several configs (home, parents, FlatTurtle TurtleBox (the NUCs controlling the screens)) and Servers. Once it’s out of beta and better supported on Unifi and Ubiquiti hardware I might deploy it to our public WiFi (well, most access points don’t look like that — but you get the point) networks too.

Looking at the logs was an eye-opener seeing what goes through your network. You can play around and block (or whitelist) certain domains.

I figured out my Devialet does an insane amount of requests to for example. This domain has a 30s TTL. It shows that the majority of my DNS requests are actually automated pings and not in any way human traffic.

Anyhow — I’ve since installed the NextDNS CLI straight on my EdgeRouter Lite acting as a caching DNS server and forwarding using DoH.

I’ve turned off dnsmasq (/etc/default/dnsmasq => DNSMASQ_OPTS="-p0") and have NextDNS listen to :53 directly.

Note that every EdgeOS update seems to wipe out the NextDNS installation, and requires a fresh install… Pain in the ass and doesn’t seem like that’s fixable.

This is my ERL NextDNS config (/etc/nextdns.conf)

hardened-privacy false
bogus-priv true
log-queries false
cache-size 10MB
cache-max-age 0s
report-client-info true
timeout 5s
listen :53
use-hosts true
setup-router false
auto-activate true
config 34xyz8
detect-captive-portals false
max-ttl 0s

The explanation of every flag is explain on their Github page and they are very responsive via issues or through their chat on

All right — next thing I’ve noticed is that my Google Home devices are not sending any DNS requests — which means the devices use hard coded DNS servers.

I have a separate vlan (eth1.90) for Google Home (includes my Android TV, OSMC, Nest Home Hub and all other GHome and Chromecast devices). For this vlan I set up a deflector to be able to cast and ping/ssh from my “main” network/vlan to GHome vlan.

Using this guide I redirected all external DNS traffic to the ERL so I can monitor what’s happening. The important part was the following:

[email protected]# show service nat rule 4053
destination {
port 53
inbound-interface eth1.90
inside-address {
port 53
protocol tcp_udp
type destination

This allows to “catch” all UDP and TCP connections to :53 and redirect them the ERL DNS server ( The GHome devices were acting a bit weird after committing the change, but a reboot of the device fixed it.

Note that you need to set this up per vlan. If you want to catch DNS requests for your Guest or IoT vlan, you’ll need to do the same.

Errors Hardware Linux Software VM

Wheezy Xen Dom0 & RAM

Note to self: <1Gb of RAM on a Dom0 Wheezy server causes kernel panics.

Using 2Gb of RAM seems to do the trick.

Errors Hardware Linux

Realtek ethernet card not working on Linux

[ 0.184110] pci 0000:04:04.0: [10ec:8139] type 0 class 0x000200
[ 3.822258] 8139cp: 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
[ 3.822281] 8139cp 0000:04:04.0: This (id 10ec:8139 rev 10) is not an 8139C+ compatible chip, use 8139too
[ 3.822574] 8139too: 8139too Fast Ethernet driver 0.9.28
[ 3.822625] 8139too 0000:04:04.0: Chip not responding, ignoring board
[ 3.822675] 8139too: probe of 0000:04:04.0 failed with error -5

On a Debian machine.

The solution was changing PCI slot , blowing away all the dust in the mobo PCI slot and on the pins of the PCI card, and gently inserting and removing it a couple of times.

After that it worked correctly.

Errors Linux Networking Software

First 5 Minutes Troubleshooting A Server


Hardware Linux Networking Software

Connect different LANs over openVPN

I now own three Raspberry Pi’s.

Using two of them (and my Guruplug as WiFi AP) I connected my new apartment with my old house (= parents) over VPN.

This way I can access the printers/scanners and NAS at home.

The 2 rPI’s are used as router (using a Macbook Air USB-to-Ethernet adapter as 2nd ethernet (eth1) port). Basic howto’s are easily found using Google to do this (a good starting point).

I made my own installation of Raspbian (as the downloadable image contains too much crap), details here (actually not that easy to find when Googling for bootstrap raspbian etc).


I’ve connected three different LANs over an OpenVPN connection:

  • LAN1 (home): (Gateway:, VPN ip:
  • LAN2 (apartment, ethernet): (Gateway:, VPN ip:
  • LAN3 (apartment, wifi): (Gateway:, VPN ip:

OpenVPN range: The subnet is in all cases.

LAN3 is connected via LAN2 to the internet. So the default gateway of router is

The gateway/routers are all Debian-based Linux systems. I’m using EDPnet as ISP, and thus need to use those Sagem/Belgacom approved routers (BBox-2 hardware). These Sagems are set in bridged mode, and don’t do the PPP stuff. PPPoeconfig on Debian takes care of most of the stuff. As EDPnet provides ipv6, I can ping6 from those routers.

The idea is to connect/ping each and every LAN from any of the clients connected the LANs (without running OpenVPN on the clients; only run it on the gateways).

For example: my PC with ip wants to connect to the NAS with ip

This can easily be achieved by setting a client-config-dir in the openvpn.conf file (or whatever the name of your config):

client-config-dir /etc/openvpn/tiete

And don’t forget to add route pushes:

push "route"
push "route"
push "route"

But here comes the annoying part. As I’m pushing routes via VPN, which is supposed to be my Guruplug’s default gateway as well (ISP > eth0:RaspberryPi:eth1 > eth0:Guruplug, remember?) this was causing quite some routing fuck ups.

The easiest way to solve this was to turn off VPN on the Guruplug all together, and route over the Raspberry Pi, by adding this line to /etc/network/interfaces:

up route add -net netmask gw dev eth1

Then I’ll change the client specific configs on the VPN. Create a file in whatever you picked as client-config-dir, and name it the actual VPN name (the name used when creating the key).

As I have three routers, I created three files (sheeva for my guruplug, Pi for my first rPI and Industry for my 2nd. Yep… Fancy names).

I also want to give a static IP address to the gateways, so I use the option:

ifconfig-push 10.9.8.<valid-ip> 10.9.8.<valid-ip - 1>

And I’ll also add the iroute option to push routes.

This is what it looks like for the router on the network (“Pi”):


For “Sheeva”, the WiFi AP on


And for plus routed over (“Industry”):


And don’t forget to set up masquerading over tun0 (or tun+) with iptables.

Now… Oddly enough, this didn’t require that much configuration, cursing and stress… And, well, it kind of just works.

From my Mac to my NAS:

nazgul ~ $ traceroute
traceroute to (, 64 hops max, 52 byte packets
 1 sheeva ( 1.936 ms 1.159 ms 0.800 ms
 2 ( 1.456 ms 1.776 ms 1.539 ms
 3 ( 55.745 ms 55.046 ms 54.734 ms
 4 ( 62.302 ms 55.327 ms 54.795 ms

From Pi (gateway to nazgul, my Mac:

pi ~ # traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 ( 65.892 ms 74.177 ms 73.957 ms
 2 ( 73.441 ms 72.902 ms 72.342 ms
 3 ( 71.780 ms 71.187 ms 70.760 ms

From Heartbeat (, my Munin stats server to the printer:

heartbeat ~/bin # traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 pi ( 39.835 ms 40.794 ms 41.567 ms
 2 ( 41.541 ms 42.452 ms 43.307 ms

From Heartbeat to Sheeva’s eth0 IP:

heartbeat ~/bin # traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 industry ( 32.716 ms 32.615 ms 34.359 ms
 2 sheeva ( 34.405 ms 34.349 ms 35.014 ms

From Heartbeat to an Android device (not sure why the latency spike):

heartbeat ~/bin # traceroute
traceroute to (, 30 hops max, 60 byte packets
 1 industry ( 31.337 ms 32.269 ms 32.218 ms
 2 sheeva ( 33.006 ms 33.052 ms 32.996 ms
 3 ( 471.564 ms 472.169 ms 473.082 ms

Next up (once I have spare time): try to sync local DNS and fix local ipv6.

I’ll put most of the configs on Github at some point.