Mullvad DNS issue

[Rubber-Duckie]

Can you check, this still seems unresolved .

Steps;

1. Connect to Mullvad and select a server in a different country.
2. Make sure all DNS sec in the browser is turned off.
3. Verify that the DNS check is green. https://mullvad.net/en/check
4. Now note the location reported by the Mullvad DNS check, it matches your exit country.

The fact the DNS server is showing in the same country as the VPN server your connected to is normal in this configuration, because the VPN is relaying the DNS query to a server in the exit jurisdiction.

Now start Portmaster with these settings.

At this point, DNS is broken - there is no connectivity to the internet. It appears that Portmaster is not respecting the Mullvad VPN’s gateway - despite the documentation stating it should be forwarding DNS to the system assigned DNS server - which is available from the TAP adapter interface that was created by the VPN.

Suggestion previous was to manually set a DNS server in Portmaster to a public server i.e.

dot://extended.dns.mullvad.net?ip=194.242.2.5&name=mullvad&blockedif=empty

But this is not what we want. The DNS requests should be passed to a Mullvad VPN Relay (via the client) not sent direct to a public server.

See here why bypassing a VPN Relay using a public facing DNS server is not a good idea; https://www.privacyguides.org/en/advanced/dns-overview/#why-shouldnt-i-use-encrypted-dns

Lets try to redirect DNS to the Mullvad local listener IP that is designed to Relay DNS...

dns://10.64.0.1?name=Mullvad&blockedif=zeroip

This is specified as a valid resolver here ; https://mullvad.net/en/help/running-wireguard-router

This results in incredibly unstable DNS resolution. It works for a moment, then fails and packs in all together - possibly some cache reminants. As soon as I disable Portmaster, everything works as normal.

The Portmaster documentation states that it only intercepts and forwards DNS queries through two possible paths:

1. Any configured DNS servers within the section shown above, bypassing the system network-configured DNS entirely.
2. If there are no entries configured in the Portmaster DNS server list, it reverts to using the network-configured DNS server.

Given # 2 is the chosen path since no DNS servers have been configured within Portmaster, Portmaster remains oblivious to the VPN local service that inserted its IP in the IP tables configuration.

I simply cannot get Portmaster to connect using Mullvad VPN and Mullvad DNS Relay.

[Internot3]

Happy to have found Portmaster, but sad to realize I cannot get Mullvard to work with it.

Has anyone been able to successfully pass the DNS requests through the Mullvad VPN Relay?

The following links generated zero success: https://github.com/safing/portmaster/issues/313#issuecomment-2339077939 https://wiki.safing.io/en/Portmaster/App/Compatibility/Software/MullvadVPN

Mullvard just says to uninstall Portmaster: https://mullvad.net/en/help/dns-leaks

What is going on here? The best VPN isn't compatible with the best Firewall?

Update: I forgot all about $PN, now it all makes sense why these programs don't work together. It's kind of a bummer being strong armed into the service. I was considering to switch to SPN before I realized the incompatibility, then I noticed it's double the price of Mullvard.

[flossposse]

Hi @Rubber-Duckie! Fellow user here. As this issue is a couple months old, I don't know whether this is still an issue for you, or if you're even still using PM, but just in case you or anyone else is struggling with this...

I think you should be able to get DNS resolution if you add dns://10.64.0.1 in Portmaster as your DNS server and turn off the "Use Secure Protocols Only option"

With this configuration, when you make a DNS request while PortMaster is running, PM will intercept the request and forward it to 10.64.0.1.

Some things to note:

