I wanted AdGuard Home on every device in my home without configuring each phone, TV, laptop, and IoT device separately. I already had everything I needed:
- An Airtel connection with a Nokia G-2425G-A router
- A Raspberry Pi 3B+
- An old Huawei EchoLife HG8145V
- One Ethernet cable
- AdGuard Home installed on the Raspberry Pi
The plan looked simple:
Internet
↓
Airtel Router
↓
Raspberry Pi running AdGuard Home
↓
Every device gets filtered DNS
It was not. Airtel had locked the DNS settings, the Huawei router could not use Ethernet as WAN, Windows had left a misleading static address on my laptop, and several layouts provided internet without sending a single DNS query through AdGuard.
The setup finally worked when I stopped treating the Pi as only a DNS server and made it the router for a separate filtered network.
Airtel blocked custom DNS
My first setup was straightforward:
Airtel Router: 192.168.1.1
Raspberry Pi: 192.168.1.7
AdGuard Home DNS: 192.168.1.7
AdGuard Home was running. I only needed Airtel’s DHCP server to announce the Pi as DNS. The router showed the DNS fields, but saving them returned:
The normal user do not have permission to do this!
Its DHCP controls were also restricted. Devices continued receiving Airtel’s DNS, while AdGuard sat idle:
Phone / TV / Laptop
↓
Airtel DHCP and DNS
↓
Internet
Raspberry Pi with AdGuard
↓
Sitting on the network, but receiving no DNS queries
Installing a DNS server does not redirect anything by itself. Clients must receive it through DHCP, use it manually, or have their DNS traffic redirected to it.
First try: use Huawei as an access point
Because Airtel’s router was locked, I connected an old Huawei EchoLife HG8145V behind it:
Airtel LAN1
↓
Huawei LAN4
Huawei LAN1
↓
Raspberry Pi
Both routers initially had the same management address:
Airtel: 192.168.1.1
Huawei: 192.168.1.1
That created an IP conflict. Sometimes Airtel opened, sometimes Huawei opened, and sometimes neither behaved consistently. Both devices could answer the same ARP request, so the laptop could cache either router’s MAC address.
I changed Huawei to:
Huawei: 192.168.1.2
The Pi eventually received:
Raspberry Pi: 192.168.1.4
With Huawei DHCP disabled, it worked as an access point and Ethernet switch. Its Wi-Fi had internet, but AdGuard still received no queries because Huawei was only bridging Airtel’s network:
Phone
↓
Huawei Wi-Fi
↓
Airtel DHCP and DNS
↓
Internet
The Pi was connected to the same switch, not placed in the traffic path. For automatic filtering, it needed to be one of these:
- The DHCP server
- The DNS server announced by DHCP
- The gateway/router through which clients accessed the internet
- A firewall redirecting DNS requests
This layout provided none of them.
Second try: use Huawei as a router
Huawei’s WAN page looked promising. It showed:
IPoE
Route WAN
DHCP
NAT
Binding Options
LAN1
LAN2
LAN3
LAN4
SSID1
I thought LAN4 could become the upstream connection:
Airtel LAN1 → Huawei LAN4 as WAN
Huawei LAN1 → Raspberry Pi
Huawei Wi-Fi → Phones and TVs
That would have separated both sides:
WAN network: 192.168.1.x
LAN network: 192.168.2.x
But the Huawei was a GPON ONT. Its WAN profiles belonged to the fibre interface. “Binding Options” only selected which LAN ports or SSIDs could use a GPON service; it did not convert LAN4 into Ethernet WAN. Stock firmware made this route a dead end.
The cable that looked broken
During this testing, my laptop could not open Huawei over Ethernet. The adapter showed:
IPv4 Address: 192.168.137.1
DHCP Enabled: No
That address came from an old Windows Internet Connection Sharing or Mobile Hotspot configuration. The cable was fine; Windows had left a static address behind.
The fix was:
- Open
ncpa.cpl - Right-click Ethernet
- Open IPv4 properties
- Select “Obtain an IP address automatically”
- Select “Obtain DNS server address automatically”
- Disable and re-enable the adapter
Once Ethernet returned to DHCP mode, Huawei opened normally. This saved me from blaming a perfectly usable cable.
The network that worked
Airtel would not announce custom DNS, and Huawei could not become an Ethernet router. So I made the Raspberry Pi the router:
Airtel Wi-Fi
↓
Raspberry Pi wlan0
↓
Raspberry Pi routing, NAT, DHCP and AdGuard Home
↓
Raspberry Pi eth0
↓
Huawei LAN1
↓
Huawei Wi-Fi
↓
Phones, TVs and other devices
There is no cable between Airtel and Huawei. The only Ethernet connection is:
Raspberry Pi eth0 → Huawei LAN1
The Pi receives internet over Wi-Fi and sends filtered internet to Huawei over Ethernet. I used this IP plan:
Airtel router: 192.168.1.1
Pi wlan0: 192.168.1.2
Huawei management: 192.168.2.1
Pi eth0: 192.168.2.4
Huawei clients: 192.168.2.100–192.168.2.200
Client gateway: 192.168.2.4
Client DNS: 192.168.2.4
The Pi’s interfaces must be on different subnets:
wlan0: 192.168.1.0/24
eth0: 192.168.2.0/24
Putting both interfaces on the same subnet would break reliable routing.
Configure the Raspberry Pi as a router
Give Ethernet a static address
I created a NetworkManager profile for eth0:
sudo nmcli con add type ethernet \
ifname eth0 \
con-name huawei-lan \
ipv4.method manual \
ipv4.addresses 192.168.2.4/24 \
ipv4.never-default yes \
ipv6.method disabled
Then activated it:
sudo nmcli con up huawei-lan
Verification:
ip -br address show eth0
Expected result:
eth0 UP 192.168.2.4/24
ipv4.never-default yes is important because wlan0 must remain the Pi’s internet route.
Enable forwarding and NAT
I enabled IPv4 forwarding:
sudo sysctl -w net.ipv4.ip_forward=1
iptables was not installed on this Raspberry Pi OS setup, so I installed it:
sudo apt update
sudo apt install -y iptables
I added NAT for the Huawei subnet:
sudo iptables -t nat -A POSTROUTING \
-s 192.168.2.0/24 \
-o wlan0 \
-j MASQUERADE
Allowed forwarding towards Airtel:
sudo iptables -A FORWARD \
-i eth0 \
-o wlan0 \
-j ACCEPT
And allowed established return traffic:
sudo iptables -A FORWARD \
-i wlan0 \
-o eth0 \
-m conntrack \
--ctstate ESTABLISHED,RELATED \
-j ACCEPT
I checked the rules and counters with:
sudo iptables -t nat -L POSTROUTING -n -v
sudo iptables -L FORWARD -n -v
Zero counters initially were normal. They increased only after a Huawei client started using the Pi as its gateway.
Make routing survive reboot
Temporary forwarding and firewall rules disappear after reboot. I made forwarding permanent:
echo 'net.ipv4.ip_forward=1' | \
sudo tee /etc/sysctl.d/99-router.conf
sudo sysctl --system
Installed firewall persistence:
sudo apt install -y iptables-persistent
Saved the rules:
sudo netfilter-persistent save
Enabled automatic reconnection for Ethernet:
sudo nmcli connection modify \
huawei-lan \
connection.autoconnect yes
And enabled AdGuard Home at boot:
sudo systemctl enable AdGuardHome
Configure AdGuard Home and DHCP
AdGuard needed to listen on eth0, not only on Airtel Wi-Fi. I checked port 53:
sudo ss -lntup | grep ':53 '
It was listening on:
*:53
That covered both Pi addresses:
192.168.1.2
192.168.2.4
No DNS binding change was required.
Huawei DHCP was disabled, leaving it as a switch and access point:
Management IP: 192.168.2.1
DHCP: Disabled
Role: Wi-Fi access point and Ethernet switch
I configured AdGuard Home DHCP on eth0:
Interface: eth0
Gateway: 192.168.2.4
Subnet mask: 255.255.255.0
Range start: 192.168.2.100
Range end: 192.168.2.200
Lease duration: 86400 seconds
The gateway must be 192.168.2.4, not Huawei’s 192.168.2.1, because the Pi is now the router. AdGuard automatically supplies itself as DNS:
DNS: 192.168.2.4
AdGuard did not recognise the static IP
AdGuard Home initially refused to enable DHCP because it did not recognise the NetworkManager address as static. I kept the working NetworkManager setup, backed up AdGuardHome.yaml, and updated its existing dhcp: section with these values:
DHCP enabled: true
Interface: eth0
Gateway: 192.168.2.4
Subnet: 255.255.255.0
Range start: 192.168.2.100
Range end: 192.168.2.200
Lease time: 86400
After restarting AdGuard Home, I checked UDP port 67 to confirm its DHCP server was active.
Test the filtered network
I forgot the Huawei Wi-Fi network on Android and reconnected so the phone would request a fresh lease. It received:
IP address: 192.168.2.100–192.168.2.200
Gateway: 192.168.2.4
DNS: 192.168.2.4
The working path was:
Android phone
↓
Huawei Wi-Fi
↓
Pi eth0
↓
AdGuard Home DNS filtering
↓
Pi NAT and routing
↓
Pi wlan0
↓
Airtel router
↓
Internet
Queries appeared in AdGuard Home’s log, and the test result was:
130 out of 135 blocked
96% blocked
AdGuard’s website still said “AdGuard for Android” and “AdGuard DNS” were not running. That was expected: it was checking its Android app and public DNS service, while I was using self-hosted AdGuard Home.
The reliable checks were:
- DNS queries appearing in AdGuard Home’s Query Log
- Blocked entries appearing in the log
- The phone receiving
192.168.2.4as DNS - High scores on independent ad-block test pages
- Firewall packet counters increasing
What it blocks—and what it does not
The setup can block:
- Website advertising domains
- Tracking pixels
- Analytics services
- Telemetry endpoints
- Malicious domains
- Some smart-TV advertising
- Some in-app advertising
- Known phishing and malware domains
This is useful for TVs, set-top boxes, and IoT devices where browser extensions are not an option.
It cannot reliably remove YouTube ads inside the official app. YouTube often serves ads and videos through overlapping infrastructure, so blocking the domain may break the video too.
The realistic options are:
- YouTube Premium
- Watching through a browser with a capable content-blocking extension
- A specialised client, where legally and operationally appropriate
That limitation does not mean the Pi setup failed; it is a limit of DNS-level filtering.
Final network diagram
INTERNET
│
Airtel Nokia Router
192.168.1.1
│
Wi-Fi
│
Raspberry Pi wlan0
192.168.1.2
│
NAT + Routing + AdGuard
│
Raspberry Pi eth0
192.168.2.4
│
Ethernet cable
│
Huawei LAN1 / Wi-Fi
192.168.2.1
│
┌─────────────┼─────────────┐
│ │ │
Phone TV Laptop
192.168.2.x 192.168.2.x 192.168.2.x
Gateway for clients: 192.168.2.4
DNS for clients: 192.168.2.4
What I learned
Internet access alone does not prove that traffic is following the route I intended. Huawei Wi-Fi had internet while it was only bridging Airtel, but AdGuard was not involved.
The practical lessons were:
- A DNS server does nothing until clients are instructed to use it.
- An access point does not automatically become a router.
- WAN profile binding is not the same as selecting an Ethernet WAN port.
- Two routers must not use the same management IP on the same network.
- Windows ICS can leave behind
192.168.137.1and make a good Ethernet cable look faulty. - Router and downstream networks should use different subnets.
- DHCP must announce both the correct DNS server and the correct gateway.
- Temporary Linux routing rules must be made persistent before rebooting.
- Query logs and packet counters are more trustworthy than whether a webpage happens to load.
- DNS-level blockers are powerful, but they cannot distinguish every first-party advertisement from content.
The Pi now does four jobs:
Internet receiver
Router
DHCP server
AdGuard Home DNS filter
Huawei only provides:
Ethernet switch
Wi-Fi access point
This gave me a separate filtered network without unlocking or modifying Airtel’s router. The final setup used hardware I already had; the difficult part was understanding which device was actually routing, serving DHCP, and handling DNS.