AR-750S Router Not Applying Firewall Rules


I am attempting to set-up my AR-750S (with firmware v.3.101) to block calls to Google’s DNS servers when using a SmartDNS service with my Chromecast. The box works fine with services that don’t use Google’s DNS servers, so the DNS Settings I applied are otherwise normally inherited.

Using the Advanced view I’ve tried a few approaches, but only Static Routing seems to ‘do’ anything (e.g I was able to configure Static Routing to re-direct all calls to to the router’s IP). This however didn’t seem to stop apps streaming via the Chromecast to geoblock me.

So I then went and tried to set-up Traffic Rules via the Firewall. I added in two entries:

IPv4-traffic - From any host in lan - To IP in wan - Refuse forward
IPv4-traffic - From any host in lan - To IP in wan - Refuse forward

I also then removed the Static Routing, however I quickly realised it was never applying these rules (even when restarting firewall and even when rebooting), as I could still ping these IPs and a trace route leads it back to Google’s DNS servers.

I then lastly tried appending the following to the end of Custom Rules:

iptables -t nat -A PREROUTING -d -j DNAT --to-destination Router IP
iptables -t nat -A PREROUTING -d -j DNAT --to-destination Router IP

But once again, this seemed to have no effect (e.g. ping’s still worked, etc).

The following settings have been enabled via normal interface in Custom DNS Server settings:

  • DNS Rebinding Attack Protection
  • Override DNS Settings for All Clients
  • Manual DNS Server Settings
    (+ DNS Server 1/2 listed below it)

Strangely when I run iptables -list via SSH it includes the following:

Chain zone_lan_forward (1 references)
target     prot opt source               destination         
forwarding_lan_rule  all  --  anywhere             anywhere             /* !fw3: Custom lan forwarding rule chain */
zone_wan_dest_REJECT  tcp  --  anywhere                 /* !fw3: DNS */
zone_wan_dest_REJECT  udp  --  anywhere              /* !fw3: DNS */
zone_wan_dest_REJECT  tcp  --  anywhere              /* !fw3: DNS 2 */
zone_wan_dest_REJECT  udp  --  anywhere              /* !fw3: DNS 2 */
zone_wan_dest_ACCEPT  all  --  anywhere             anywhere             /* !fw3: Zone lan to wan forwarding policy */
ACCEPT     all  --  anywhere             anywhere             ctstate DNAT /* !fw3: Accept port forwards */
zone_lan_dest_ACCEPT  all  --  anywhere             anywhere             /* !fw3 */

But in spite of this I can still ping…

Can someone please help as I’ve thrown everything I can find at it, but can’t get it to do something that was easier for me to set-up on DD-WRT previously by comparison (this is my first OpenWRT router).


You can ping but what about a DNS request? Did you try experimenting with dig command from a client on your network or doing a DNS trace specifically?

I am using Chromecast too and have simply trusted the Override DNS setting for now and have not yet tested to see if it works.

If the Override DNSis functioning, I would still expect that you would be able to ping and only that DNS requests (on Port 53 and 853) should be intercepted by the router.

EDIT: just to add, since Google has launched their encrypted public DNS we might expect that Chromecast are to start using them too eventually. Hopefully gl.inet is aware of this and are already or are soon to include blocking port 443 to encrypted public DNS services with the Override setting.

It is possible to block 443 for dns but if Google enforce this in Chromecast, you may just kill the Chromecast’s Internet by doing this.

Thanks very much for the tip.

The following command seems to indicate that the router is catching these calls:
dig @ +trace +question A

When ran it then returned as follows:
; <<>> DiG 9.10.6 <<>> @ +trace +question A
; (1 server found)
;; global options: +cmd
;. IN NS
;; Received 17 bytes from in 36 ms

Also enabled dns-strict via Advanced UI… Which I know can help.

…Which now makes me think its the lack of blocking port 443 which is my new issue with my Chromecast.

1 Like

Where and is blocked, then Google falls back to the network’s default DNS servers typically, so i’d be surprised if the use of the port 443 doesn’t have a fallback where that’s blocked.

1 Like