• 10.64.0.1 is an address that's local to the VPN network, so it's only going to be accessible while the Mullvad VPN is connected. Once you disconnect from VPN, DNS resolution will fail if that's the only server configured.
• The request to 10.64.0.1 is a plain DNS request, meaning it's unencrypted except for the encryption provided by the VPN. If the VPN is disconnected, and you try to look up an address, you'll be sending unencrypted DNS requests to 10.64.0.1. (And it will fail unless you're on a network that also has a DNS server at that address)

Regarding this:

See here why bypassing a VPN Relay using a public facing DNS server is not a good idea; https://www.privacyguides.org/en/advanced/dns-overview/#why-shouldnt-i-use-encrypted-dns

The way I read this, what Privacy Guides is saying is that encrypted DNS alone (without VPN) is insufficient if you want third parties to be unable to observe which sites your traffic is going to. But I don't think they meant to imply that you shouldn't use encrypted DNS in combination with a VPN, especially since in this case the DNS is operated by your VPN provider.

If you're connected to Mullvad's VPN, then all your traffic, including DNS requests, will be routed through the VPN, so if you used their public dot://extended.dns.mullvad.net server to resolve widgets.com, that request will appear to come from the VPN server, not from your computer. A third party sniffing packets for SNI would be able to infer that some Mullvad user was visiting widgets.com, but they wouldn't be able to tell which Mullvad user without somehow getting access to decrypted traffic. So I don't think that guide should be taken as a reason to avoid using the DoT resolver.

[github-actions[bot]]

This issue has been automatically marked as inactive because it has not had activity in the past two months.

If no further activity occurs, this issue will be automatically closed in one week in order to increase our focus on active topics.

[github-actions[bot]]

This issue has been automatically marked as inactive because it has not had activity in the past two months.

If no further activity occurs, this issue will be automatically closed in one week in order to increase our focus on active topics.

[github-actions[bot]]

This issue has been automatically closed because it has not had recent activity. Thank you for your contributions.

If the issue has not been resolved, you can find more information in our Wiki or continue the conversation on our Discord.

[eugenesvk]

Because this time you've missed your 1-week opportunity to scare the evil bot away (which shouldn't exist)

[an0o0oo00o00o0o00onymo0o000o0o0ooo0o0us]

Same. Always wanted to use Portmaster but I just can't because I use Mullvad.

[an0o0oo00o00o0o00onymo0o000o0o0ooo0o0us]

Hi @Rubber-Duckie! Fellow user here. As this issue is a couple months old, I don't know whether this is still an issue for you, or if you're even still using PM, but just in case you or anyone else is struggling with this...

I think you should be able to get DNS resolution if you add dns://10.64.0.1 in Portmaster as your DNS server and turn off the "Use Secure Protocols Only option"

With this configuration, when you make a DNS request while PortMaster is running, PM will intercept the request and forward it to 10.64.0.1.

Some things to note:

* 10.64.0.1 is an address that's local to the VPN network, so it's only going to be accessible while the Mullvad VPN is connected.  Once you disconnect from VPN, DNS resolution will fail if that's the only server configured.

* The request to 10.64.0.1 is a plain DNS request, meaning it's unencrypted except for the encryption provided by the VPN.  If the VPN is disconnected, and you try to look up an address, you'll be sending unencrypted DNS requests to 10.64.0.1.  (And it will fail unless you're on a network that _also_ has a DNS server at that address)

Regarding this:

See here why bypassing a VPN Relay using a public facing DNS server is not a good idea; https://www.privacyguides.org/en/advanced/dns-overview/#why-shouldnt-i-use-encrypted-dns

The way I read this, what Privacy Guides is saying is that encrypted DNS alone (without VPN) is insufficient if you want third parties to be unable to observe which sites your traffic is going to. But I don't think they meant to imply that you shouldn't use encrypted DNS in combination with a VPN, especially since in this case the DNS is operated by your VPN provider.

If you're connected to Mullvad's VPN, then all your traffic, including DNS requests, will be routed through the VPN, so if you used their public dot://extended.dns.mullvad.net server to resolve widgets.com, that request will appear to come from the VPN server, not from your computer. A third party sniffing packets for SNI would be able to infer that some Mullvad user was visiting widgets.com, but they wouldn't be able to tell which Mullvad user without somehow getting access to decrypted traffic. So I don't think that guide should be taken as a reason to avoid using the DoT resolver.

This also doesn't work for me.

[oliverban]

Is there any updates regarding this issue? I've followed the guide from Safing but it doesn't work unfortunately and when Mullvad is active I can't get PM to work and I loose connectivity. Not ideal since I have custom rules in PM that I'd like to still be respected but I'd rather have Mullvad than only PM! 😢