Yet another thread on issues w/ local DNS forwarding

Installing and Using OpenWrt Network and Wireless Configuration
1

I am using an rpi 4 with Openwrt as a routed wireless access point, as per this tutorial.

Everything works just fine.

Recently, I have altered my DNS settings to running a local Unbound DNS on my OPNSense firewall at internal IP 10.0.0.254. I have 3 devices, where 'n' in the wireless interface address below is either 10, 20, or 30. All other devices i.e. workstations etc within the internal VLAN networks can access the 10.0.0.254 unbound address. There are no ingress or egress rules on my switch ports, they have been removed for testing this problem.

The network is as follows:

local device -> (wifi) -> 192.168.n.1 -> 10.0.40.0/24 -> (static route on switch to firewall) -> 10.0.0.254

I cannot get DNS on the wireless interfaces, regardless of how I set the forwarding or whether the DNS address on the device is the wireless interface itself (192.168.n.1) or the unbound instance on the firewall (10.0.0.254), or the VLAN inteface on the firewall (10.0.40.1). DNS does work when setting to 8.8.8.8 on the device.

I have tried dhcp option 6, DNS forwarding, Port Forwarding on the firewall. Nothing works.

Is there a way to forward DNS queries from the wireless interface to the internal VLAN? Do I need to set the DNS address on the device to the wireless interface or the internal 10.0.0.254 interface?

Here are my firewall settings for all devices, is there some kind of issue with port forwarding across networks? I have tried all combinations of network routing, including changing the firewall routing away from the VLAN and forwarding to the 10.0.0.254 interface.

This is my usual firewall routing:

openwrt
openwrt1048Ă—256 30.7 KB

The following post replies show an example of using the 10.0.0.254 interface. In my normal configuration, the "Interfaces" do not change only difference is the firewall route from the wlan0 to vlan40dhcp instead of wlan0 to lan.

2

openwrt2
openwrt21091Ă—647 87.4 KB

3

openwrt3
openwrt31075Ă—443 37.8 KB

4

openwrt4
openwrt41076Ă—204 20.5 KB

5

I have now also tried adding custom rules as follows:

# DNSHIJACKv4
# Log and redirect DNS Traffic
iptables -t nat -N dnshijack
iptables -t nat -I dnshijack -j LOG --log-prefix "dnshijack4 "
iptables -t nat -A dnshijack -j DNAT --to-destination 10.0.0.254
# anything else is hijacked
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -j dnshijack
# fix "reply from unexpected source"
iptables -t nat -A postrouting_lan_rule -d 10.0.0.254 -p tcp -m tcp --dport 53 -m comment --comment "!fw3: DNS Pi-hole MASQUERADE" -j MASQUERADE
iptables -t nat -A postrouting_lan_rule -d 10.0.0.254 -p udp -m udp --dport 53 -m comment --comment "!fw3: DNS Pi-hole MASQUERADE" -j MASQUERADE
6

Have also tried extended ruleset:

# DNSHIJACKv4
# Log and hijack to Pihole
iptables -t nat -N dnshijack
iptables -t nat -I dnshijack -j LOG --log-prefix "dnshijack4 "
iptables -t nat -A dnshijack -j DNAT --to-destination 10.0.0.254
# allow Pihole to query internet
iptables -t nat -A prerouting_lan_rule -m mac --mac-source 00:11:22:33:44:55 -p udp --dport 53 -j ACCEPT
iptables -t nat -A prerouting_lan_rule -m mac --mac-source 00:11:22:33:44:55 -p tcp --dport 53 -j ACCEPT
# allow queries to OpenWrt
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -d 10.0.2.1 -j ACCEPT
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -d 10.0.2.1 -j ACCEPT
# anything else is hijacked
iptables -t nat -A prerouting_lan_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_lan_rule -p tcp --dport 53 -j dnshijack
# other zones
iptables -t nat -A prerouting_guest_rule -p tcp --dport 53 -d 10.0.0.254 -j ACCEPT
iptables -t nat -A prerouting_guest_rule -p udp --dport 53 -d 10.0.0.254 -j ACCEPT
iptables -t nat -A prerouting_guest_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_guest_rule -p tcp --dport 53 -j dnshijack
iptables -t nat -A prerouting_iot_rule -p tcp --dport 53 -d 10.0.0.254 -j ACCEPT
iptables -t nat -A prerouting_iot_rule -p udp --dport 53 -d 10.0.0.254 -j ACCEPT
iptables -t nat -A prerouting_iot_rule -p udp --dport 53 -j dnshijack
iptables -t nat -A prerouting_iot_rule -p tcp --dport 53 -j dnshijack
# fix "reply from unexpected source"
iptables -t nat -A postrouting_lan_rule -d 10.0.0.254 -p tcp -m tcp --dport 53 -m comment --comment "!fw3: DNS Pi-hole MASQUERADE" -j MASQUERADE
iptables -t nat -A postrouting_lan_rule -d 10.0.0.254 -p udp -m udp --dport 53 -m comment --comment "!fw3: DNS Pi-hole MASQUERADE" -j MASQUERADE

And also adding DNS Forwardings and Checking to ignore resolve file

7

Finally, I have tried using custom DNS servers which also does not work. I'm quite confident that I have now tried all possible combinations of solutions to this issue.

Any thoughts appreciated.

openwrt5
openwrt5878Ă—129 7.4 KB

NOTE: If I simply set option 6 with 8.8.8.8 then DNS works. However, that is obviously not a solution.

8

Do you have any hardware doing anything in that arrow because those addresses suggest that they are on two different gateways and that won’t work.

Your pictures doesn’t really say much, you need to past the firewall and network config files.

9

So that arrow is the firewall rule from the wireless interface to the wired interface on the pi i.e. from "guest" to "vlan40dhcp" in the second post on this thread, the firewall rule itself is illustrated in the OP.

Sure, which config files should I share?

10

I recommend at least the systems you have screenshot on but the question is connected to these system config files: wireless, network, dhcp and firewall.

11

This is all one device. It's a raspberry pi setup as a routed access point. Going from wireless to wired. All of the instructions are in the link to that tutorial. Here it is again

I don't know anything about these config files, so you'll need to be more specific.

The alternative is to setup the pi as a bridged access point which will mean the wireless interface and wired are on the same network. However, this doesn't seem necessary given that 8.8.8.8 is still reachable. I find it highly doubtful that the DNS server needs to be on the same exact network segment for this to work.

12

Ok so a revelation this morning: I was unable to ping 10.0.0.254 from the rpi sitting on 10.0/24 VLAN. I had accidentally removed VLAN1 as "untagged" on that port. Reinstating VLAN as untagged on the rpi wired port meant I could ping 10.0.0.254, of course.

Then I still couldn't ping 10.0.0.254 from my mobile device sitting on the wireless interface, this was until I changed my openwrt firewall rules to route from wlan0 to lan which is a 10.0.0.0/24 untagged subnet. However, even with this set I still cannot get DNS resolution from 10.0.0.254 despite being able to ping directly from my mobile device.

So, I think the issue is something to do with NAT'ing on the rpi from 192.168.1.0/24 on the wireless interface, to 40.0/24 on the wired interface. This would make sense as I have setup the pi in this fashion.

It appears my options are as follows:

  1. Change the config of the rpi to a BRIDGED access point, as opposed to a ROUTED access point. Then setup a resolver on the 40.0/24 VLAN and reference that in my DNS options on my mobile device. Undesirable, as I do not want an internal VLAN exposed no matter how isolated. Regardless, I think this is my only option.

  2. Apply the DNAT rules I found above and fiddle with that to handle DNS packets across 192.168 and 40.0/24

13

It sound familiar…

1 Like
14

10.0.0.254 is directly accessible through the lan interface (10.0.0.232). Set 10.0.0.254 as a custom DNS server on that interface, not on VLAN40.

Go to Network>DHCP and DNS>General Settings and set 10.0.0.254 as an upstream DNS server (this should not be necessary, but better set it up).

image

Remove all other DNS settings (if any).

Yes. The wireless devices should use 192.168.n.1 as a DNS server. Their DNS requests will be forwarded by the router to 10.0.0.254 and your problem will be solved without additional routing or port forwarding.

1 Like
15

Thanks for that! Will this work if I am routing wireless traffic through to VLAN40?

There is a static route that takes all VLANs on the switch through to 10.0.0.254.

EDIT: the answer is yes, this works now. Will do a write up at some point.