`lore auth login` fails with "No authentication configured on server" despite correct server-side auth config; UDP/QUIC traffic to server never arrives

[Kon-Log]

Summary

lore auth login lores://<host>:41337 consistently fails with:

[Error] No authentication configured on server
`lore auth login` fails with "No authentication configured on server" despite correct server-side auth config; UDP/QUIC traffic to server never arrives
  at lore-revision\src\auth\login.rs:66:1

...even though the server has server.auth fully configured (jwt_issuer + jwk.endpoint pointing to a working OIDC provider), and we have ruled out every network-layer cause we can inspect from our side.

Environment

• loreserver version: 0.8.6+373 (also reproduced on 0.8.4)
• lore CLI version: 0.8.6 (Windows, x86_64-pc-windows-msvc)
• Server OS: Debian 13 (trixie), unprivileged LXC container
• Auth provider: self-hosted, embedded OIDC/Dex-based IdP (own OAuth2 issuer), JWKS at issuer's /keys path
• Reproduced identically across 3 separate test rounds (server v0.8.4, server v0.8.6 with old client, server v0.8.6 with new client)

Server config (server.auth section)

[server.auth]
jwt_issuer = "<our OIDC issuer URL>"

[server.auth.jwk]
endpoint = "<our OIDC issuer URL>/keys"

Server startup logs confirm this is loaded correctly:

auth: Some(AuthSettings { jwk: Some(JWKServiceSettings { endpoint: "<redacted>/keys" }), jwt_audience: None, jwt_issuer: Some("<redacted>") })

Unauthenticated requests to other endpoints are correctly rejected ("authorization header required"), so the JWT verification path itself works — the login/discovery path does not.

What we ruled out

We DNAT 41337/tcp and 41337/udp directly to the container (no reverse proxy in front for this port). Before filing, we verified:

1. Upstream firewall (hosting provider): explicit accept rule for 41337, protocol * (TCP+UDP), positioned before any discard rule.
2. NAT/DNAT: both 41337/tcp and 41337/udp forwarding rules present and correct at the host firewall.
3. Guest-level firewall: confirmed not enforced at all on this host — cannot be blocking anything.
4. Server socket state: ss -tulnp on the container confirms loreserver is listening on both tcp 0.0.0.0:41337 (LISTEN) and udp 0.0.0.0:41337 (UNCONN, bound).
5. TCP reachability: openssl s_client -connect <host>:41337 completes a full TLS handshake successfully (Verify return code: 0 (ok)) — TCP definitely reaches the server.
6. UDP reachability: we watched the NAT packet counter for the 41337/udp forwarding rule live across 5 consecutive lore auth login attempts. It stayed at 0 packets throughout, while the TCP counter for the same port>
7. Server-side logs show no entry at all for any of the login attempts — nothing errors, nothing logs a request, it's silent.

Question / suspected root cause

Given (6), our working theory is that lore auth login's "environment"/auth-discovery call is sent over QUIC (UDP) and that UDP transport either isn't reaching our server for a reason outside what we can inspect, or the client>

Could you confirm:

• Does lore auth login's discovery/environment check use QUIC/UDP, TCP-based gRPC, or both (e.g. QUIC with TCP fallback)?
• Is "No authentication configured on server" the correct message when the underlying transport fails, or should that surface a different error (e.g. NotSupported code 18, per the 0.8.6 changelog)?
• Any way to get more verbose client-side logging for the discovery step to distinguish "server said no auth" from "couldn't reach server"?

Happy to provide packet captures or run further diagnostics on request.