Wireguard with default route

[dhaavi]

Continuation of issue from the VPN Compatibility thread:

I can say that wireguard used to work with portmaster like a charm since I first used portmaster. I never used DNS in [Interface] section and always had wireguard just to access servers (computers actually) behind NAT.

Today I decided to finish setup of MASQUERADE (I have no idea what am I doing) so I can tunnel everything through gateway server. TLDR I changed AllowedIPs in [Peer] section from 10.10.0.0/8 to 0.0.0.0/0.

• client connects to the server and shows like 50bytes/s traffic when running wg command
• network stopped working at all
• couldn't dig anything
• couldn't ping 8.8.8.8 / 10.10.0.1 (wg gw) / 192.168.1.1 (lan gw)

When I changed AllowedIPs to 31.0.0.0/8 which is subnet that includes address of famous Czech "what is my ip" website it worked like a charm. I don't think setting DNS in wireguard is an issue. It more likely catches some traffic between portmaster and everything else and it breaks because of this.

Originally posted by @northys in https://github.com/safing/portmaster/issues/160#issuecomment-798974673

[ppacher]

Hi, unfortunately it took a while to find time to test this but I'm currently on it and I can confirm some strange behavior here. At the first try, everything worked as expected and I was able to route the complete traffic (including DNS) via the default gateway (which was set to the wireguard server). Once I restarted portmaster/one of the wireguard peers things get weird and stopped working. I'm currently debugging what's going on here and will post an update as soon as I can shed some light here.

For reference, here's my setup:

Server (some machine with a public IP)

This one has an iptables firewall where I ensured IP forwarding and port access is allowed by:

# Enable IP forwaring
sysctl -w net.ipv4.ip_forward=1

# Allow access to wireguard peer listening port
iptables -A INPUT -p tcp --dport 52180 -j ACCEPT 
iptables -A INPUT -p udp --dport 52180 -j ACCEPT

It's also important to configure MASQUERADE on the internet facing interface:

iptables -A POSTROUTING -t nat -o enp3s0 -j MASQUERADE

The /etc/wireguard/wg0.conf file looks something like the following:

[Interface]
Address=10.9.1.254/24
ListenPort=52180
PrivateKey=<removed>
PostUp=iptables -A FORWARD -i %i -j ACCEPT; iptables -A FORWARD -o %i -j ACCEPT
PostDown=iptables -D FORWARD -i %i -j ACCEPT; iptables -D FORWARD -o %i -j ACCEPT

[Peer]
# That's my laptop
PublicKey=<removed>
PresharedKey=<removed>
AllowedIPs=10.9.1.10/32

Client (my laptop connected via mobile tethering)

This one has the Portmaster running

[Interface]
Address=10.9.1.10/32
PrivateKey=<removed>
DNS=10.9.1.254

[Peer]
# Thats the server
PublicKey=<removed>
PresharedKey=<removed>
AllowedIPs=0.0.0.0/0, ::/0
Endpoint=<removed>:52180

[ppacher]

Ok, seems like we have two different issues here. They might be caused by the same underlying bug but I'm not yet 100% sure.

Issue 1: Packets are not routed if portmaster starts before wireguard

It seems like there is an issue if the Portmaster starts before the wireguard interface is configured. If I bring up the wireguard interface with wg-quick up wg0 and start the Portmaster afterwards network traffic is routed as expected (still, Issue#2 applies). If the Portmaster is running before the wireguard tunnel is set up things break and packets cannot be routed anymore.

Possible Workaround

Restart the Portmaster service after the wireguard VPN is connected. Make sure to work-around Issue#2 as well.

Issue 2: Portmaster fails to reply to redirected DNS queries

If one configures a DNS=<ip-addr> in the [Interface] section the system will direct all DNS queries to the resolver specified there (as intended). Though, if the Portmaster is running on this peer it will detect a rogue DNS query that it will intercept and handle on it's own. AFAICT this works as expected but the Portmaster then fails to correctly reply to the query which results in DNS not working for every process other than the portmaster.

Possible Workarounds

Don't set DNS= at all

If the sole purpose of the DNS= setting was to ensure DNS is no exposed to the local network then the setting can be removed because the Portmaster already takes care of DNS encryption. If the default gateway is configured via the wireguard interface the Portmaster will also use that path for resolving queries and will thus have the same effect. Note that this workaround does not work if a system resolver is in use (like systemd-resolved). In that case set DNS=127.0.0.1 like described below (no need to configure somethig in Portmaster)

Set DNS=127.0.0.1 and configure DNS in Portmaster

If one wants to query a dedicated DNS server when connected to the Wireguard VPN (because local or non-public addresses should be resolved) the easiest workaround is to configure that DNS server in the Portmaster itself and use DNS=127.0.0.1 for the wireguard interface.

[davegson]

linked to this issue in the VPN Compatibility Community Reports via https://github.com/safing/docs/commit/7eb00f89208b6e96b3ec0fbe0c8bd18582de5485

[northys]

@ppacher I can confirm the Issue 1 workaround works for me. Thanks for the investigation!

Btw you must have spent a lot of time mastering typography in markdown. Each time you post something it's such a pleasure to read it :D

[northys]

I have made some changes to my portmaster.service unit file so it restarts portmaster everytime wg-quick@wg0 is restarted. I'll report whether it works so we can add it to doc or something. Source: https://stackoverflow.com/a/36047871

[Unit]
Description=Portmaster Privacy App
[email protected]
[email protected]
[email protected]
[email protected]

When I restart [email protected] the portmaster is immediately restarted afterwards as expected.

EDIT: Internet works right after reboot =)

[northys]

After 14 days I can tell that there are still edge cases when I have to restart either wireguard or portmaster after reboot, but it works most of the time and never crashed when booted in the correct order so I'm happy with the result for now.

I also tried to run wireguard on Windows with 0.0.0.0/0 set in AllowedIPs but it doesn't work at all. So I'm reporting it just to let you know. Not an issue for me actually.

[dhaavi]

Nice to know the workaround works.

Thanks also for checking on Windows.

[Gajus84]

Thanks for the input. I'm facing the same issues. Workaround for Issue 2 works perfectly, even using my Pi-Hole/Unbound Service on the other side of the WG-Tunnel.

northys changes on the Systemd Unit work on [email protected] restart, but not on boot. Maybe my system is too fast?

Edit: Leaving the Systemd Service untouched and using wg-quicks PostUp command to restart Portmaster seams to do the trick.

[northys]

@Gajus84 what exactly you have put to your PostUp? I'll try it on my machine and probably add it to doc or something :)

Btw yes, it happened to me like 2 in past 2 months that I booted with broken connection but it was still better than restarting it manually each time I connect to wg.

[Gajus84]

[Interface]
Table = auto
PostUp = sleep 5; systemctl restart portmaster;
PrivateKey = PRIVATEKEY
Address = WG ADRESS
DNS=127.0.0.1
ListenPort = PORT

I'm not sure if the sleep-command is really necessary, but as I suspected some kind of race condition (maybe during IP-tables setup?) between Portmaster and Wireguard I thought I give everything some extra time.

[zer0exia]

The workaround works, but I had to set up portmaster to not start automatically during system boot, because I usually need to manually start wireguard on certain occasions. Does this workaround only works once per boot? Because if I disconnect and reconnect wireguard, restarting the portmaster service won't suffice, I had to reboot my pc and start wg and portmaster again consecutively.

Another thing, if the dns is set to 127.0.0.1 in the wireguard config, portmaster update check will fail, with error :

Failed to execute 'open' on 'XMLHttpRequest': '' is not a valid HTTP method.

I'm not sure whether this is an expected byproduct of the workaround, or not.

[northys]

@zer0exia I can say that on Fedora 33 my workaround works even after multiple wg / portmaster restarts.

[ppacher]

@zer0exia can oyou post your wireguard configuration (with keys removed) so we can check if something is wrong in there?

[zer0exia]

