mirror of
https://github.com/fosrl/pangolin.git
synced 2026-05-07 05:09:18 -05:00
[GH-ISSUE #1637] OCID fails with Authentik - how to troubleshoot? #10727
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/pangolin#10727
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @t984447 on GitHub (Oct 8, 2025).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/1637
Describe the Bug
First setup as a test in my homelab where I am currently using my internal DNS server and internal ACME.
I am having major issues authenticating towards pangolin via my IDP (Authentik) as I am getting the same issue each time which lacks clarity.
I believe this might be a bug but at the same time I am not sure if I am troubleshooting correctly.
Each time I try to login I can access my auth.magic.com page and authenticate successfully in authentik. However there seem to be something wrong with the callback step for OCID communication. When landing on pangolin or a resource protected by pangolin I get the below issue;
Checking .machinelogs.json I can see the following;
{ "level":"\u001b[31merror\u001b[39m", "message":"Failed to send request", "stack":"Error: Failed to send request at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:35:15) at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async OAuth2Client.validateAuthorizationCode (file:///app/node_modules/arctic/dist/client.js:66:24) at async validateOidcCallback (file:///app/dist/server.mjs:21681:20)", "timestamp":"2025-10-08T19:03:34.302Z" }A brief checklist;
My setup is as follows;
Environment
Proxmox 8.4 LXC
LXC: ubuntu-24.04-standard_24.04-2_amd64.tar.zst
fosrl/pangolin:1.10.1
traefik:v3.5
To Reproduce
I am not sure what might be the source but as I am doing allot of customization towards my Pangolin setup using
LXC, custom CA (and ACME) and all running locally.
Expected Behavior
I expect either the application to let my access the resource or have the logs show a detailed error message describing what the issue is.
@SigmaSquadron commented on GitHub (Oct 9, 2025):
I've also had issues with Kanidm since updating to 1.10.3. I am not using a custom CA (Kani works well with the Let's Encrypt certificates), so this is likely a Pangolin issue.
@SigmaSquadron commented on GitHub (Oct 9, 2025):
Could you try running with the log level set to
debugand see if this message appears in the log?b34c3db956/server/routers/idp/validateOidcCallback.ts (L165-L169)@t984447 commented on GitHub (Oct 9, 2025):
Logger set to debug and the message you refer to always comes before the error;
@t984447 commented on GitHub (Oct 9, 2025):
Also tried updating to latest and I get the same error and behaviour.
Pangolin Version:
fosrl/pangolin:1.10.3
Traefik Version:
traefik:v3.5.3
@SigmaSquadron commented on GitHub (Oct 9, 2025):
The issue points to this call:
b34c3db956/server/routers/idp/validateOidcCallback.ts (L171-L175)But I'm not sure why Arctic is failing to send the Oauth2 request. The upstream code hints at it not being able to access our Oauth2 providers, which is insane given the call immediately above works.
@t984447 commented on GitHub (Oct 9, 2025):
Its nice to know I was not alone as I thought I was going crazy :)
At first I thought it was a matter of trust since I am using my own CA server in my LAN, but seeing as you get the same with LE I am starting to think there might be network issues.
However for some reason it feels like its not sending anything but fails directly. Wondering if I should try a TCP dump from my LXC running only Pangolin too se what/where it tries to send packages.
@SigmaSquadron commented on GitHub (Oct 9, 2025):
Might also want to try a bisection assuming this doesn't depend on your db's state.
@t984447 commented on GitHub (Oct 10, 2025):
Ok, Never mind the TCP capture as forgot the HTTPS deal and I do not have a capturing solution atm.
@SigmaSquadron what do you mean with bisection?
My current pangolin setup is expendable since I haven't started using it yet.
@SigmaSquadron commented on GitHub (Oct 10, 2025):
A bisection is a debugging step powered by
git bisect. First, clone the Pangolin repository and set the first bisection commit to the last "known good" version, and set the first bad commit to the head of 1.10.2. Git will then move you to the commit exactly between the known good and known bad versions. On that commit, you can compile and run pangolin locally and set up OIDC. If it works, mark that commit as good and continue the bisection. If it doesn't work, mark that commit as a bad commit and continue until you find the first bad commit.I can't try this with my infrastructure since Kanidm hates running outside of production environments, and I'd get unrelated errors. I hope authentik isn't allergic to ad-hoc testing like this.
@t984447 commented on GitHub (Oct 13, 2025):
ah, I understand. Problem for me is that I have never had a "good functional" version as this is my first setup.
I guess I could just backtrack the docker images and see what works... but not sure if its an developed issue or something that never worked.
@SigmaSquadron commented on GitHub (Oct 13, 2025):
OIDC did work because I was successfully using it since version 1.8.
@t984447 commented on GitHub (Oct 14, 2025):
I tried running an older docker image, 1.9.0, and got the same issue. If I try 1.8.0 my setup will not even start with
my current setup. Seemingly there was a big change between 1.8-1.9 which were there are changes no related to the "config" folder (which I did try to swap out)
Only alternative left for me is to setup another LXC running specifically Pangolin 1.8.0 however I am not sure what the installer might have been changed since.
@MotaRaja commented on GitHub (Oct 14, 2025):
I am also having this issue with Pocket-ID. getting a timeout error when trying to authenticate with SSO
@Clementinox commented on GitHub (Oct 15, 2025):
I have authentik working using the following:
When creating a user, select the OICD provider and make sure under username you have the email of the authentik user.
Then under server admin, for the authentik provider, set identifier path to email
@t984447 commented on GitHub (Oct 15, 2025):
Unfortunate this does not make any difference for me, Ive tried already with a pre-made account.
Since I am using my own local selfsigned CA for most things I kind if suspect that the issue is related to either the CA not being trusted but there is no documentation of how to add custom CA truststore to anything.
For both Traefik and Pangolin I had to add custom lines in the docker-compose to replacing the ca-certificates file. Not sure if I missed anything. Another thing which bothers me is that all other applications I have locally works, such as Portainer, Zabbix or even OpenWebGUI. Most of which i had to add my own CA to a truststore for them to work.
Additionally I have noticed that Pangolin is the only application which does not ask for OpenID Configuration URL.
i.e https://auth.magic.com/application/o/pangolin/.well-known/openid-configuration
@t984447 commented on GitHub (Oct 15, 2025):
Reading more just now I notice the thread Cant delete user from pangolin that was created using OIDC via Authentik where the last comment by RJDavison mentions that the Autoprovisioning is not working as intended.
The main thing I am trying is auto-provisoning which sounds like a broken feature.
@SigmaSquadron commented on GitHub (Oct 18, 2025):
This seems to be unrelated to the issue OP and I are getting.
@t984447 commented on GitHub (Oct 18, 2025):
I had some time earlier today and tried the new version, 1.11.0, of Pangolin but alas.. no dice. Same error :(
Next would be to try setting up a new environment with 1.8.0 and my Authentik setup.
@dx911xd commented on GitHub (Oct 21, 2025):
Similar setup without custom ca certs but op provider is Zitedal with how to provided by pangolin, oidc works fine till 1.10.3 but broken in 1.11.0 and 1.11.1, whether auto provision on or off, none of the newer versions work. Same login error on pangolin UI.
@shanelord01 commented on GitHub (Oct 22, 2025):
I've tried setting Pocket ID up on both my unraid (over a Newt tunnel) and on the same server as Pangolin (where I set it up as a local site). Followed this: https://docs.pangolin.net/manage/identity-providers/pocket-id and this https://pocket-id.org/docs/client-examples/pangolin
In both instances, when I try and login to Pangolin selecting Pocket ID, I get a "There was a problem connecting to Pocket ID. Please contact your administrator."
I have followed the steps exactly, ensuring all fields are correct.
I have turned off Pangolin auth for the proxied https://auth.mydomain.com/ address
Still cannot get this to work.
I can login to Pocket ID without issue via the proxied https://auth.mydomain.com/ directly.
UPDATE: Just tested setting up Grafana using OAuth as per here and it works perfectly.
https://pocket-id.org/docs/client-examples/grafana
Note this is if I use username/password or other auth other than Pocket ID for Pangolin first. As soon as I go through Pangolin auth using Pocket ID it fails. So, if I am already logged into Pangolin, the auth for Grafana works.
So it seems to be a Pangolin issue.
@shanelord01 commented on GitHub (Oct 22, 2025):
Logs show Pangolin is talking to localhost. Is this expected?
@shanelord01 commented on GitHub (Oct 23, 2025):
OK. I have gotten this working, tested with Pocket ID set up on my Pangolin VPS.
TLDR;
Pangolin can't reach your public token URL (other OIDC apps you set can).
For Pangolin OIDC, use
http://pocket-id:1411/api/oidc/tokenToken URLFor anything else use the one provided by Pocket ID for the Token URL.
Steps:
ie replace https://pocketid.mydomain.com with your actual address
Setup your resource for Pocket ID as a "local site" resource, no auth.
Setup Pocket ID by logging in to the setup address which will be the url you setup in step 3 with a trailing /setup, ie https://pocketid.mydomain.com/setup
Do the steps detailed here https://docs.pangolin.net/manage/identity-providers/pocket-id but importantly when you get to the step of copying the credentials etc, only use the Client ID, Client Secret and Authorization URL from Pocket ID, you need to use this Token URL in Pangolin otherwise it will fail:
http://pocket-id:1411/api/oidc/tokenYou ONLY need to use this address for your Pangolin OIDC - any other apps use the one provided by Pocket ID.
Everything should now work. Pangolin login via auth works.
You can also setup additional OIDC Clients (like immich, Grafana etc) from Pocket ID and they will also function without issues. Just ensure they use the Token URL provided by PocketID.
@L0sWach0s commented on GitHub (Oct 26, 2025):
Hey!
Same issue here with Pangolin 1.11.1
Setup:
Yesterday evening, the setup was fine, changed nothing and today it stopped working.
2025-10-26T10:12:56+00:00 [error]: Failed to send request Stack: Error: Failed to send request at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:35:15) at processTicksAndRejections (node:internal/process/task_queues:105:5) at runNextTicks (node:internal/process/task_queues:69:3) at process.processImmediate (node:internal/timers:453:9) at process.callbackTrampoline (node:internal/async_hooks:130:17) at async OAuth2Client.validateAuthorizationCode (file:///app/node_modules/arctic/dist/client.js:66:24) at async validateOidcCallback (file:///app/dist/server.mjs:23235:20) Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/3/oidc/generate-url Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/3/oidc/validate-callback 2025-10-26T10:13:23+00:00 [error]: Failed to send request Stack: Error: Failed to send request at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:35:15) at process.processTicksAndRejections (node:internal/process/task_queues:105:5) at async OAuth2Client.validateAuthorizationCode (file:///app/node_modules/arctic/dist/client.js:66:24) at async validateOidcCallback (file:///app/dist/server.mjs:23235:20)Transfering my PocketID instance to the VPS is no option.
Any other ideas?
@LoganRupe commented on GitHub (Oct 29, 2025):
Same issue here, glad I'm not alone, Pangolin 1.11.1 going to Authentik:
@DenizSe commented on GitHub (Nov 2, 2025):
Same issue here, on 1.12.0 with Authentik 2025.10.0
| Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/3/oidc/generate-url
pangolin | Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/3/oidc/validate-callback
pangolin | 2025-11-02T21:42:54+00:00 [error]: Unexpected error response
pangolin | Stack: Error: Unexpected error response
pangolin | at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:74:11)
pangolin | at process.processTicksAndRejections (node:internal/process/task_queues:105:5)
pangolin | at async OAuth2Client.validateAuthorizationCode (file:///app/node_modules/arctic/dist/client.js:66:24)
pangolin | at async validateOidcCallback (file:///app/dist/server.mjs:24314:20) {"status":403}
@aweb-01 commented on GitHub (Nov 4, 2025):
Also getting this issue on 1.11.1 with Authentik 2025.10.0. It's relatively new I think, my configuration was working fine until recently.
Edit: interestingly this issue does not occur if I configure it to use a different instance of Authentik not configured as a resource in Pangolin.
@dx911xd commented on GitHub (Nov 4, 2025):
Find one work around for zitadel, delete the OIDC provider with system admin (local) account and add OIDC provider back after the upgrade. beware OIDC call back URL changes on pangolin side.
@t984447 commented on GitHub (Nov 5, 2025):
So I've been Testing a bit with both Keycloak and now PocketID and all seems to fail. Mind you these are fresh and new installation connected to Pangolin wich all seems to fail at the same step.
@seanalewine commented on GitHub (Nov 8, 2025):
I'm having the same issue with Pangolin v1.11.1, Pocket ID v1.14.0. OIDC was working flawlessly until a recent update to Pangolin. Pangolin and Pocket ID are deployed on seperate VPS so no using the docker network as a workaround. Error message of "Failed to send request" in logs like everyone else. I tried deleting the OIDC provider from Pangolin and starting from scratch with no success.
@t984447 commented on GitHub (Nov 10, 2025):
I am kind of lost here of how to troubleshoot.
There are even some other cases which seems to be the same issue but not sure, like the newest one being https://github.com/fosrl/pangolin/issues/1838
@L0sWach0s commented on GitHub (Nov 10, 2025):
I've opened a separate issue because this bug is not yet resolved.
The solution by @shanelord01 is a workaround that doesn't address the root cause,
and it doesn't work in my setup.
@skengerz commented on GitHub (Nov 11, 2025):
I solved this by updating pangolin to the latest version that was numbered 1.12.2 i was previously on v1.11.1 as was defined in the downloaded docker compose file.
@aweb-01 commented on GitHub (Nov 11, 2025):
I updated to 1.12.2, same issue:
@skengerz commented on GitHub (Nov 11, 2025):
It's been a couple days for me but i'm pretty sure the only changes i made in between experiencing the issue and it being resolved were changing the identifier path to preferred_username and changing the defined version in the docker compose file from 1.11.1 to latest, I've tried to retrace my steps but i can find anything additional that i changed. Sorry i could be of any help :( I hope your issue gets resolved.
@t984447 commented on GitHub (Nov 12, 2025):
Yea, I get you.
I tried updating to Pangolin 1.12.2 and Traefik 3.6.0 but as aweb-01, no dice.
@tylerobara commented on GitHub (Nov 18, 2025):
I had this a few months ago and at the time I traced the problem to a cloudflare proxy issue. I solved it by pointing pangolin directly to my WAN IP using extra hosts:
Now for some reason, Pangolin is not resolving to that IP even though its visible in the container's /etc/hosts. Nslookup from inside pangolin container keeps resolving to the cloudflare proxy ip. Hopefully a root cause is found.
@shrunbr commented on GitHub (Nov 19, 2025):
I get this same issue with Authelia but going over my tailscale network.
@t984447 commented on GitHub (Nov 19, 2025):
This is interesting, is that for the Pangolin Docker then?
And this is not having Authentik running through Pangolin?
@tylerobara commented on GitHub (Nov 19, 2025):
correct the extra hosts config is being applied to the pangolin container. Access to Authentik does not go through pangolin.
@t984447 commented on GitHub (Nov 19, 2025):
Tested this a bit now with PocketID both through Pangolin and direct to the IDP service.
Thanks tho for the added info.
Darn, Of all who experience the same issue it feels like there is no real correlation which confuzzled me.
@nmsw-phil commented on GitHub (Dec 2, 2025):
Same issue for me. Used to work with authentik, now getting:
I even deleted and recreated my IDP config in Pangolin, but it produces the same error.
@bobobado commented on GitHub (Dec 9, 2025):
I receive a very similar error to @nmsw. Please see below and let me know how I can troubleshoot. I have recreated the identity provider a few times but not luck. Thank you
@tastycarbon commented on GitHub (Dec 11, 2025):
Did adding the extra_hosts solve the issue for you? I have a similar error. My authentik instance is on my home lab and pangolin is on a vps. I added authentik as a resource with no platform SSO and i can access authentik without an issue. But going through pangolin's login page gives me an error.
@t984447 commented on GitHub (Dec 12, 2025):
No. None of my attempts has worked.
I have grounded to an halt and are looking for alternatives since Pangolin seems busted for me :(
Not sure if its all due to being all local lan with custom DNS, ACME server and no outside connections.
Updated to 1.13.0 today and still getting the same error after an "verification" is performed, not sure what "request" its trying to send where.
@BeastleeUK commented on GitHub (Dec 16, 2025):
Running 1.13.1 and just discovered this issue too, with authentik.
Even though I had this working previously I made the identifier path change and this fixed my issue. Thanks for posting this.
@collse commented on GitHub (Dec 16, 2025):
are you saying yours is working again? would you mind sharing what exactly you have changed?
@BeastleeUK commented on GitHub (Dec 16, 2025):
Hi, mine had the error seen in this comment. Mine had previously been working with authentik but for some reason wasn't any more. I updated the identifier path in the Pangolin IdP provider settings for authentik to be email from sub and it worked.
I don't think this is the fix everyone else needs but I am happy to try and help get it working if I can. I have my authentik on a separate host, connected as a site, but all URLs resolve via public DNS and Pangolin is proxying to it.
@tylerobara commented on GitHub (Dec 16, 2025):
No change here. Still getting
State verifiedfollowed byWith any of
preferred_username,sub, oremailfor identifier path. Based on Authentik logs, I don't suspect Pangolin is having trouble reaching Authentik.@bobobado commented on GitHub (Dec 17, 2025):
I made the change from "sub" to "email" in my Identity Provider but get the same error as previously. My issue might be different as my instance is not "failing to send" but generating an "unexpected error". Not sure how to proceed.
@fernando-madepa commented on GitHub (Dec 18, 2025):
I have the same problem but with Google on a self-managed system with Docker. After reviewing the problem, it appears that Docker with network bridge cannot resolve IPv6.
Inside the Pangolin Docker:
< content-type: text/html
< date: Thu, 18 Dec 2025 20:41:57 GMT
< server: scaffolding on HTTPServer2
< content-length: 0
< x-xss-protection: 0
< x-frame-options: SAMEORIGIN
< x-content-type-options: nosniff
< alt-svc: h3=":443"; ma=2592000,h3-29=":443"; ma=2592000
<
@collse commented on GitHub (Dec 22, 2025):
I have a similar issue but also see other messages
it seems like that. request to :3000 does not occur but there is no further option/guidance on how to troubleshoot.
My authentik is a resource behind pangolin, on a different host and the resource url is pointing at it if that helps.
@collse commented on GitHub (Dec 23, 2025):
just updated to 1.14.0 and it is still not working, error message now is slightly more descriptive
do any debug log options exist to dig into this further?
edit:
looking inside the pangolin container, am I correct in assuming the api service only runs on ipv6?
adding enable_ipv6: false to the docker compose networks: section ends with
^^ until I force-recreate
but then services still spawn listeners on ipv6 and not ipv4 inside the pangolin container
@L0sWach0s commented on GitHub (Dec 23, 2025):
Quick update:
Adding the extra_hosts solved my issue.
@L0sWach0s commented on GitHub (Dec 23, 2025):
and an other update... since switching back from Tailscale to newt, the issue appears again...
@robbbbbie commented on GitHub (Dec 23, 2025):
I got it working by doing the following:
@t984447 commented on GitHub (Dec 27, 2025):
I've since long switch to another solution but it seems that others are still coming back to this issue which is both sad and a bit refreshing.
While this has no effect on my setup I noticed that I had to disable IPV6 both in containers and Traefik somehow, but cannot remember what exactly I did. The LXC I had Pangolin in is since long erased.
I tried this with both Authentic and PocketID where non of them works. This would be tested with access to iDP both through Pangolin and not-through Pangolin. And since everything is handled in my local LAN atm there is no need for my to use Tailscale.
@collse commented on GitHub (Dec 28, 2025):
I have just spun up another stack this time with the licensed EE for homelab, same situation. The extra_hosts for the pangolin service does not do anything in my setup which is on a dynamic link with IP fixed until the connection resets which is hardly never, using the external IP as well as the internal for authentik here does not change the behaviour at all
the only difference now, I can see all the granted requests to Authentik as part of the logging, what I don't see are requests to the api/v1/ endpoints which shows to me it is not hitting the service.
@anzi-tech commented on GitHub (Jan 3, 2026):
This may or may not be helpful for anyone, but I recently updated and started getting the exact same error (OIDC was working perfectly fine for months until I had to restart the container) and output as @collse . I logged into Pangolin as the local admin and was messing with the URL for my Identity provider's (Authentik) Authorize URL and Token URL, which did not work at first. When I set them BACK to my original URLs (which were working before my restart), things started working again...
Sorry its not super informative, but the only logging change I see is that I am no longer getting:
I did NOT make any extra_hosts changes and am on v1.14.1 running in Podman.
@anzi-tech commented on GitHub (Jan 3, 2026):
In expanding on sketchy fixes that seem to have worked for me as well. Public access to my Authentik server routes through Pangolin (probably not ideal, but here we are). Toggling on and off the health check for my Public Authentik target also resolved the error in another test.
@bobobado commented on GitHub (Jan 4, 2026):
I've tried many suggestions recommended here but can't seem to get this working. I'm on the latest version of Pangolin and now get a similar but slightly different error when attempting to use authentik as the identity provider. The error is:
Any help is appreciated
@earthworm1 commented on GitHub (Jan 18, 2026):
@bobobado did you find a solution? I might have the same issue. Set the internal gerbil ip via extra_hosts: in the docker-compose file and disabled the health check.
When i try 'curl -v https:///.well-known/openid-configuration' from within the pangolin container, i can reach pocket-id behind newt, but get the 401 unauthorized error. From any other machine and from the pangolin host itself, i get a 200 without any errors. On my first try everything worked and i could provision my users. After a couple hours, it stopped working and i only get the 401.
@bobobado commented on GitHub (Jan 21, 2026):
@earthworm1 no I have not. I am still getting the same error and unable to use my external ID provider. Hoping for a fix at some point.
@kapuett commented on GitHub (Jan 23, 2026):
Got the same issue. Setup:
Forward to Authentik when logging into Pangolin via SSO works fine, then
Pangolin docker logs show same errors:
@BeastleeUK commented on GitHub (Jan 23, 2026):
Sorry if this was covered above, I'm chiming in whilst at work and haven't had a chance to read back through.
If you're running Pangolin and OIDC on the same host, then is the Pangolin instance running inside the Gerbil network stack and OIDC outside? If so then they localhost is not really the same place for them. You need to use an IP or a name that can be resolved to the OIDC service. maybe expose it using 127.0.0.1:port to the host, to prevent it being connected to externally, and then call the host IP and the port instead?
I stopped using Pangolin as I don't really need external access for more than sharing some photos now, so I can't test for you. I fixed my split tunnel DNS with Tailscale so authentik is always accessible to me on the go now, making Pangolin almost redundant. I'll come back to it again once I can be confident of isolation for Pangolin shared resources from the rest of my internal network, which wasn't the case when I was using it. My network design, not Pangolin's fault. I'll be following development and any issues I'm on but not actively using it.
@haydenhaydo commented on GitHub (Jan 25, 2026):
Having the same issue here, worked for a little while and then stopped a couple hours later when I went to login again. Setup and logs is identical to @kapuett
@collse commented on GitHub (Jan 26, 2026):
ok, just to close this up - I did a complete net new install of my instance with 1.15, though I believe to having configured everything as previously it works perfectly fine now
my setup
unify gw (ddns via cloudflare), ports forwarded as needed
DMZ Zone
Internal Zone
remote VPS
all clients internal and externally have access, pangolin is the forwarding proxy, I expose regular services via proxy as well, authentik is a public service on pangolin and the OCID points to the pangolin service name (fqdn)
Not sure if anything changed under the hood but it is working fine now
@aweb-01 commented on GitHub (Jan 27, 2026):
I finally spent a few hours digging into this and got this working on my setup.
TL;DR: in my identity provider setup I configured the authorization URL as the public facing url to authentik (i.e. https://auth.my.domain/application/o/authorize/), and set the token URL as my docker internal URL to the HTTP link for authentik (http://authentik:9000/application/o/token/).
I assume it needed to be the http instead of https because there isn't a cert for the internal domain. However with the traffic all being internal to docker I don't expect that to cause any issues.
Some other troubleshooting steps I found helpful:
running
docker exec pangolin curl -vk http://authentik:9000/application/o/token/,docker exec pangolin curl -vk https://auth.my.domain/application/o/token/, etc and checking the outputs. Ideally you'll get a HTTP/1.1 405 Method Not Allowed response. Anything else indicates problems with pangolin connecting to Authentik which needs to be troubleshot further.I tried various configurations of
extra_hosts: - "auth.my.domain:192.168.1.72"and while they were helpful in enabling pangolin to reach auth.my.domain, I still always got a 401 code when trying to curl it.Anyway hope this helps someone, good luck.
@t984447 commented on GitHub (Jan 27, 2026):
Very intresseting, now the questions then becomes. Was the HTTPS certificates from your own CA or from a public provider?
This is something that Ive suspected being an issue since I have my own CA internally which is also in use with my PocketID setup.
@aweb-01 commented on GitHub (Jan 27, 2026):
I use wildcard certs from let’s encrypt, but obviously they won’t be valid for internal docker traffic to https://authentik:9000 etc., thus the need for http.
Idk why pangolin has issues referencing domains behind its own traefik reverse proxy for Authentik but this seems to be an okay workaround.
@TheD3vilsAdvocate commented on GitHub (Feb 3, 2026):
2026-02-03T21:38:01+00:00 [error]: OIDC provider returned an unexpected response during token exchange {"status":401}
Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/1/oidc/generate-url
Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/1/oidc/validate-callback
2026-02-03T21:38:33+00:00 [error]: OIDC provider returned an unexpected response during token exchange {"status":401}
meh I'm tired after wasting 90 minutes on this. Tried almost every solution listed here. Not sure how to proceed.
@StillLoading commented on GitHub (Feb 10, 2026):
I've found a workaround some of you might be interested in.
My setup:
The issue was the same as others described. Login for all resources using Authentik was working fine, but login to Pangolin itself did not work.
I think the issue is due to the traffic looping back to itself on the VPS side. There might be some kernel parameter that solves this better, but I just took a hammer to it and just redirected the traffic inside the LXC back to the gerbil/traefik container.
Since the Pangolin container will resolve the Authentik DNS to the public IP of the VPS, the rule will just bounce it back into the docker container.
I've tested the same with editing the /etc/hosts file inside the containers, but that did not work for me.
@tjsalmon commented on GitHub (Feb 10, 2026):
An update to this thread. I had OIDC auth working for a week with Cloudflare, and then I started seeing the same error as some of you:
[error]: Failed to reach OIDC provider while exchanging authorization code {"error":"Failed to send request"}.A couple days ago I installed Tailscale on my VPS so that I could ssh via Tailscale and disable port 22. Since then I couldn't log in via my identity provider anymore. I just took Tailscale down on my VPS and sure enough, I'm able to log in again via the identity provider. I don't have a solution yet, but Tailscale was preventing my VPS from reaching the OIDC provider. My tailnet is also routed through a local DNS server for what it's worth.
@kapuett commented on GitHub (Feb 11, 2026):
Hey @StillLoading,
thanks providing your workaround. Gave this a go on my VPS and it doesn't work with docker (or I'm doing something wrong). Tried with putting it before
and after DOCKER target
error message and log outputs stay the same. Also tried adding
to both gerbil and pangolin containers, same results. But good to know it's working that way with LXC, maybe somebody with more docker networking knowledge can translate that.
@StillLoading commented on GitHub (Feb 12, 2026):
@kapuett Shouldn't be much of a difference between running docker inside LXC and on the VPS host itself. The issue is that you need to force the Authentik traffic from Pangolin back through itself. It should work from inside the container with the extra_hosts, but for me it didn't even if set in the hosts file directly. I didn't investigate that much further and just went fk it, I'm just gonna layer 3 redirect everything.
The easiest way to check if that is working, is by entering the Pangolin container and running curl against your authentik url. If you get a response you're good and you might have a different problem. And if not, you have the same issue I had. You can also check the Pangolin resource logs to see if any requests are getting through to your Authentik public resource when you try to login to Pangolin.
You also need to adjust your rules on the Authentik public resource, because the Pangolin authentication request will now come from the docker network. If you have any IP/geo restrictions setup you need add an allow rule for the docker network.
BTW, my iptables looks like this:
If I've got some spare time I might investigate this further since it feels like this should be solvable more elegantly. My guess is there is some kernel security preventing IP redirection to the host for traffic coming from docker/LXC.
@kapuett commented on GitHub (Feb 15, 2026):
Seems to be a different issue then:
Makes sense as when clicking
authentik login prompt works and only after login the message
shows.
@StillLoading commented on GitHub (Feb 15, 2026):
@kapuett If you're getting a 401 check your resource logs on pangolin, your rules might be blocking the request since its coming from an internal IP.
You might also want to check the Authentik logs when you click the login button to see if the request actually arrives there. If not, it's something in between that sends that 401 and you just have to figure out what.
@kapuett commented on GitHub (Feb 15, 2026):
The 401 in the curl isn't the issue. I can see the requests in my site's traefik for the initial auth prompt, but none for the error message. Something isn't properly routed. Reminds me of https://github.com/orgs/fosrl/discussions/2255
@StillLoading commented on GitHub (Feb 15, 2026):
Maybe I should have clarified a bit more. I was just saying getting that 401 was progress since now you can check the http routing.
I feel like you're almost there. I would just sanity check everything again to be sure. Maybe this little checklist will help you narrow down where the issue is right now.
@bignick8t3 commented on GitHub (Feb 17, 2026):
Came here to thank the last few days of comments.
I too have Pangolin on a VPS and Authentik local, Authentik goes via Pangolin RP over Newt, I kept getting a 401 after logging into Authentik from Pangolin.
Pangolin gui would give a key exchange error.
I had two rules in place in Pangolin for Authentik.
Disabling these made the authentication process work and I was able to login to Pangolin via Authentik.
In docker logs I saw the following:
Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/1/oidc/generate-url Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/1/oidc/validate-callbackThanks again to those who gave me a steer in the right direction, it's much appreciated.
@StillLoading commented on GitHub (Feb 17, 2026):
@bignick8t3 FYI you don't need to disable rules, just set it up like this
You can also set static IPs for the Pangolin containers in the compose files so you won't have to even allow the whole /16. Just check your resource logs for the deny when the rules are enabled to see what source IP was used.
The important part is that the Authentik resource cannot have SSO enabled or "Pass to Auth" rules. That simply won't work since you cannot authenticate against a service that needs to be authenticated by itself beforehand. Hope that makes sense.
@TheD3vilsAdvocate commented on GitHub (Feb 17, 2026):
Hey i FINALLY got it to work thanks god, thanks to some inputs from here
First, it appears that a) SSO has to be disabled ofc b) no geoblocking rules should be applied whatsoever. Otherwise it will not transfer information from one server to the other
Second, I set the "Identifier Path" to "preferred_username" and then it finally worked...
Thanks for all input!
@kapuett commented on GitHub (Feb 17, 2026):
@bignick8t3 how's your Authentik in the site setup, is it behind a reverse proxy as well and internally accessed via TLS? If so, how is it configured in Pangolin? That's my config, with authentik served via traefik on the site, TLS only:
@StillLoading thanks for the detailed steps. Here's what I got:
Much appreciate your support!
@j551n-ncloud commented on GitHub (Feb 17, 2026):
Guys thank you!! You guys really helped me a Lot 😊
@StillLoading commented on GitHub (Feb 18, 2026):
@kapuett It looks like your token URL is http not https, but I'm on mobile right now, I'll have to take a better look at your complete post on a bigger screen.
@kapuett commented on GitHub (Feb 18, 2026):
Well, that's embarassing: @StillLoading that was the issue. Thank you!
@StillLoading commented on GitHub (Feb 18, 2026):
No worries 😉, glad it works for you now.
@bignick8t3 commented on GitHub (Feb 19, 2026):
@StillLoading yep that got it, adding the local docker network as the second rule allows the geo blocks to still work.
Thanks again.
@TheD3vilsAdvocate commented on GitHub (Feb 27, 2026):
One thing that I found out is that you could still get geoblock to work without adding the local docker network by adding every country manually except yours.
Not that this is desirably in any way. But Pangolin could add a "block every country but mine" feature or nested rules or something.
@kapuett commented on GitHub (Feb 28, 2026):
I don't see how that would achieve anything else than:
RFC1918 addresses should not have a country code, so setting rules like you described doesn't make sense for that case. You can verify this with https://www.maxmind.com/en/geoip-demo.
So depending on how pangolin works, you'd need to add the docker IP CIDR before you deny everything else.
Apart from that, I think this issue should be closed. It doesn't seem there is a general issue and there is now lots of information in that thread on how to troubleshoot issues.
@LoganRupe commented on GitHub (Mar 14, 2026):
Circling back — I managed to resolve this in my setup (Pangolin + Authentik, both on an internal LAN with a private Step-CA).
The root cause for me was twofold:
This way the token request stays internal to the Docker network and hits Traefik directly. Hope this helps someone else stuck on the "Failed to send request" error.
Swap out the example domains/filenames obviously, but that covers both pieces of the fix.
@samanthavbarron commented on GitHub (Mar 21, 2026):
Thank you @LoganRupe! Fix (2) worked for me!
@github-actions[bot] commented on GitHub (Apr 5, 2026):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.
@Streetlamp123 commented on GitHub (Apr 13, 2026):
It would be nice if all requests to internal resouces did this automatically
@github-actions[bot] commented on GitHub (Apr 28, 2026):
This issue has been automatically marked as stale due to 14 days of inactivity. It will be closed in 14 days if no further activity occurs.