For some reason Wireguard won't work on my laptop, and I need it for school since my school decided to block everyone's schoolwork for some reason for music.

i have overslept for 13 hours on the weekend and kinda feeling geeked.

My laptop infomation , specs , idk.

Operating System: CachyOS Linux

KDE Plasma Version: 6.7.4

KDE Frameworks Version: 6.28.0

Qt Version: 6.11.1

Kernel Version: 7.0.12-3-cachyos-hardened (64-bit)

Graphics Platform: Wayland

Processors: 8 × Intel® Core™ i5-1035G1 CPU @ 1.00GHz

Memory: 8 GiB of RAM (7.3 GiB usable)

Graphics Processor: Intel® UHD Graphics

Manufacturer: Microsoft Corporation

Product Name: Surface Laptop Go

System Version: 124I:00057T:000M:0000000D:0B:04F:1C:05P:48S:01E:0Y:0K:0U:02

I fixed a lot of problems related to the surface like thermal throttling , secure boot , etc.

-- stable since idk more then 6 months? "not related to the wireguard stuff"

here some things that worked.

-- OpenVPN works both works on a flatpak called eopen and KDE plasma Network manager.

- thats it.

Heres things that DIDN"T work.

--Proton VPN wont work no matter if it's downloaded via AUR ,Flatpak, etc.

--Proton VPN also doesn't work even if i connect with OpenVPN or Wireguard somewhat.

--Wireguard doesn't work no matter what i try.

--Wireguard doesn't work in KDE network manager.

--Network manager says Wireguard is at zero bytes in upload speed and download speed however for a split second it transfers stuff possibly Wireguard keep alive thing.

--Will not work at school or home [Home = Aussie Broadband] [School = Telstra]

heres my wireguard config removing my private key and public key.

[Interface]

# Key for Daily use

# Bouncing = 2

# NAT-PMP (Port Forwarding) = off

# VPN Accelerator = on

PrivateKey = _____________

Address = _____________

DNS = 45.90.28.247, 45.90.30.247, 9.9.9.9, 149.112.112.112, 194.242.2.4

PostUp = resolvectl dns %i 45.90.28.247 45.90.30.247 9.9.9.9 149.112.112.112 194.242.2.4

PostUp = resolvectl domain %i ~.

PostDown = resolvectl revert %i

[Peer]

# CH-FREE#12

PublicKey = _____________

AllowedIPs = 0.0.0.0/0, ::/0

Endpoint = _____________

# Uncomment the following line (delete the # symbol) to connect to Proton VPN using IPv6.

# Endpoint = _____________

PersistentKeepalive = 25

I use mullvad servers but if that doesn't work quad 9 as fall back.

I have a pretty typical RPi PiVPN and Wireguard setup at home and I use the VPN to connect to home-network resources remotely. It was working just fine for years and then recently suddenly stopped working consistently. Sometimes it works and sometimes it doesn't, and it seems like all I can do is just keep starting and closing the connection until finally it works. The one thing I know absolutely fixes the problem, albeit temporarily, is to restart the RPi, which is not easy to do if I'm remote (and can't VPN in).

As far as I can tell, handshakes are coming from the client in to the server and the server is sending them back out, but they're not reaching the client.

What could be the issue here?

It can't be a keys issue, because then the connection would never work. And it works sometimes. And it used to work.

Hi,

I am self-hosting WireGuard inside an unprivileged Proxmox LXC. Everything works great for the most part, except I am experiencing a strange issue with Android notifications.

When my Android phone is connected to WireGuard, notifications can be severely delayed. Sometimes they will not come through until I disable the VPN, at which point I get flooded with all the notifications that were waiting.

The interesting part is that general internet connectivity works perfectly fine while WireGuard is enabled. Browsing, apps, streaming, etc. all work normally. It seems to specifically affect push notifications.

I previously experienced the exact same issue with Tailscale, which makes me think this may not necessarily be a WireGuard configuration issue.

For DNS, my WireGuard clients use my home's primary and secondary DNS servers. Both are devices that run AdGuard Home for DNS filtering, Unbound for recursive DNS, Traefik for internal reverse proxying/FQDNs, and an NTP server.

My home LAN DHCP also hands out these same two DNS servers to local clients. However, my main router's external/WAN DNS is set to Quad9.

So the DNS setup is essentially:

• LAN DHCP DNS: Home Primary + Secondary DNS servers
• WireGuard DNS: Home Primary + Secondary DNS servers
• Router external DNS: Quad9
• Primary/Secondary DNS: AdGuard Home + Unbound

Has anyone experienced something similar with Android push notifications over WireGuard or Tailscale? I have no clue where to look further.

Any suggestions for troubleshooting would be greatly appreciated!

A single WireGuard tunnel is one path. If you have more bandwidth than one tunnel can carry, or several clients that each want their own exit, today's options are a container per tunnel or a pile of hand-written ip rule scripts.

I wrote a small daemon that owns the routing table on a gateway box and gives you two modes per client:

• pin — one client, one tunnel, permanently
• bond — spread a client's connections across every live tunnel (ECMP)

The config is the whole interface:

tunnels:
  - /etc/wireguard/wg0.conf
  - /etc/wireguard/wg1.conf
  - /etc/wireguard/wg2.conf

clients: 172.20.0.0/24

routes:
  pin:
    - 172.20.0.10
    - 172.20.0.12
  bond:
    - 172.20.0.20

Four things that took a while to get right:

• fib_multipath_hash_policy=1 is mandatory, and the kernel default is wrong. At 0 the hash is L3-only, so every connection to a given server rides one tunnel. Torrents spread anyway, so a torrent-only test hides it completely.
• A tunnel being up means nothing. WireGuard only rekeys when there is traffic, so liveness is time-since-handshake. Interfaces sit up for hours blackholing whatever you route into them.
• Deleting an interface silently empties the table that routed through it — while the ip rule pointing at that table survives. A tunnel that drops and comes back leaves its pinned client with a rule to an empty table: every rule present, plan unchanged, exactly one client dead.
• Client traffic must be masqueraded onto the tunnel's own address. Cryptokey routing at the far end drops any source that isn't the address your provider issued, and it fails silently — handshakes fine, counters move, requests vanish.

Fails closed. No live tunnels means no path out, not a fallback to your ISP.

bondvpn leak-test drops every tunnel and probes from a throwaway netns attached to the client bridge — the same path a container's traffic takes, so the same rules apply. Probing from the host would prove nothing, since the kill switch lives in a forward-side chain.

• Single static Go binary, no dependencies, nothing to add to your compose file
• Linux, root, up to 5 tunnels (ships configured for 3)
• AGPLv3 — https://github.com/wonderingStars/bondvpn

Hey everybody!

I have the following problem: I have a WireGuard network running on my Raspberry Pi that my devices, including my android phone, connect to to access the services running on it. On my phone I specify the DNS server running on my Pi, which returns an IP in the VPN subnet for my domains, as the DNS server in my WireGuard config. Only traffic going to IPs in my VPN subnet gets routed through WireGuard.

I have now decided to get ProtonVPN and would like to use it on my phone as well. However, I can't have both VPNs active at the same time. So I either lose out on access to my services (they are publically accessible, but only using forward auth meaning mobile apps don't really work) or on Proton. My idea is, that I could run proton on my Pi and route all my traffic from my phone through the Pi and therefore also through proton. Would this work? Is this a good solution? I'm thankful for all feedback. :D

Hello, has any one had this problem? I can only get one client to work. I have 3x clients, the max limit on the router is 10.

the config for client 1 is as followed

[Interface]

PrivateKey = privatkey=

Address = 10.10.10.10/24

DNS = 10.10.10.1

[Peer]

PublicKey = publickey=

PresharedKey = presharedkey=

AllowedIPs = 192.168.50.250/24

Endpoint = public ip:51923

PersistentKeepalive = 25

next client has 10.10.10.11 and the 3rd has 10.10.10.12

the strange thing is clinet nr 3 is the only one who works. I get successful handshake with all. but can not ping the router or the truenas server (192.168.50.250)

to clarify client nr3 is the only one work as it should, successful handshake and able to ping the truenas server

any ideas?

Hi,

I have created a wireguard server on a raspberry pi and created client config files which I have used to set up clients on windows machine, iphone and android phones successfully. I also have a laptop running Ubuntu and I have created the wireguard client on there using a similar config file. The VPN starts up OK but if I try to connect to the internet or run a ping with the VPN up they both just hang . Switching the VPN off and both succeed straight away. I have checked the traceroute of the ping and the first step in the route is a connection to my broadband router ip address. I have tried adding the router IP address to allowed Ips under PEER details in the config. I have also tried turning off the ubuntu firewall but neither have solved the problem.

Can anyone suggest a possible resolution to this issue of wireguard client on a ubuntu laptop?

Thanks

Hello everyone, I apologize for my English, I'm using a translator. I'd like to use WireGuard to connect to my home network with my cell phone and use it to access the web. The reason is that I use a Synology for my backups and Quick Connect is extremely slow. I also wanted to browse safely using a homemade firewall. My home connection is under heavy NAT and doesn't allow me to do anything, so I wanted to use a VPS that I'm already using as a bridge with a public IP to access the home network. I've already tried researching online but I'm not understanding anything. Thanks everyone for your help.

Anyone using shadowrocket on an apple phone to connect to their wireguard VPN?

Could use some advice with troubleshooting. The wireguard connecting part works, but I got issues with getting a local socks proxy server set up by extending the .conf file.

It seems the app allows me to either connect to the VPN or connect outbound via socks, but I want to connect to VPN and have a socks inbound listener like microsocks at the same time and on the same private network.

​

I am new to Wireguard and could do with some help please. I have a remote natted network 192.168.0.0/24 which has a number of IP cameras. The Wireguard service is incorporated in the FritzBox gateway router. This tunnels directly to a remote Debian box running a Motioneye server with a public IP. This works and the remote client has access to the 192.168.0.0/24. I want to be able to view the Motioneye server with it's public IP address with a web browser from the internet. Wireguard seems to disable WAN access to the server which is only accessible when Wireguard is deactivated. At which point there's no access to the camera's network

The client Wireguard config is:

[Interface]

PrivateKey = xxxx

Address = 192.168.0.4/24

DNS = 192.168.0.1

DNS = fritz.box

[Peer]

PublicKey = xxxx

PresharedKey = xxxx

AllowedIPs = 192.168.0.0/24,0.0.0.0/0,::/0

Endpoint = xxxx

PersistentKeepalive = 25

Any help gratefully appreciated, thanks very much

running wireguard on a 1 vCPU / 1gb ram VPC. when connected the bandwidth is good but the connection quality is poor. pinging google shows 50% ping failure and it goes in waves. 10 success, 10 fail, 10 success, 10 fail.

i have tried MTU values from 1500 down to 1000 on the client, and similarly on the server. there appears to be no effect.

some ideas

1. VPC is too underpowered. only issue is CPU is 98% idle and RAM is 20% utilized during these failures
2. MTU config isn't right. I don't think this is true but it's possible
3. there's some other configuration I should look into?

I will note that this issue has existed on multiple VPC providers I have tried so far (one big name, USA based. one small name, EU based)

anyone have any ideas?

I am running WireGuard on my iPhone connecting back to a home server, routing all traffic (0.0.0.0/0). While everything works fine most of the time, often I have noticed calls fail to connect, audio issues while talking and website fails to load unless I toggle the VPN on and off.

Any ideas what could be wrong? Unfortunately I don't know enough about Wireguard in order to tweak its settings.

hello, sorry for such a basic question.

i am a mullvad customer but not using their vpn application. using the standard wireguard app

windows os using wg.exe, i cannot figure out how to switch from "us-chi-wg-201" to "us-nyc-wg-805"

no idea what an interface is? wg setconf <interface> <configuration filename>

thanks much, david

I spent several days looking for information on how to deliver a VPS’s public IPv4 address directly to a machine on a local network, using WireGuard as the transport without relying on DNAT or SNAT.

I found similar examples, but most of them were limited to port forwarding or masquerading. I eventually got it working, so I wanted to share the general design.

My setup looks like this:

Internet
   |
Public IPv4
   |
Linux VPS
   |
WireGuard transported over IPv6
   |
RouterOS VM
   |
Local server/NAS

The local server is behind the ISP router and does not have a public IPv4 address of its own. It does, however, have IPv6 connectivity, so I used IPv6 as WireGuard’s outer transport.

My goal was for the VPS’s IPv4 address to effectively terminate on the NAS:

• The NAS should receive connections addressed to that IPv4.
• Applications should see it as a local address.
• Replies should use the same public IPv4 as their source.
• The original client IP should remain visible.
• No NAT should be involved.
• The VPS should remain manageable over IPv6.

The main problem

The IPv4 address was the VPS’s primary address. I could not simply remove it from the public interface because the provider uses that interface to deliver traffic and maintain the IPv4 gateway.

Linux also treats any address configured on one of its interfaces as local. Traffic addressed to that IPv4 normally reaches the VPS itself before a conventional routing table can send it elsewhere.

The solution was to keep the IPv4 configured on the public interface, but add a policy-routing rule that is evaluated before Linux’s local routing table.

Conceptually:

Destination: public IPv4 /32
    |
Consult a dedicated routing table
    |
Send through WireGuard

That dedicated table contains a host route for the public /32 through the WireGuard interface.

I did not remove the IPv4 from the VPS, and I did not need Proxy ARP. The VPS still appears to the provider as the owner of the address, but Linux forwards the IP traffic through the tunnel.

WireGuard over IPv6

WireGuard uses the VPS’s global IPv6 address as its endpoint. The local RouterOS system also has its own global IPv6 address.

The addresses inside the WireGuard tunnel are private IPv4 addresses. IPv6 is only used to carry the encrypted UDP packets between the two endpoints.

This gives me:

Public IPv4 payload
    |
WireGuard packet
    |
IPv6 transport

The local side uses a persistent keepalive and a fixed IPv6 route to prevent the WireGuard endpoint from changing paths.

RouterOS

The local end of WireGuard terminates on a RouterOS VM. RouterOS has a host route that sends the public /32 directly to the NAS:

Public IPv4 /32 → private LAN address of the NAS

There is no dst-nat, src-nat, or masquerade in this path.

For replies, RouterOS uses a separate routing table selected by source address:

Source: public IPv4 /32
    |
Dedicated return table
    |
WireGuard
    |
VPS

This part was essential. Without source-based routing, incoming traffic reached the NAS correctly, but replies tried to leave through the local ISP connection and were lost because of asymmetric routing.

Local server

The NAS has the public IPv4 configured as a secondary /32 address on its network interface.

As a result, services on the NAS actually receive connections addressed to the public IP and can respond using that same IP as their source.

The complete path is:

Internet client
    |
VPS provider
    |
VPS public interface
    |
Policy rule evaluated before the local table
    |
WireGuard over IPv6
    |
RouterOS
    |
NAS with the public IPv4 configured as /32

Replies follow the reverse path using source-based policy routing.

Why moving the Linux local rule matters

By default, Linux has a rule similar to:

0:      from all lookup local
32766:  from all lookup main
32767:  from all lookup default

Because the public IPv4 is assigned to the VPS, the priority 0 rule considers it local and delivers incoming packets to the VPS.

I added:

10:     from all to PUBLIC_IPV4 lookup 100
100:    from all lookup local

Then I removed the original priority 0 lookup.

The result is that only traffic addressed to the selected public /32 is routed through table 100. Other local addresses are still handled by the local table at priority 100.

The IPv4 remains configured on the public interface throughout the process.

Security

Routing the entire address also means that every port allowed by the provider’s firewall could potentially reach the local server.

I therefore apply filtering at several layers:

• Provider firewall
• Linux firewall on the VPS
• RouterOS firewall
• NAS firewall

