[Solved] Wireguard interface no internet

LinG · 2021-04-07 16:57:58

Intro

trying to setup a wireguard VPN and pihole server (on the same machine), I followed the wireguard article on the wiki and after generating all the required keys was able to connect my client to the server on the wireguard network interface.

Settings

1. server

[Interface]
Address = 10.0.0.1/24, fdc9:281f:04d7:9ee9::1/64
ListenPort = redacted
PrivateKey = redacted

[Peer]
PublicKey = redacted
PresharedKey = redacted
AllowedIPs = 10.0.0.2/32, fdc9:281f:04d7:9ee9::2/128

2. client (using NetworkManager ui from plasma-nm)

[IPv4 Interface]
DNS = 10.0.0.1
Address = 10.0.0.2
Netmask = 255.255.255.255
Gateway = 10.0.0.1

[Peer]
AllowedIPs = 0.0.0.0/0,::/0

After connecting

1. server

wg0: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.0.0.1/24 scope global wg0
       valid_lft forever preferred_lft forever
    inet6 fdc9:281f:4d7:9ee9::1/64 scope global
       valid_lft forever preferred_lft forever

2. client

vpn: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state UNKNOWN group default qlen 1000
    link/none
    inet 10.0.0.2/32 scope global noprefixroute vpn
       valid_lft forever preferred_lft forever
    inet6 fe80::8819:8321:837f:187d/64 scope link stable-privacy
       valid_lft forever preferred_lft forever

The problem

1. pinging between the client and server works fine, but when I try to ping 8.8.8.8 (internet) it fails

What I've tried

1. I believe this is because the wg0 interface on the server side does not share with the internet interface (which enters at eth0)
2. So I followed the internet sharing article on the wiki using iptables
3. Now I can't even ping between the server (ping 10.0.0.2 from server) and the client (ping 10.0.0.1 from client) after activating these rules

What am I missing? (iptables info below)

sysctl -a | grep forward
net.ipv4.conf.all.bc_forwarding = 0
net.ipv4.conf.all.forwarding = 1
net.ipv4.conf.all.mc_forwarding = 0
net.ipv4.conf.default.bc_forwarding = 0
net.ipv4.conf.default.forwarding = 1
net.ipv4.conf.default.mc_forwarding = 0
net.ipv4.conf.eth0.bc_forwarding = 0
net.ipv4.conf.eth0.forwarding = 1
net.ipv4.conf.eth0.mc_forwarding = 0
net.ipv4.conf.lo.bc_forwarding = 0
net.ipv4.conf.lo.forwarding = 1
net.ipv4.conf.lo.mc_forwarding = 0
net.ipv4.conf.wg0.bc_forwarding = 0
net.ipv4.conf.wg0.forwarding = 1
net.ipv4.conf.wg0.mc_forwarding = 0
net.ipv4.conf.wlan0.bc_forwarding = 0
net.ipv4.conf.wlan0.forwarding = 1
net.ipv4.conf.wlan0.mc_forwarding = 0
net.ipv4.ip_forward = 1
net.ipv4.ip_forward_update_priority = 1
net.ipv4.ip_forward_use_pmtu = 0
net.ipv6.conf.all.forwarding = 1
net.ipv6.conf.all.mc_forwarding = 0
net.ipv6.conf.default.forwarding = 1
net.ipv6.conf.default.mc_forwarding = 0
net.ipv6.conf.eth0.forwarding = 1
net.ipv6.conf.eth0.mc_forwarding = 0
net.ipv6.conf.lo.forwarding = 1
net.ipv6.conf.lo.mc_forwarding = 0
net.ipv6.conf.wg0.forwarding = 1
net.ipv6.conf.wg0.mc_forwarding = 0
net.ipv6.conf.wlan0.forwarding = 1
net.ipv6.conf.wlan0.mc_forwarding = 0

iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wg0 -o eth0 -j ACCEPT

