Wireguard setup: Mullvad Client + Server for Android

Adblock is installed as open-wrt plugin (adblock 3.5.5-3) via lucid. Pihole runs independently on a pi with a fixed ip. So this is why i like the pihole, I know where it is. The adblocker inside the router works with routing, a thing, how you saw, which is new for me. :smiley:

The REALLY funny thing is, that the blocking on my phone only works when te pihole runs, on the other hand the queries from my phone are not seen in the pihole. So it seems, the phone uses the adblocker from openwrt, but can only do so, when setting the pihole as custom DNS server. :open_mouth:

I disabled the adblock functionality now. Result: adblocking still working, so it seems to be the PI! Now Mullvad also do not say I have DNS leaks. All request go to the pihole now! I guess before I had two DNS servers running in parallel.

UPDATE: after reboot blocking was gone again. So it seems the pihole is not used from my phone!

You router IP rotates??? Wow.

That would make [more] scene.

1 Like

Please tell me if I should open a new ticket, since the original question was answered. Nevertheless it is with focus on my system now, described above.

I found a new issue (might be the same as with the DNS things):
when connected to my router with the new fancy setup of two VLANs and two tunnels I can not reach my nextcloud anymore. This is just a raspi with DynDNS and port forwarding. I connected it to the VLAN without Mullvad. Reaching it from outside (Phone LTE, no tunneling) works perfectly. But I can not reach it anymore from the inside. Since it is in another VLAN it is clear that I can not reach it by IP. But why I can not go from my PC/Phone over Mullvad, use their DNS, look for my DynDNS IP and come back over the internet into the WAN port? All I found online was to activate NAT loopback, this is enabled for the port forwardings. Anything more to consider?

I guess this is the same problem as with the PiHole. After some more research I found out, that I can only use/ping it when I am in the LAN/WLAN, not when I am coming from the phone tunnel. So this the reason, why I can not choose it as an DNS server and have to chose the router as DNS and also see no adbocking on the phone when I disable the openwrt adblocking (since all DNS request from the phone run NOT over the pihole).

Of course not. Just no understand the routing.

Oh my...another thing not mentioned...but it's OK. :smiley:

That's not clear at all. Just make another rule for, priority 5, lookup main (you may have to flip priorities with the more-specific rule).

config rule
	option in 'lan2'
	option dest ''
	option priority '5'
	option lookup 'main'

You're in essence leaking traffic out of your VPN by placing more rules for not using Table No. 2 - perhaps that will give you a better perspective. I wanted to highlight this because of the DNS details, wanting to reach devices in LAN1, excluding individual IPs, etc. Most people don't want VPN leaks, so just wanted to note it.

No clue why you considered that even. NAT loopback on OpenWrt is not quite like on other routers; and nonetheless, I don't think you're using the word appropriately anyways.

On OpenWrt, loopback works to test WAN access for the IP/port in question (i.e. running a personal web server on a desktop and testing loopback). You keep mixing routing and firewalling. It's OK, I did that too when I first learned policy-based routing. :smiley:


  • Does Mullvad allow inbound traffic!?!?
  • Who said you can't you their DNS? You want adblocking correct? If Mullvad offers that, sure - use them!
  • If you take the routes and rules out, how would your devices send the reply traffic (e.g. the reply phone_vpn traffic) via WAN!?!? (Explain with VPN still working router-wide)
  • Why would you connect to a VPN, to go through the VPN - to then access your router...without VPN? That makes 0 sense to me...or I misunderstood the question.

Then allow it. Permit forwarding from phone_vpn to lan1. Simple. The router doesn't magically know you want to make another route then permit it through the firewall - I learned that too when first doing routes/firewalls.

You don't have to, it's the router itself - there's no routing! Any traffic to any IP arriving on the router is simple input as far as the router's concerned (as long as your have 1.) a route for that interface exists [if needed]; and 2.) you permit it in the firewall!).

Okay, I see your questions and confusion and try to make things a little clearer.

At the moment there are two open problems.

  1. Nextcloud things
  2. DNS things

To 1.:
I was not able to access the Nextcloud via IP from inside my network. So I thought it would be possible to access it via my DynDNS name. Both was not possible. Forget my thoughts about mullvad (the thing where you just were "???"). Basically I just want to reach it. End of story.

I added the routing rule you suggested (variated it for only allowing the one IP of my pi) and it works nice. I can reach the nextcloud from lan2. Then I added the same rule for wg0 (phone) and can also reach it via phone from inside the tunnel via IP. Nevertheless I can still not reach it via the dyndns name. This is not a MUST-HAVE but would be very nice to avoid configuration issues when changing connection or using the system outside the tunnel. Access without the tunnel goes well. The Pi does not use the tunnel (connected to lan, not lan2) what is okay for me, since I want the possibility to reach it on computers without any tunnels too. So what do I have to do to reach it via the dyndns name from my network too (the domain)? Before I created the VLANs this was not a problem and was also the thing I thought "NAT Loopback" stands for.

To 2.:
The DNS still behaves a little weird. When using the adblocker in the router (just enabled it) adblocking when using the phone works. In the router nevertheless I configured under "DHCP and DNS" on "DNS Forwarding" the IP of my pihole, which uses lan2! All devices in the network seems to use the pihole, but mullvad tells me I leak DNS, although the pihole itself uses the Mullvad DNS. When disabling the router internal adblock the leak is gone, but the phone cannot block anymore.
This tells me two things: 1. the phone cannot see the pihole, although it uses lan2 and is in the same fw zone. I think I need a new route, but I could not figure out how, since it is already in lan2. So all rules you have told me would route over the main lookup or lookup 2 to decide which interface to leave the router (mullvad or no mullvad). So how to configure here? 2. it tells me that the adblock inside the router has a DNS configure problem which is gone when I disable the internal block. I guess the best would be just always to use the pihole and also configure it inside the wireguard interface in the phone.

So I think I have to create a rule from phone_vpn to the pihole.

I tried (pihole has

config rule
	option in 'wg0'
	option dest ''
	option priority '4'
	option lookup '2'

but it did not work. I think I still mess things up here. I have understood that the firewall and the route/rules are different things. But nevertheless I do not get, how to allow access from one interface to a specific different. Maybe I need a new route as well (table 3) only for lan2 and then let the phone point to it?

Figured 2. out by myself.
I added the pihole to VLAN1, so it does not use Mullvad. Then I added the same rules as for the Nextcloud server. Now I can reach the pihole from the phone and lan2 in general. I disabled the internal adblocker and added the pihole's IP as the DNS to forward in "lan" interface, "lan2" interface and in "DHCP and DNS". I had to enable "Strict Order" under "DNS and DHCP" Advanced Settings nevertheless. By using the Mullvad DNS in the pihole I now route all DNS queris over the pihole from all members of the network, see no ads anymore and also do not get any DNS leaks from Mullvad anymore.

I still can not access the nextcloud and see some weird DNS behaviour sometimes. Since the original questions are all answered I will open new tickets and leave this one marked as solved. Thank you for your help again!

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.