Conversation

Notices

1. Embed this notice
   @Dwarf (dwarf@borg.social)'s status on Sunday, 29-Jan-2023 06:04:51 JST @Dwarf

   why is wireguard so vague in what it wants

   • Embed this notice
     @Dwarf (dwarf@borg.social)'s status on Sunday, 29-Jan-2023 06:09:58 JST @Dwarf

     in reply to

     1 server, 2 clients. client<->server works, but client->server->client seems to be completely dead with the message "ping: sendmsg: Destination address required".
     
     The wireguard logging only shows "wireguard: wg0: Handshake for peer 28 ((einval)) did not complete after 5 seconds, retrying (try 15)", which it shows on both peers.
     
     net.ipv4.ip_forward = 1 is on which is pretty much the only thing I can imagine would screw with things.
     
     #wireguard

   • Embed this notice
     Laplace Lopsided (laplace@infosec.exchange)'s status on Tuesday, 31-Jan-2023 00:38:20 JST Laplace Lopsided

     in reply to

     @dwarf I had a similar problem. My solution was to use a /32 or /128 netmask on the client.

     @Dwarf likes this.
   • Embed this notice
     @Dwarf (dwarf@borg.social)'s status on Tuesday, 31-Jan-2023 00:46:21 JST @Dwarf

     in reply to

     • 4censord

     @4censord@mstdn.social Yep, client{1,2} -> server works and server -> client{1,2} works too.
     
     The clients are set up as follows:
     server: 10.0.99.6
     client1: 10.0.99.3
     client2: 10.0.99.5
     
     The server and client{1,2} have all the peers listed with their respective public keys, but only have an Endpoint configured for the server. client2 has AllowedIPs = 10.0.99.3/32 set for client1 and AllowedIPs = 10.0.99.6/32 set for the server, so that should also be correct as far as I understand.
     
     I run just a normal ping:$ ping 10.0.99.3 PING 10.0.99.3 (10.0.99.3) 56(84) bytes of data. From 10.0.99.5 icmp_seq=1 Destination Host Unreachable ping: sendmsg: Destination address required I can also do a traceroute to the server just fine:$ traceroute 10.0.99.6 traceroute to 10.0.99.6 (10.0.99.6), 30 hops max, 60 byte packets 1 10.0.99.6 (10.0.99.6) 2.087 ms 2.085 ms 2.210 ms But traceroute 10.0.99.6 traceroute to 10.0.99.6 (10.0.99.6), 30 hops max, 60 byte packets 1 10.0.99.6 (10.0.99.6) 2.087 ms 2.085 ms 2.210 msBut not to client1:$ traceroute 10.0.99.3 traceroute to 10.0.99.3 (10.0.99.3), 30 hops max, 60 byte packets send: Destination address required

   • Embed this notice
     4censord (4censord@mstdn.social)'s status on Tuesday, 31-Jan-2023 00:46:23 JST 4censord

     in reply to

     @dwarf for me it works without problems. If you want, I can take a look at it later, but you would need describe your setup more.

     Does client{1,2} -> server on its own work?

     How are you calling ping, "destination address required" sounds more like e.g. it can't resolve the other host vie DNS.

   • Embed this notice
     @Dwarf (dwarf@borg.social)'s status on Tuesday, 31-Jan-2023 00:46:59 JST @Dwarf

     in reply to

     • 4censord

     @4censord@mstdn.social oops I ruined the paste :(

   • Embed this notice
     4censord (4censord@mstdn.social)'s status on Tuesday, 31-Jan-2023 01:51:54 JST 4censord

     in reply to

     @dwarf Can you remove
     * the peer config for client1 from client2
     * the peer config for client2 from client1

     It sounds for me like your clients are trying to connect to each other directly, instead of going via the server.

     This fails, because they don't have `Endpoints` configured for each other

     @Dwarf likes this.
   • Embed this notice
     @Dwarf (dwarf@borg.social)'s status on Tuesday, 31-Jan-2023 02:05:54 JST @Dwarf

     in reply to

     • 4censord

     @4censord@mstdn.social ha that makes my ISP router very confused because now I'm getting From <ISP_ROUTER_IP> icmp_seq=1 Packet filtered.
     
     I figured I'd add a route to fix that:
     10.0.99.0/24 via 10.0.99.6 dev wg0 proto static metric 24
     But then I run into:$ ping 10.0.99.3 PING 10.0.99.3 (10.0.99.3) 56(84) bytes of data. From 10.0.99.5 icmp_seq=1 Destination Host Unreachable ping: sendmsg: Required key not availableso it seems that's not the solution either ?

   • Embed this notice
     @Dwarf (dwarf@borg.social)'s status on Tuesday, 31-Jan-2023 02:45:55 JST @Dwarf

     in reply to

     • 4censord

     @4censord@mstdn.social My clients are set up with a /32 that matches the AllowedIPs in the other clients config, are you giving a /24 to every client?

   • Embed this notice
     4censord (4censord@mstdn.social)'s status on Tuesday, 31-Jan-2023 02:45:56 JST 4censord

     in reply to

     @dwarf I forgot: i have it set up with a /24

   • Embed this notice
     4censord (4censord@mstdn.social)'s status on Tuesday, 31-Jan-2023 02:45:58 JST 4censord

     in reply to

     @dwarf How is your clients `Address` set up?
     Is it a /32 with only the clients ip, or eg a /24?

     For me, the route with the wireguard interface looks like this:

     10.0.1.0/24 dev wg1 proto kernel scope link src 10.0.1.4 metric 50

   • Embed this notice
     @Dwarf (dwarf@borg.social)'s status on Tuesday, 31-Jan-2023 03:02:03 JST @Dwarf

     in reply to

     • 4censord

     @4censord@mstdn.social interesting, I'll give that a try!

   • Embed this notice
     4censord (4censord@mstdn.social)'s status on Tuesday, 31-Jan-2023 03:02:04 JST 4censord

     in reply to

     @dwarf No, I wasn't clear with what i meant.

     On the server, the client is configured like this:

     # Client 1
     [Peer]
     PublicKey = [...]
     AllowedIPs = 10.0.99.3/32

     So the client only gets a single address (/32).

     On the client side, it is set up like this:

     [Interface]
     Address = 10.0.99.3/24
     PrivateKey = [...]

     So the client has a single address (10.0.99.3), but knows its part of a /24 network.

     @Dwarf likes this.
   • Embed this notice
     @Dwarf (dwarf@borg.social)'s status on Tuesday, 31-Jan-2023 03:53:32 JST @Dwarf

     in reply to

     • 4censord

     @4censord@mstdn.social It's alive!! Thanks bunches :ablobcatheartsqueeze: