no listen url was specified for the etcd cluster TLS manager, new wag servers will not be able to join

[ForestCat4]

Fresh plain vanilla Ubuntu 24.02 desktop install
Fully operational wireguard
No docker, etc
After following the only two sets of wag install instructions on the internet carefully,
From terminal as root after running ./wag start -config config.json I get this
"no listen url was specified for the etcd cluster TLS manager, new wag servers will not be able to join"

Neither site lists that as an expected/normal output. Is it?

Afterward, running , for example: ./wag version , I see:
"Get "http://unix/version": dial unix /tmp/wag.sock: connect: no such file or directory

Just trying for a bare minimum test install, without ssl, certs, Public-accessible webserver, etc. I wanted to add that after I get the management ui up. Is that possible?

Thanks!

Here's my config.json

{
  "Proxied": false,
  "ExposePorts": null,
  "HelpMail": "info@foo.com",
  "Lockout": 5,
  "ExternalAddress": "<my_WAN_ip",
  "MaxSessionLifetimeMinutes": 1440,
  "SessionInactivityTimeoutMinutes": 60,
  "ManagementUI": {
        "ListenAddress": "127.0.0.1:4433",
        "Enabled": true,
        "Debug": false
  },
  "Webserver": {
    "Public": {
      "ListenAddress": ":8080"
    },
    "Tunnel": {
      "Port": "80"
    }
  },
  "Authenticators": {
    "Issuer": "Wireguard",
    "Methods": ["totp"],
    "DomainURL": "",
    "OIDC": {
      "IssuerURL": "",
      "ClientSecret": "",
      "ClientID": ""
    }
  },
  "Wireguard": {
    "DevName": "wg0",
    "ListenPort": 51820,
    "PrivateKey": "<myKey>",
    "Address": "10.10.88.1/24",
    "MTU": 1420,
    "ServerPersistentKeepAlive": 25,
    "DNS": ["8.8.8.8"]
  },
  "DatabaseLocation": "devices.db",
  "Acls": {
    "Groups": {
      "group:admin": ["foobar"]
    },
    "Policies": {
      "group:admin": {
        "Mfa": ["172.69.0.0/16", "172.63.0.0/16"],
        "Allow": ["0.0.0.0/0", "::/0"]
      }
    }
  }
}

[NHAS]

You're missing the clustering block.

    "Clustering": {
        "ClusterState": "new",
        "ETCDLogLevel": "error",
        "ListenAddresses": [
            "https://127.0.0.1:2380"
        ],
        "TLSManagerListenURL": "https://127.0.0.1:3434"
    },

[NHAS]

Entirely understandable that you thought it was only for clusters. Unfortunately wag needs to set up a cluster of size 1 even when you're not clustering it with other members. But thats just semantics.

For your curl command, looks like you just didnt run it as root to overwrite the binary.

Also congratulation you've found a panic which is almost certainly a bug so Im going to open that on your behalf.

[ForestCat4]

Glad to help, sorry to make extra work for you, lol.
It is interesting that if I add the clustering block, I get the panic. If I remove the block, no panic.
re: curl, if I run that from a terminal as root (su, not sudo), that's when I get the permission denied, etc. Seems strange to me, since I'm cd'd to /opt/wag, and one would think curl has the rights of the user that runs it???? I can create/delete/edit in that folder in the same terminal session that I try to curl from.

In any case, is there something further I can test to get this running, or, alternatively, is there a known-compatible environment I can create to run it? I have plenty of hardware to load a known-working distro/version on. Doesn't matter to me which distro. The box will be dedicated to wg/wag.

[JSmith-Aura]

Finding a panic is a good thing not a bad thing.

The reason its panicing if you add the cluster is because the configuration is valid and thus it tries to parse your ACLs which then causes it to panic. Unfortunately the reason for the panic is not particularly clear, I've added a patch on the unstable branch but I couldnt replicate this bug on my machine.

If you feel comfortable running the unstable branch you could run it via docker.

---
services:
  wag:
    image: ghcr.io/nhas/wag:unstable
    container_name: wag
    restart: always
    ports:
      - 11371:11371/udp
    cap_add:
      - NET_ADMIN
     ports:
      - # ADD YOUR PORTS HERE
    volumes:
      - ./wag/config/:/cfg/:z # PUT YOUR CONFIG.JSON in ./wag/config/config.json
      - ./wag/data/:/data:z
    devices:
      - /dev/net/tun:/dev/net/tun

[ForestCat4]

I've been able to make a fair bit of progress on this over the past week, but I need to know something before I spin my tires too much longer:
Is there any way, just for testing purposes, that I can set this up with the "host" computer behind a residential isp with a dynamic ip?
I got as far as setting up a dynamic dns hostname and testing it, however my stinking rotten useless isp (cablevision/optonline) is blocking port 80, hence no acme/letsEncrypt/etc that I've been able to figure out yet.

re: wag itself, could you verify a couple of my assumptions?

1 Wag instantiates its own wg interface, and is much happier if there are no pre-exisiting (ie wg0) interfaces.
2 Wag does not depend on or consider any other(pre-existing) wg conf information outside of its own json.
3 Wag allows the actual wireguard tunnel to be established, and then uses MFA to control access to ip resources using iptables, etc.
4 A private key generated on the host machine via wg genkey is sufficient for conf.json. From that point on, wag handles all key generation/management.

I reached a point where a peer laptop using a wag-generated conf was able hit the host with the first packet (tcpdump), every 5 seconds or so, but with no reply/ack.
It is important to note that another wg interface on the host, when enabled, works fine w/ that laptop using its matching wg conf.

if assumption 3 above is correct, then I'm guessing there's maybe a key issue.

In any case, can I make this work temporarily (just for testing) without domains/certs/etc, using my dynamic WAN ip(which doesn't change much)?
Thanks again!

[NHAS]

Hi @ForestCat4, you've probably moved on to other things since this issue was last visting.

But wag supports DNS-01 ACME, which means if you have a domain that you control you can issue certificates without having to have any port open at all.

1. Wag does indeed create its own wireguard tunnel interface. It doesnt care if there are pre-existing wireguard interfaces, just as long as you're not trying to create two with the same name.
2. Yes, wag doesnt need you to do anything other than configure it
3. Vaguely, wag manages wireguard devices and has a custom built firewall that you apply policies to that allow/disallow traffic based on authentication state
4. Yes just a private key, and probably some policy to say that your clients can hit something, by default the wag web UI is allowed through the firewall. Wag also sets up some iptables rules to protect the wag host itself, so unless you define ExposedPorts your clients will only be able to ping the wag host, and connect to its MFA portal

You can indeed make wag run without TLS, this will mean that some forms of authentication cant be used like webauthn (fido/u2f keys).
And notifications wont work.

Other than that it should be fine.

Sorry for the long response!