@ppacher Sure. On portmaster the DNS is configured to use Quad9. `:::: Client configuration shown below :::: [Interface] PrivateKey = linux_priv Address = 10.6.0.2/24 MTU = 1420 DNS = 127.0.0.1

[Peer] PublicKey = server_pub PresharedKey = linux_psk Endpoint = REDACTED:51820 AllowedIPs = 0.0.0.0/0, ::0/0`

[ppacher]

Thanks @zer0exia.

Did you try to add a PostUp= like shown in the snippet from @Gajus84? Also, could you post the output of systemctl cat portmaster.service?

[zer0exia]

@ppacher added the PostUp= in my config, and now it works (tested disconnecting/reconnecting wg several times). I guess adding sleep = 5 is really necessary in my system. When I ran the wg-quick up command with the added PostUp, it usually took almost a minute to complete, before I can start using my internet. I rebooted my machines few times and repeated the process (of disconnecting/reconnecting to wg), and only one of those reboots the internet connection randomly didn't work. I'm not really sure what might caused it, but for now the workarounds will work most of the time.

Here's the output of systemctl cat portmaster.service portmaster.log

EDIT : I found out the same problem would still happen again after my system was on for a while. Internet connection will be gone unless I stop portmaster and fixed back the DNS on wg config (use only wg connection without portmaster). Or just reboot my PC every time it happens.

Also I want to add further feedback on the error above regarding update check. Right-clicking the portmaster tray icon will fill the entire screen with the error message (minor QoL stuff). I apologize if I'm clogging the thread with this.

[ppacher]

@zer0exia

we do have some improvements regarding the DNS resolver already released to the beta Release Channel. Would you mind testing that branch and report whether this fixes the "no internet after a while" issue?

Thanks for reporting the notification/tray-issue. I'll forward that to the correct repository.

[heli-aviator]

I'm bringing life back to this, can anyone explain how I can use/what I need to do, to use wireguard with portmaster occasionally. I use windscribe servers on wireguard, I don't use it to connect to my LAN at the moment.

if I start wg-quick up ATL-Mountain and portmaster is started it will brake my internet connection. I've tried sudo systemctl stop portmaster then start wg-quick up ATL-Mountain Then restarted sudo systemctl start portmaster but the connection is still broken, until I take down wg-quick down ATL-Mountain the Internet connection comes back.

Does anybody have any tips? if you have could you try explaining it in layman's terms?

[acheong08]

Any chance this could be fully resolved? I've actually stopped using portmaster specifically because of this for over a year and was hoping to come back to a fixed version

[Visual-Dawg]

I also have an issue with Wireguard. I am using the DNS option to access an internal network, however with Portmaster running the DNS stops working.

How can I provide data for you to debug this?

[Cris70]

I have the same issue, and I can confirm that the suggested workaround works. Is there a resolution in the works? Thank you in advance

[Raphty]

a vpn compatibility mode is something we are considering tackling later this year.

(for those who just read this, in general VPN as a technology is compatible, usually it is the apps which break compatibility, and this mode will increase compatibility, with hopefully only minor drawbacks)

[Flashwalker]

Issue 1: Packets are not routed if portmaster starts before wireguard

It seems like there is an issue if the Portmaster starts before the wireguard interface is configured. If I bring up the wireguard interface with wg-quick up wg0 and start the Portmaster afterwards network traffic is routed as expected (still, Issue#2 applies). If the Portmaster is running before the wireguard tunnel is set up things break and packets cannot be routed anymore.

Possible Workaround

Restart the Portmaster service after the wireguard VPN is connected. Make sure to work-around Issue#2 as well.

added the PostUp= in my config, and now it works (tested disconnecting/reconnecting wg several times). I guess adding sleep = 5 is really necessary in my system. When I ran the wg-quick up command with the added PostUp, it usually took almost a minute to complete, before I can start using my internet. I rebooted my machines few times and repeated the process (of disconnecting/reconnecting to wg), and only one of those reboots the internet connection randomly didn't work. I'm not really sure what might caused it, but for now the workarounds will work most of the time.

Alas, it doesn't always work. For some unknown reason, Portmaster continues to block Wireguard traffic even if the Portmaster service is restarted. All connections through Wireguard are recognized by Portmaster as Other connections.

I'm not using Secure DNS option in Portmaster. Always use DNS cache is disabled. I'm not using DNS in Wireguard config file.

[Flashwalker]

I have the same issue, and I can confirm that the suggested workaround works. Is there a resolution in the works? Thank you in advance

Any chance this could be fully resolved? I've actually stopped using portmaster specifically because of this for over a year and was hoping to come back to a fixed version

Try to disable Always use DNS cache in Portmaster settings, and not set DNS in Wireguard config file

[Flashwalker]

If i start Wireguard and restarting the Portmaster service via systemctl restart portmaster command - connection isn't working.
The only way connection is working if i - start/restart Wireguard and restart the Portmaster service from the app menu - several times.

[GabrieleRisso]

I can confirm that postmaster is working properly in linux. The only modification i made was to edit the client wireguard configuration file by adding this line: PostUp = sleep 4; systemctl restart portmaster;

/etc/wireguard/wg.conf :

[Interface]
PostUp = sleep 4; systemctl restart portmaster;
PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
Address = 10.110.222.2/24
DNS = 9.9.9.9, 149.112.112.112

[Peer]
PublicKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
PresharedKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXX=
Endpoint = 99.999.999.999:52978
AllowedIPs = 0.0.0.0/0

[LokeYourC3PH]

I personally have simply had enough with all the problems that Portmaster creates as opposed to what it is supposed to solve. Issues with VPN (WireGuard, NordVPN, you name it), issues with WSA/WSL, internal connection issues... And no matter what you try to solve it, Portmaster refuses to let it work. I purchased 2 years of Pro, but this is simply too much for me and too convoluted, and I'm tired of it simply. Going to uninstall Portmaster again like I had to do a year ago because of the same issues. Somebody wake me up when Portmaster works properly, until then SimpleWall or MFC will suffice just fine.

[Cris70]

I personally have simply had enough with all the problems that Portmaster creates as opposed to what it is supposed to solve.

Same here, I stopped using PortMaster months ago after struggling to make it work properly without success. High CPU usage, issues with VPN, etc.

[acheong08]

The main thing I liked PortMaster for was checking out which process was making DNS requests & blocking them from doing so. I've now switched over to using AdGuardHome for DNS and found this script: https://gist.github.com/gptlang/d7e22aba20b3187d8f5f40b9a65fe5b5 (a fork, the original has a memory leak) to be pretty useful (on Linux) for checking offending processes making DNS requests. Might be worth it at some point to improve upon it & get a proper logging/searching UI up and running.

[LokeYourC3PH]

The main thing I liked PortMaster for was checking out which process was making DNS requests & blocking them from doing so. I've now switched over to using AdGuardHome for DNS and found this script: https://gist.github.com/gptlang/d7e22aba20b3187d8f5f40b9a65fe5b5 (a fork, the original has a memory leak) to be pretty useful (on Linux) for checking offending processes making DNS requests. Might be worth it at some point to improve upon it & get a proper logging/searching UI up and running.

I used to love GlassWire for that purpose on Windows, and while NextDNS would achieve the same, I personally want both the DNS/Connection requests & blocking aspects as well as the integrated "one click to block" firewall aspects of it. I chose Portmaster because Portmaster is, as I see it, a more advanced & feature-rich version of GlassWire, and I also don't have to pay a hefty and pointless monthly subscription for Portmaster as you have to do with GlassWire (although I did support Portmaster development by buying a 2 year Pro package, something I somewhat regret doing now just a little). I really wanted Portmaster to succeed GlassWire, but alas, Portmaster simply isn't ready yet for daily usage as it is still far too unstable. I mean hell, even when you completely shutdown Portmaster and kill the system service, it still blocks VPN and causes connection problems for WSA/WSL, and all the other host of problems that exist with Portmaster. Such a shame really, but for now I can deal with using just SimpleWall as a firewall with "one click to block" functionality, and as for the graphs & DNS/connections analysis, I can do without that for the moment (I refuse to pay a damn subscription to GlassWire, as I hate subscriptions out of principle, they're incredibly shady anti-consumer tactics imo).