dsnet up does nothing
xxxserxxx opened this issue · comments
Everything from the tutorial seems to have run without hickup, but dsnet up
doesn't appear to do anything. The WG config generated for a peer was good, and the resulting wg-quick up <config>
command looks good on the peer. However, on node 0 -- where all of the commands to generate the json config, and the peer WG config was created -- no routing is established:
# dsnet up
# echo $?
0
# dsnet sync
# netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 m.n.o.p 0.0.0.0 UG 0 0 0 eth0
m.n.o.0 0.0.0.0 255.255.224.0 U 0 0 0 eth0
m.n.o.0 m.n.o.1 255.255.224.0 UG 0 0 0 eth0
# wg
interface: dsnet
public key: censored
private key: (hidden)
listening port: 51820
peer: censored
preshared key: (hidden)
allowed ips: 10.79.56.2/32, censored
peer: censored
preshared key: (hidden)
allowed ips: 10.79.56.3/32, censored
# cat /proc/sys/net/ipv4/ip_forward
1
No error, but no network and no information for the wg interface, as if it was never set up. I tried dsnet down
and up
a few times -- always exit code 0, but no change to the routing that I could detect. The wireguard data toggles in and out. I've made sure the 51820 port is open in the firewall (both TCP and UDP).
As I said, the WG config for the peer imported into wg-quick
beautifully and set up the routing correctly.
Node 0 is
- Linux Arch, kernel 5.15, x86_64
- wireguard 1.0
- dsnet 226c61a (Tue May 17 20:52:01 2022)
- compiled with Go 1.19
I will take a look, I just bumped all the deps so there might have been something in the old api that was silently broken
Can you try with sudo
@xxxserxxx
@naggie I don't see any errors when trying to do up
or down
without sudo
I'm not sure which direction would make most sense here, just simply check if we have root or check each permission required to perform a command.
@botto Sorry if it wasn't clear, but I was su'd to root (sudo su -
), so all commands in my example were run as root.
Which branch should we be building from? I just did a go install github.com/naggie/dsnet@latest
and it looks like what got installed was version v0.2.2. From the project latest releases, it looks like the most recent release is v0.6. The last change to go.mod
on the master branch was 7 months ago -- are you releasing from a different branch than master
?
EDIT: I don't know why go install
seems to grab v0.2.2, but it doesn't matter. I cloned the repo, made sure I was on a commit post v0.6
tag (last commit on the master branch), built it, and get the same result. dsnet
returns no errors, but also doesn't set up routing:
$ git log -1
commit f08433b23c87de70eb60dbb352b8ded00da61a9f (HEAD, origin/master, origin/HEAD)
Merge: 226c61a 4ea3809
Author: Cal Bryant <callan.bryant@gmail.com>
Date: Fri Aug 5 09:40:47 2022 +0100
Merge pull request #73 from naggie/remove_vendor
Removed vendor
$ go build -o ./dsnet ./cmd
$ sudo ./dsnet up && echo Success
Success
$ sudo ./dsnet sync && echo Success
Success
$ sudo wg
interface: dsnet
public key: censored
private key: (hidden)
listening port: 51820
peer: censored
preshared key: (hidden)
allowed ips: 10.79.56.2/32, fd00:1547:dac6:c500:4efb:bed6:3b62:474e/128
peer: censored
preshared key: (hidden)
allowed ips: 10.79.56.3/32, fd00:1547:dac6:c500:62bc:7655:8eb2:a784/128
$ netstat -rn
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
0.0.0.0 censored.1 0.0.0.0 UG 0 0 0 eth0
censored.0 0.0.0.0 255.255.224.0 U 0 0 0 eth0
censored.0 censored.1 255.255.224.0 UG 0 0 0 eth0
$ exit
Ok, a little more info: I ran the dsnet
server portion on a different computer, and it worked as expected, so you can rule out any recent commit bug. It is specific to this server (I have some other servers at this cloud provider I'm going to test -- maybe it's their VMs). That said, I've set up other networking on this machine, so there's nothing specifically preventing routing commands from working
While it may be not working as expected because of some external system thing, there's no information useful for debugging. It'd be nice if it logged an error if it was unable to set up the routing -- right now, it looks like every command is successful.
UPDATE Ran the machine as a client, and wg-quick returned RTNETLINK answers: Permission denied
. So definitely not an issue with dsnet
. From other research, it looks like systems that aren't able to use ipV6 have this issue. The fix may then be #36; I haven't yet tested what happens if I remove all ipV6 entries from the config, but if it prevents dsnet
from trying to set up ipV6 routes, it may solve the issue.
The fact that dsnet
is swallowing this error is something I believe could be improved. Documenting the fix for non-ipV6 systems would also be helpful. I'm closing this ticket in any case, but hopefully someone else who runs into this issue will find it helpful.
Yes, the errors being swallowed I've noticed as well. It's something I'm going to look at improving.
Quick update: deleting all ipv6 references made everything work.