Some Feedback/help for anyone else trying to get this running

[Snuupy]

First of all, this is a great project!

I played with ionscale for a bit, I ran into an issue where I was unable to add machines without a tag. This was using the generated API key. The syntax was not the easiest to figure out, but I did manage it (for anyone else struggling to set this up):

# create tailnet
ionscale tailnets create --name USERNAME --addr https://ionscale.domain.tld --system-admin-key xxxxxx

# create auth-key
ionscale auth-keys create --tailnet USERNAME --addr https://ionscale.domain.tld --system-admin-key xxxxxx

There was some inconsistency between the docker documentation and the reference config, the keys that needs to be set in config.yaml are listen_addr and server_url.

public_addr, https_listen_addr, and https_listen_addr do not need to be set.

I had:

listen_addr: ":8080"
server_url: "https://ionscale.domain.tld"

and my reverse proxy pointing to those.

Can we get a web UI to manage tailnets? I assume this project was heading in that direction anyway but I wanted to ask.

[Snuupy]

Also, here is my docker-compose.yml since the repo only provides a Dockerfile

services:
  ionscale:
    container_name: ionscale
    volumes:
        - ./config.yaml:/etc/ionscale/config.yaml
        - ./data:/data
    ports:
        # - 80:80
        # - 443:443
        # - 8080:8080
        - 3478:3478/udp
    image: ghcr.io/jsiebens/ionscale:latest
    command: server --config /etc/ionscale/config.yaml
    networks:
        - default
        - swag
networks:
    swag:
        external: true

[jsiebens]

hi @Snuupy

Thanks for playing a bit with ionscale!

I'm aware that the lack of documentation can make it a bit difficult to get started. Hopefully, I can find the time to make some improvements there.

Regarding creating machines without tags.
I assume you didn't configure any OIDC provider. If so, a tailscale device cannot be linked to an 'identity/user/...'; hence, a tag is required.
Auth keys created with the system admin key will always require a tag because a system admin key doesn't represent an 'identity/user/...'

What version of ionscale are you using? The latest release (0.15.0) has some breaking changes, and the docs should be updated accordingly.

A minimal configuration looks like this:

listen_addr: ":443"
public_addr: "ionscale.domain.tld:443"
stun_public_addr: "ionscale.domain.tld:3478"

tls:
  acme: true
  acme_email: "<your email>"

database:
  url: "/data/ionscale.db?_pragma=busy_timeout(5000)&_pragma=journal_mode(WAL)"

keys:
  system_admin_key: "<a generated system admin key>"

docker run \
  -v $(pwd)/config.yaml:/etc/ionscale/config.yaml \
  -v $(pwd)/data:/data \
  -p 443:443 \
  -p 3478:3478/udp \
  ghcr.io/jsiebens/ionscale:0.15.0 server --config /etc/ionscale/config.yaml

With this configuration, the embedded DERP and STUN servers are enabled, and it can be used on, for example, a VPS with a public IP address and the domain ionscale.domain.tld pointing to the address.

The config will be slightly different if you are behind a reverse proxy and the server running ionscale is not publicly accessible.
I'm not sure (haven't tested this scenario yet), but I think connectivity issues can occur when the embedded STUN is not reachable.

The following should work in that case, assuming the reverse proxy will terminate SSL:

listen_addr: ":8080"
public_addr: "ionscale.domain.tld:443"

tls:
  disable: true

derp:
  server:
    disabled: true # disabled embedded DERP/STUN as the STUN port of ionscale is not publicly accessible
  sources:
    - https://controlplane.tailscale.com/derpmap/default # use tailscale DERP server or your own DERP server as the STUN port of ionscale is not publicly accessible

database:
  url: "/data/ionscale.db?_pragma=busy_timeout(5000)&_pragma=journal_mode(WAL)"

keys:
  system_admin_key: "<a generated system admin key>"

Hopefully, this clarifies things a little bit for the time being.

[Snuupy]

Thanks for the reply! I'll need some time to go through it all. Do you have any plans for a web UI?

[Snuupy]

Thanks for playing a bit with ionscale!

Thank you for making this project! The autogroups in ACLs are a must have and that drew me to this project.

I'm aware that the lack of documentation can make it a bit difficult to get started. Hopefully, I can find the time to make some improvements there.

No worries - a lot of projects have this problem too! That is why I tried to help document a working config :)

Regarding creating machines without tags. I assume you didn't configure any OIDC provider.

Correct.

If so, a tailscale device cannot be linked to an 'identity/user/...'; hence, a tag is required.

Ah, I see.

Auth keys created with the system admin key will always require a tag because a system admin key doesn't represent an 'identity/user/...'

understood - so I need to set up an OIDC provider first...

I am currently contemplating zitadel, gitea and authentik but have not yet made a decision. Did you have any suggestions for self-hosted OIDC?

What version of ionscale are you using?

latest (0.15.0)

With this configuration, the embedded DERP and STUN servers are enabled, and it can be used on, for example, a VPS with a public IP address and the domain ionscale.domain.tld pointing to the address.

Great! I do have DERP/STUN enabled. I haven't added a 2nd device yet (holding off until I set up OIDC) so I haven't been able to test the DERP/STUN.

The config will be slightly different if you are behind a reverse proxy and the server running ionscale is not publicly accessible. I'm not sure (haven't tested this scenario yet), but I think connectivity issues can occur when the embedded STUN is not reachable.

I don't think this will be a problem, it also was not a problem on headscale. As far as I'm aware, DERP is on port 443 and STUN is on port 3478. 443 is forwarded to nginx (or in my case, linuxserver/swag), and 3478 is open for UDP (compose file allows the udp port to connect without a reverse proxy) so STUN should work.

For reverse proxies, is it possible to reverse proxy UDP? I wonder if I should if it's possible.

assuming the reverse proxy will terminate SSL:

Yes, that's correct.

Hopefully, this clarifies things a little bit for the time being.

Thank you (again) for the reply! It seems I will have to do an OIDC spike prior to playing with this more. I will try to keep this thread in the loop but it may take some (a lot) of time.

[thomanhphuc]

Is there any basic guide for configuring OIDC ? I'm encountering an issue with Google Authentication:
'Authentication successful but you're not authorized to use any network.'