Im trying to use my raspberry pi as a wireguard server.

When connecting my raspberry Pi to my router via Ethernet cable, my router assigns pi to ip

Ive confirmed the pi receives internet access via running ping www.startpage.com when SSH'd into the pi

However, once I run wg-quick up wg0 on the pi, I lose all internet access. Ping via ssh no longer works.

To regain internet access I have to run wg-quick down wg0

Wireguard is doing somthing to break my internet

My Raspberry Pi wireguard config file

sudo nano /etc/wireguard/wg0.conf

Address =
ListenPort = 51820

AllowedIPs =, ::0

Client config file

sudo nano /etc/wireguard/wg0.conf

Address =

AllowedIPs =, ::/0
Endpoint = PI/ROUTER_PUBLIC_IP:51820

NOTE : I have changed the AllowedIPs settings numerous times within both configs, to test different results, wg-quick up wg0 on my Pi still breaks the internet through my pi, without it, internet runs normally

I notice that wg-quick up wg0 is modifying my nft ruleset when up

sudo nft list ruleset
table ip wg-quick-wg0 {
        chain preraw {
                type filter hook prerouting priority raw; policy accept;
                iifname != "wg0" ip daddr fib saddr type != local drop
        chain premangle {
                type filter hook prerouting priority mangle; policy accept;
                meta l4proto udp meta mark set ct mark
        chain postmangle {
                type filter hook postrouting priority mangle; policy accept;
                meta l4proto udp meta mark 0x0000ca6c ct mark set meta mark

when wg0 interface is down, these rules dont exist So maybe something in these rules is blocking internet access within the pi

Problem Elimination

  1. isnt used by any other device on router
  2. uncommenting net.ipv4.ip_forward=1 in /etc/sysctl.conf makes no difference, the exact problem remains the same, inet access with ip4 commented or uncommented with wg0 down, no inet access with ip4 commented or uncommented with wg0 up
  3. the wireguard client-side is irrelevant at this stage
  4. The problem isnt anything to do with wireguard private/public keys, as it throws errors when it is.
  • 1
    (1) The wireguard configuration says that you're sending your default route (i.e. everything you haven't explicitly declared elsewhere) across the VPN. Is that expected? (2) If you are using ssh to access the Pi, then unless that ssh session was established locally you will likely break it because there is no longer a route to the Pi (you've moved it to the VPN) Apr 7 at 21:22
  • @ChrisDavies 1) It wouldnt be needed to send my default route through the VPN. Especially as the pi itself is the VPN server. To elaborate for brevity, Whats the point of the pi routing traffic as PI VPN > Pi > Router, from within the Pi it needs only be Pi > Router. But youve raised a interesting point, if the Pi VPN doesnt provide internet access to itself, how can it for external connected wireguard clients? 2) The SSH session is from another laptop connected to the same Router the pi is on, perhaps thats why it still works?
    – Rachel1983
    Apr 7 at 22:17
  • @A.B I didnt post the client config file because its not the cause of this issue. If I cant get the VPN host server device(pi) internet to work for itself, Clients would be unlikely to get internet through the pi.
    – Rachel1983
    Apr 7 at 22:23
  • @A.B I will post the client configuration, But the lack of internet exists on the server device.
    – Rachel1983
    Apr 7 at 22:25
  • @A.B If the server shouldnt use AllowedIPs =, What should I put here? Ive tried putting different ips, mostly internal ones. I left AllowedIPs as All in both server and client files to reduce problems by allowing all(for now)
    – Rachel1983
    Apr 7 at 22:35

1 Answer 1


When the wireguard interface is up, it's defined to send everything across the VPN:

AllowedIPs =, ::/0

This is a typical client configuration and almost certainly inappropriate for a server configuration.

Instead, you should be declaring the (small) subnet that the client is to use for itself once it's connected. For example,

Just make sure that this network address is not part of a subnet you're using somewhere else

  • In your post from Instead, you should... are you now referring to server wg0.conf Address Ive cleaned up this question by posting a new simpler version, if you wouldn't mind looking over it. unix.stackexchange.com/q/774059/604506
    – Rachel1983
    Apr 9 at 0:42
  • for clarification I never reposted the same question, they are noticeably different questions. The question here was why does wireguard break my internet access, the other question linked above demonstrates a working but unrouted internet connection. Putting everything in one question like you are encouraging is bad practice and would only invite another Stack member to post "Make a new question instead of muddying everything here" or the likes of
    – Rachel1983
    Apr 9 at 16:30
  • @Rachel1983 if you haven't received answers yet, or (as is the case here) the answerers themselves encourage you to update your existing question, then you should do that if your problem evolves (and it is clearly an evolution, not some brand new completely independent problem) instead of posting a new one. As for muddying up things, edits don't have to be additive. You can rewrite the whole question to better structure the inclusion of new information.
    – muru
    Apr 10 at 3:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .