1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER

  • wireguard setup issue

    From Rainer Dorsch@21:1/5 to All on Thu Dec 26 22:41:53 2024
    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
  • From Michael =?utf-8?B?S2rDtnJsaW5n?=@21:1/5 to All on Fri Dec 27 11:20:01 2024
    On 26 Dec 2024 22:41 +0100, from [email protected] (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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Michael =?utf-8?B?S2rDtnJsaW5n?=@21:1/5 to All on Fri Dec 27 22:30:01 2024
    On 27 Dec 2024 21:14 +0100, from [email protected] (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 [email protected] (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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)