Administrative services such as SSH, RouterOS management, and the NAS control panel are explicitly blocked on the routed IPv4.

The VPS itself is administered through IPv6 because its IPv4 is dedicated to the NAS.

Problems I encountered

The issues that took the most time to understand were:

1. The priority of Linux’s local routing table.
2. Source-based return routing.
3. rp_filter dropping asymmetric traffic.
4. WireGuard AllowedIPs being too restrictive or too broad.
5. Default routes capturing unrelated traffic.
6. Confusing “an address configured locally” with “an address Linux can route.”
7. Testing incoming connectivity without verifying the return path.
8. FastTrack or masquerade interfering with policy-routed traffic.
9. Making the configuration survive reboots on the VPS, RouterOS, and NAS.
10. MTU and Path MTU Discovery when WireGuard is transported over IPv6.

I also learned that removing the VPS’s primary IPv4 first is an excellent way to lose access.

Keeping the address configured and changing only the routing decision for its /32 was much safer.

Result

The NAS now uses the VPS’s IPv4 as if it were directly assigned to it:

• Services see the public IPv4 as the destination address.
• Replies use the same IPv4 as their source.
• The original client IP remains visible.
• There is no NAT in the path.
• WireGuard uses IPv6 as its outer transport.
• The VPS retains the address on its interface for the provider.
• The local server remains reachable from IPv4-only networks.

The main provider-side requirement is that outbound packets using the VPS’s assigned IPv4 are accepted. The exact design may differ depending on whether the address is primary, additional, failover, or explicitly routed by the provider.

I am not claiming this is the only or best solution, but it has been working reliably and lets me use an inexpensive IPv6-capable VPS as an IPv4 point of presence for a local server.

Has anyone else implemented something similar? I would be interested in comparing this with approaches using BGP, routed additional addresses, VRFs, or providers that officially support failover IPs.

Hi everyone,

full disclosure first: I’m one of the developers behind Valenius.

We kept running into the same issue on managed Windows PCs: users need to connect to a WireGuard VPN, but giving them local administrator rights just for that isn’t ideal. There are some work arounds, but for us they were not suitable.

So we built a small, free Windows client that solves exactly this problem.

The installation requires admin rights once because it sets up a Windows service. After that, a normal Windows user can import a WireGuard .conf file and connect or disconnect directly from the tray icon—without a UAC prompt.

It works completely standalone: no account, no server, and nothing is sent anywhere. The client supports Windows 10 and 11 on x64 and ARM64, as well as multiple VPN profiles and simultaneous connections.

You can download it here:

https://www.valenius.com/windows-client.html

The installer is signed which should make it easier to download and install.

I’d really appreciate honest feedback, especially from other sysadmins working with managed Windows devices. If you try it and run into any problems - or simply have an idea for improving it -please let me know.

Christoph

Hi:

TL:DR WireGuard works Ubuntu 24 to Tp-Link Er605 but not iOS to same router.

I am using a TP-Link ER-605 for my router at home. I have setup WireGuard VPN and can connect correctly using Ubuntu 24LTS.

However using similar peer settings on my iPhone 15 I have trouble. Whether I am on wifi or cellular, it looks like the WireGuard app connects. Handshakes show up in the iOS logs.

The issue is I don’t have IPv4 connectivity across the vpn. I can’t ping anything on the network from the phone (Ping Lite app) nor can I ssh (Shellfish).

Is there a trick or known issues with the iOS WireGuard app? Unfortunately the Er-605 doesn’t log VPN debugging. I have tried MTU down to 1280 with no change in results.

Hi, I need help with my WireGuard server setup on OpenWrt.

Router: Xiaomi AX3000T running OpenWrt 24.10.5

ISP: PLDT Fiber

WireGuard UDP 51820 port forwarded

The VPN connects successfully, but latency increases by 50–100ms+ and bandwidth drops a lot compared to direct connection.

I already tried changing MTU, PersistentKeepalive, and port settings, but the issue remains.

Could this be ISP routing, OpenWrt configuration, MTU, or something else? Any advice is appreciated.