On 26 Dec 2024 22:41 +0100, from m...@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
