XPost: linux.debian.user
Copy:
debian-kde@lists.debian.org (
debian-kde@lists.debian.org)
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.
-----BEGIN PGP SIGNATURE-----
iQEzBAABCgAdFiEE2MpLFUnSpXcLz1fxosR1jloS3s0FAmdvCqUACgkQosR1jloS 3s01xAf+KZ9NfEdecOgn4VrW0f1v6nNNUNnNZ/bF2lRaN8rvepnUqD+KeNFKnwEo MkpxkPOEMVMqryK5yA6bYCdI/QEeg75NwS1BpSVMZNHGL/2kdYhBhX6M09viHPxC /bThebjlH5Nr2r/q2AvpmLU7MG2BWuduNN0wd/K/dWziwzsX+Wc9pCxRbtHmx7ji QVlo7aS/8i5kCwwes5uP4IMmYo+kletENmezRMkQaSke9R6QdOOULOAV4Ww+8mBd lhNPlQZ6SWZ3SxIPanEFQ4BbePr0j66jbi+H0eFV0gtbY2/ws5ClVa4jw43tbA3T DuAXE5JqBUhruzT+TtBPUGM4Us86Sg==
=QgKb
-----END PGP SIGNATURE-----
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)