-
-
Notifications
You must be signed in to change notification settings - Fork 130
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] "Name does not resolve" when using Authentik OIDC #1558
Comments
if you |
It does resolve with If it helps to know the actual subnets:
I will point out that both RomM and Authentik are proxied through Caddy, but in a straightforward setup and networking-wise RomM and Authentik are no different than other Caddy reverse proxies I have that work fine, so I highly doubt it's Caddy causing a problem. And for IPs:
If it helps: I did read some Linux DNS resolvers have issues if IPv6 is not available, but they attempt both I have no problem like this anywhere else in my Proxmox or Docker infrastructure, so I'm led to believe this is a problem with the Docker image or its networking settings. I'm happy to try any troubleshooting options but I'm not sure what to attempt from here. |
I noted it works with Safari. That's true on one of my computers. On another, the Safari behavior is the same as Chrome and Firefox, so maybe there was lingering auth data that allowed it to succeed. |
So here's some more information, hopefully. I ran
In this example, I replaced my Authentik domain with This does follow the pattern I saw earlier: RomM attempts a DNS lookup of both the IPv4 and IPv6 addresses for Authentik. The IPv6 request happens to return first and correctly replies with a failed lookup, even though the IPv4 request succeeds, also as expected. Like I suggested in my original issue, this almost sounds like a race condition in which the IPv6 request happens to return first, and instead of the DNS resolver waiting for both requests to complete, it just immediately gives up once it sees any failure. A fix for my specific case may be to disable IPv6 lookups entirely. I'm not sure how to do that, especially without changing kernel settings on the host Proxmox server which I don't want to do; I'm fine changing system settings in the LXC or the Docker containers where possible. But, if indeed the issue is the resolver failing on any resolution error instead of all resolution errors, both IPv4 and IPv6, that sounds more like a library or system/container problem and that should be fixed instead. edit: (╯°□°)╯︵ ┻━┻ Okay I have no idea what the hell is happening. On my one computer where Safari works fine for Authentik logins to RomM, the |
I'm using a similar set up (AD being local DNS, Opensense + Unbound + HAproxy for reverse proxy in a different machine, firewall and external DNS). Authentik and Romm do not talk to each other, except through the proxy. I disabled Ipv6 on my DNS and removed all AAAA records just to test. Stopped all stacks and restarted them. I was still able to connect with Authentik internally and externally. I'm using Firefox for the browser. I had a problem with Authentik before with Romm, the cause was a space somewhere in the compose, hence why I'm sharing mine below, if that could help. My compose for reference and the .env file. (I only included romm)
stack.env
HA Proxy backend:
Authentik provider uses Signing Key self signed certificate. Hope that helps. First message on github, hope I didn't break any convention / standards. |
Well this is interesting. I looked at your config and compared to mine. I have no trailing slash on my I have no clue why that could cause a DNS resolution error in the logs unless the error is a lie and it's actually a 404 or something. I will keep monitoring to see if this actually fixed the problem or it's a fluke. Regardless, I don't think RomM should emit this kind of error if the |
Happy you got it potentially working : ) Just to note, this may be linked to that issue: |
RomM version
3.7.3
Describe the bug
I cannot get Authentik SSO login to work. When attempting to log in using the "Login with Authentik" button on the login page, I get "Internal server error" and the
romm
container emits a massive stack trace ultimately referencing failed DNS resolution.I censored the domain that it tries to resolve for privacy, but the domain definitely resolves properly on both my LAN and over the internet. On my LAN, it resolves to a
CNAME
that itself points to anA
record. On the internet, it resolves straight to anA
record. I updated my internal DNS to use anA
record as a test, but it made no difference. My DNS does not offer an IPv6 address by design.My RomM instance otherwise works properly when I use a local login. This error occurs only after I'm logged in via Authentik; i.e., I only see it once I'm either already logged into my SSO or, if I'm logged out, after I submit the login form in Authentik. If I'm not logged into the SSO and I click "Login with Authentik", I see the SSO login, but it fails once I submit the login.
I'm absolutely sure I'm using the same client ID and secret in my Authentik provider setup and in the
docker-compose.yml
.Coincidentally or not, the login via Authentik does work in Safari. Why I have no idea: it fails in Firefox and in Chrome. I have several extensions in Firefox, but none in Chrome, plus the DNS resolution error is server-side. I speculate there's some race condition where the
A
record resolves first before theAAAA
resolution fails (as expected).The container log is attached. My
docker-compose.yml
as follows. I'm running Docker in a Proxmox LXC. None of the other services I run in any other containers or VMs have this problem.When I'm in the Proxmox LXC,
dig mydomain
works fine.To Reproduce
Set up Authentik login in
docker-compose.yml
and an OIDC provider and application in Authentik. Attempt to log into RomM via Authentik and, when a user is logged into Authentik, requests to RomM fail.Expected behavior
Logging in via Authentik should redirect via OIDC successfully.
Screenshots
n/a
Desktop (please complete the following information):
Additional context
Add any other context about the problem here.
The text was updated successfully, but these errors were encountered: