Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #276031 > unrolled thread

wireguard setup issue

Back to article view | Back to linux.debian.user

Contents

  wireguard setup issue Rainer Dorsch <ml@bokomoko.de> - 2024-12-26 23:20 +0100
    Re: wireguard setup issue Michael Kjörling <c9bc136c6063@ewoof.net> - 2024-12-27 11:20 +0100
      Re: wireguard setup issue Rainer Dorsch <ml@bokomoko.de> - 2024-12-27 21:20 +0100
        Re: wireguard setup issue Michael Kjörling <c9bc136c6063@ewoof.net> - 2024-12-27 22:30 +0100

#276031 — wireguard setup issue

[Multipart message — attachments visible in raw view] — view raw

Hello,

I have a Debian stable wireguard server (192.168.11.254) with IP forwarding 
and Debian stable wireguard client (192.168.11.4) with wireguard setup through 
the plasma network manager interface. The server setup works flawless with an 
Android wireguard client, therefore I suspect that the issue is on the client 
side.

I don't see an error message but I don't get responses to ping from client to 
server:

root@aura:/etc/wireguard# ping 192.168.11.254 
PING 192.168.11.254 (192.168.11.254) 56(84) bytes of data. 
^C 
--- 192.168.11.254 ping statistics --- 
5 packets transmitted, 0 received, 100% packet loss, time 4080ms 

root@aura:/etc/wireguard# 

Also I don't see an issue with the config:

root@aura:/etc/wireguard# wg    
interface: ionos 
 public key: +O9Ea+2W3B7ke14Y6+7QN8o8l3iObNd8xYy4lhz5Hhk= 
 private key: (hidden) 
 listening port: 57832 
 fwmark: 0xcb7f 

peer: h41FylDIh3CnAyzsOhRVu/uzuU2gxMaQ5vDdqoXRkko= 
 endpoint: 87.106.44.192:51820 
 allowed ips: 0.0.0.0/0, ::/0 
 transfer: 0 B received, 2.31 KiB sent 
root@aura:/etc/wireguard# ip route 
default via 192.168.11.254 dev ionos proto static metric 50  
default via 192.168.178.1 dev wlo1 proto dhcp src 192.168.178.31 metric 600  
169.254.0.0/16 dev wlo1 scope link metric 1000  
192.168.11.0/24 dev ionos proto kernel scope link src 192.168.11.4 metric 50  
192.168.178.0/24 dev wlo1 proto kernel scope link src 192.168.178.31 metric 
600  
root@aura:/etc/wireguard# ip addr show dev ionos 
19: ionos: <POINTOPOINT,NOARP,UP,LOWER_UP> mtu 1420 qdisc noqueue state 
UNKNOWN group default qlen 1000 
   link/none  
   inet 192.168.11.4/24 brd 192.168.11.255 scope global noprefixroute ionos 
      valid_lft forever preferred_lft forever 
   inet6 fe80::f52b:51b5:4aeb:221e/64 scope link stable-privacy  
      valid_lft forever preferred_lft forever 
root@aura:/etc/wireguard# 


Any hint or idea what I am missing is welcome.

Thanks
Rainer

[toc] | [next] | [standalone]

#276037

On 26 Dec 2024 22:41 +0100, from ml@bokomoko.de (Rainer Dorsch):
> root@aura:/etc/wireguard# ping 192.168.11.254 
> PING 192.168.11.254 (192.168.11.254) 56(84) bytes of data. 
> ^C 
> --- 192.168.11.254 ping statistics --- 
> 5 packets transmitted, 0 received, 100% packet loss, time 4080ms 
> 
> root@aura:/etc/wireguard# 

Small detail, and quite possibly not relevant here, but when debugging
network issues, I always explicitly disable reverse DNS lookups with
ping using -n.


> Also I don't see an issue with the config:
> 
> root@aura:/etc/wireguard# wg    
> interface: ionos 
>  public key: +O9Ea+2W3B7ke14Y6+7QN8o8l3iObNd8xYy4lhz5Hhk= 
>  private key: (hidden) 
>  listening port: 57832 
>  fwmark: 0xcb7f 
> 
> peer: h41FylDIh3CnAyzsOhRVu/uzuU2gxMaQ5vDdqoXRkko= 
>  endpoint: 87.106.44.192:51820 
>  allowed ips: 0.0.0.0/0, ::/0 
>  transfer: 0 B received, 2.31 KiB sent 

No data received at all definitely suggests a problem with the tunnel
itself.

> root@aura:/etc/wireguard# ip route 
> default via 192.168.11.254 dev ionos proto static metric 50  
> default via 192.168.178.1 dev wlo1 proto dhcp src 192.168.178.31 metric 600  
> 169.254.0.0/16 dev wlo1 scope link metric 1000  
> 192.168.11.0/24 dev ionos proto kernel scope link src 192.168.11.4 metric 50  
> 192.168.178.0/24 dev wlo1 proto kernel scope link src 192.168.178.31 metric 
> 600  

Two default routes seems odd, though with the different metrics
shouldn't in itself be a huge issue. I haven't double-checked how
Wireguard sets up routes on tunnel activation.

Remember that a Wireguard key pair can only be used with exactly one
pair of endpoints at any one point in time. If you want to connect
from different endpoints, you need to set up separate key pairs or
make sure that any other endpoints using that key pair is disconnected
before connecting from elsewhere, or traffic won't flow properly.
Depending on how you set up the tunnel, that's definitely something I
would check.

-- 
Michael Kjörling
🔗 https://michael.kjorling.se

[toc] | [prev] | [next] | [standalone]

#276050

[Multipart message — attachments visible in raw view] — view raw

Thanks for your quick reply.

I didn't manage to get it working with the Plasma interface.

But importing a working wireguard profile 

root@aura:~# cat /etc/wireguard/wg0.conf
[Interface]
Address = 192.168.11.4/24
DNS = 5.1.66.255
ListenPort = 51820
PrivateKey = <private key>

[Peer]
PublicKey = h41FylDIh3CnAyzsOhRVu/uzuU2gxMaQ5vDdqoXRkko=
AllowedIPs = 0.0.0.0/0, ::/0
Endpoint = 87.106.44.192:51820
PersistentKeepalive = 20
root@aura:~# 


into network manager as described here https://blogs.gnome.org/thaller/
2019/03/15/wireguard-in-networkmanager/ worked well and I can enable and 
disable the interface through the plasma network applet/tray icon.

Thanks again
Rainer

Am Freitag, 27. Dezember 2024, 11:10:10 CET schrieb Michael Kjörling:
> On 26 Dec 2024 22:41 +0100, from ml@bokomoko.de (Rainer Dorsch):
> > root@aura:/etc/wireguard# ping 192.168.11.254
> > PING 192.168.11.254 (192.168.11.254) 56(84) bytes of data.
> > ^C
> > --- 192.168.11.254 ping statistics ---
> > 5 packets transmitted, 0 received, 100% packet loss, time 4080ms
> > 
> > root@aura:/etc/wireguard#
> 
> Small detail, and quite possibly not relevant here, but when debugging
> network issues, I always explicitly disable reverse DNS lookups with
> ping using -n.
> 
> > Also I don't see an issue with the config:
> > 
> > root@aura:/etc/wireguard# wg
> > interface: ionos
> > 
> >  public key: +O9Ea+2W3B7ke14Y6+7QN8o8l3iObNd8xYy4lhz5Hhk=
> >  private key: (hidden)
> >  listening port: 57832
> >  fwmark: 0xcb7f
> > 
> > peer: h41FylDIh3CnAyzsOhRVu/uzuU2gxMaQ5vDdqoXRkko=
> > 
> >  endpoint: 87.106.44.192:51820
> >  allowed ips: 0.0.0.0/0, ::/0
> >  transfer: 0 B received, 2.31 KiB sent
> 
> No data received at all definitely suggests a problem with the tunnel
> itself.
> 
> > root@aura:/etc/wireguard# ip route
> > default via 192.168.11.254 dev ionos proto static metric 50
> > default via 192.168.178.1 dev wlo1 proto dhcp src 192.168.178.31 metric
> > 600
> > 169.254.0.0/16 dev wlo1 scope link metric 1000
> > 192.168.11.0/24 dev ionos proto kernel scope link src 192.168.11.4 metric
> > 50 192.168.178.0/24 dev wlo1 proto kernel scope link src 192.168.178.31
> > metric 600
> 
> Two default routes seems odd, though with the different metrics
> shouldn't in itself be a huge issue. I haven't double-checked how
> Wireguard sets up routes on tunnel activation.
> 
> Remember that a Wireguard key pair can only be used with exactly one
> pair of endpoints at any one point in time. If you want to connect
> from different endpoints, you need to set up separate key pairs or
> make sure that any other endpoints using that key pair is disconnected
> before connecting from elsewhere, or traffic won't flow properly.
> Depending on how you set up the tunnel, that's definitely something I
> would check.

[toc] | [prev] | [next] | [standalone]

#276052

On 27 Dec 2024 21:14 +0100, from ml@bokomoko.de (Rainer Dorsch):
> I didn't manage to get it working with the Plasma interface.
> 
> But importing a working wireguard profile 
> 
> root@aura:~# cat /etc/wireguard/wg0.conf
> [Interface]
> Address = 192.168.11.4/24
> DNS = 5.1.66.255
> ListenPort = 51820
> PrivateKey = <private key>
> 
> [Peer]
> PublicKey = h41FylDIh3CnAyzsOhRVu/uzuU2gxMaQ5vDdqoXRkko=
> AllowedIPs = 0.0.0.0/0, ::/0
> Endpoint = 87.106.44.192:51820
> PersistentKeepalive = 20
> root@aura:~# 

Note that the local listening port seems to be different from that
mentioned in your original post in this thread:

On 26 Dec 2024 22:41 +0100, from ml@bokomoko.de (Rainer Dorsch):
> root@aura:/etc/wireguard# wg    
> interface: ionos 
>  public key: +O9Ea+2W3B7ke14Y6+7QN8o8l3iObNd8xYy4lhz5Hhk= 
>  private key: (hidden) 
>  listening port: 57832 
>  fwmark: 0xcb7f 

I'm not sure if this is _the_ difference, but it's certainly _a_
difference.

In general, when things don't work, it is a good idea to remove as
many layers of abstraction as one can, as you did here, and use the
raw tooling. Doing so will generally either (a) make the problem go
away, as it did for you, thus indicating that the additional tooling
did something you did not expect (if you want to use the additional
tooling, this narrows down what to look at because you're now only
looking for differences between what it does and what your raw tools
usage does); or (b) give you a simpler setup which still reproduces
the problem, making it easier for others to reproduce the issue you're
having.

-- 
Michael Kjörling
🔗 https://michael.kjorling.se

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user

csiph-web