iptables -nvL
Chain INPUT (policy ACCEPT 273 packets, 28180 bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination
    0     0 ACCEPT     all  --  *      *       0.0.0.0/0            0.0.0.0/0            ctstate RELATED,ESTABLISHED
    0     0 ACCEPT     all  --  wg0    eth0    0.0.0.0/0            0.0.0.0/0

Chain OUTPUT (policy ACCEPT 217 packets, 33180 bytes)
 pkts bytes target     prot opt in     out     source               destination

Last edited by LinG (2021-04-09 17:55:33)

respiranto · 2021-04-08 02:50:40

Whats the `ip route' on the client?

The firewall seems very permissive, you probably should at least change the default FORWARD policy to DROP or REJECT--but that is irrelevant to getting the connection up.

LinG · 2021-04-08 17:01:36

Before I activate the iptables rules on the server (so I can still ping 10.0.0.1 the server from the client)

ip route
default via 192.168.2.254 dev wlan0 proto dhcp metric 600 
default via 10.0.0.1 dev vpn proto static metric 20050 
10.0.0.0/24 dev vpn proto kernel scope link src 10.0.0.2 metric 50 
192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.57 metric 600

(192.168.2.254 is the IP of the router at my home where both my client and server are connected too)

After I activate the iptables rules on the server (now I can no longer ping 10.0.0.1 the server from the client)

ip route
default via 10.0.0.1 dev vpn proto static metric 50 
default via 192.168.2.254 dev wlan0 proto dhcp metric 600 
10.0.0.0/24 dev vpn proto kernel scope link src 10.0.0.2 metric 50 
192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.57 metric 600

Also, if I then disable the iptables rules, the routes stay the same and don't go back and I can still not ping 10.0.0.1 the server.

If I then disconnect the wireguard interface on the client side and reconnect the routes are back to

ip route
default via 192.168.2.254 dev wlan0 proto dhcp metric 600 
default via 10.0.0.1 dev vpn proto static metric 20050 
10.0.0.0/24 dev vpn proto kernel scope link src 10.0.0.2 metric 50 
192.168.2.0/24 dev wlan0 proto kernel scope link src 192.168.2.57 metric 600

and I can ping the server again.

I also saved the iptables routes (using iptables-save) for easy on and off, here is the content

cat /etc/iptables/iptables.rules
# Generated by iptables-save v1.8.7 on Tue Apr  6 16:46:06 2021
*nat
:PREROUTING ACCEPT [11:2616]
:INPUT ACCEPT [11:2616]
:OUTPUT ACCEPT [2:301]
:POSTROUTING ACCEPT [0:0]
-A POSTROUTING -o eth0 -j MASQUERADE
COMMIT
# Completed on Tue Apr  6 16:46:06 2021
# Generated by iptables-save v1.8.7 on Tue Apr  6 16:46:06 2021
*filter
:INPUT ACCEPT [164:15250]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [98:13677]
-A FORWARD -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -i wg0 -o eth0 -j ACCEPT
COMMIT
# Completed on Tue Apr  6 16:46:06 2021

The firewall seems very permissive, you probably should at least change the default FORWARD policy to DROP or REJECT--but that is irrelevant to getting the connection up.

You mean the output of iptables -S where it says -P FORWARD ACCEPT ?

Last edited by LinG (2021-04-08 17:04:38)

LinG · 2021-04-08 21:19:37

I was using the external IP address of the server (so the IP address I was assigned by the ISP provider and port forwarded the port that I use for the wireguard interface). If I change the endpoint of the server peer on the client side to the local address (192.168.2.1) then suddenly it all works.

Why doesn't it work with the external IP address while both server and client are on the same local network? (Because the goal is to be able to use it outside of home using the external IP address, does that work?)

Last edited by LinG (2021-04-08 21:20:20)

progandy · 2021-04-08 22:37:23

Using the external IP from the local network requires support for hairpinning / nat loopback on your router

https://en.wikipedia.org/wiki/Hairpinning

Last edited by progandy (2021-04-08 22:39:27)

LinG · 2021-04-09 17:54:40

I never knew such a thing existed, thank you

respiranto · 2021-04-10 04:53:15

LinG wrote:

You mean the output of iptables -S where it says -P FORWARD ACCEPT ?

Yes.

Arch Linux

#1 2021-04-07 16:57:58