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;
Adding my own CA as trust to traefik and both docker containers ca-certificates.crt
Setting environment variable for both containers TZ: Europe/Stockholm (if it was a time issue since Pangolin container seem to be running two hours late)
Adding re-adding both provider and application in Authentik and IDP in Pangolin.
If I disable Authentication for a resource in Pangolin which also has its own SSO towards the same IDP it works. As in my Authentik installation works.
My setup is as follows;
Original setup where the auth page goes through Pangolin as a resource and the DNS pointing as Pangolin.
While auth DNS points towards pangolin I add extra_hosts: to Pangolin docker and points towards my IDP.
Redirect all traffic for auth page towards my IDP.
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.
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;
<img width="467" height="260" alt="Image" src="https://github.com/user-attachments/assets/1c2ea8af-55e4-450d-84d8-45d635bd1537" />
### 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;
- Adding my own CA as trust to traefik and both docker containers _ca-certificates.crt_
- Setting environment variable for both containers _TZ: Europe/Stockholm_ (if it was a time issue since Pangolin container seem to be running two hours late)
- Adding re-adding both provider and application in Authentik and IDP in Pangolin.
- If I disable Authentication for a resource in Pangolin which also has its own SSO towards the same IDP it works. As in my Authentik installation works.
### My setup is as follows;
1. Original setup where the auth page goes through Pangolin as a resource and the DNS pointing as Pangolin.
2. While auth DNS points towards pangolin I add _extra_hosts:_ to Pangolin docker and points towards my IDP.
3. Redirect all traffic for auth page towards my IDP.
<img width="1168" height="416" alt="Image" src="https://github.com/user-attachments/assets/73fa5caf-78cc-4f01-9c33-7e7b4eeeed9d" />
### Environment
1. OS Type & Version: (e.g., Ubuntu 22.04)
Proxmox 8.4 LXC
LXC: ubuntu-24.04-standard_24.04-2_amd64.tar.zst
2. Pangolin Version:
fosrl/pangolin:1.10.1
4. Traefik Version:
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.
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.
<!-- gh-comment-id:3383606904 -->
@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.
<!-- gh-comment-id:3383625454 -->
@SigmaSquadron commented on GitHub (Oct 9, 2025):
Could you try running with the log level set to `debug` and see if this message appears in the log?
https://github.com/fosrl/pangolin/blob/b34c3db956868c304dc727752211fccbd4e6dc21/server/routers/idp/validateOidcCallback.ts#L165-L169
logger.debug("State verified", {
urL: ensureTrailingSlash(existingIdp.idpOidcConfig.tokenUrl),
expectedState,
state
});
Logger set to debug and the message you refer to always comes before the error;
{
"level":"\u001b[34mdebug\u001b[39m",
"message":"GET /api/v1/user",
"timestamp":"2025-10-08T19:03:34.195Z"
}
{
"level":"\u001b[34mdebug\u001b[39m",
"message":"POST /api/v1/auth/idp/2/oidc/validate-callback",
"timestamp":"2025-10-08T19:03:34.277Z"
}
{
"expectedState":"wDRSowb_v3O1vywzxT1190jHHoaqggwoPg2Y0Ln0glk",
"level":"\u001b[34mdebug\u001b[39m",
"message":"State verified",
"state":"wDRSowb_v3O1vywzxT1190jHHoaqggwoPg2Y0Ln0glk",
"timestamp":"2025-10-08T19:03:34.280Z",
"urL":"https://auth.magic.com/application/o/token/"
}
{
"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"
}
<!-- gh-comment-id:3384041375 -->
@t984447 commented on GitHub (Oct 9, 2025):
> Could you try running with the log level set to `debug` and see if this message appears in the log?
>
> [pangolin/server/routers/idp/validateOidcCallback.ts](https://github.com/fosrl/pangolin/blob/b34c3db956868c304dc727752211fccbd4e6dc21/server/routers/idp/validateOidcCallback.ts#L165-L169)
>
> Lines 165 to 169 in [b34c3db](/fosrl/pangolin/commit/b34c3db956868c304dc727752211fccbd4e6dc21)
>
> logger.debug("State verified", {
> urL: ensureTrailingSlash(existingIdp.idpOidcConfig.tokenUrl),
> expectedState,
> state
> });
Logger set to debug and the message you refer to always comes before the error;
```
{
"level":"\u001b[34mdebug\u001b[39m",
"message":"GET /api/v1/user",
"timestamp":"2025-10-08T19:03:34.195Z"
}
{
"level":"\u001b[34mdebug\u001b[39m",
"message":"POST /api/v1/auth/idp/2/oidc/validate-callback",
"timestamp":"2025-10-08T19:03:34.277Z"
}
{
"expectedState":"wDRSowb_v3O1vywzxT1190jHHoaqggwoPg2Y0Ln0glk",
"level":"\u001b[34mdebug\u001b[39m",
"message":"State verified",
"state":"wDRSowb_v3O1vywzxT1190jHHoaqggwoPg2Y0Ln0glk",
"timestamp":"2025-10-08T19:03:34.280Z",
"urL":"https://auth.magic.com/application/o/token/"
}
{
"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"
}
```
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
<!-- gh-comment-id:3384753023 -->
@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
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.
<!-- gh-comment-id:3384907904 -->
@SigmaSquadron commented on GitHub (Oct 9, 2025):
The issue points to this call:
https://github.com/fosrl/pangolin/blob/b34c3db956868c304dc727752211fccbd4e6dc21/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.
```typescript
export async function sendTokenRequest(request: Request): Promise<OAuth2Tokens> {
let response: Response;
try {
response = await fetch(request);
} catch (e) {
throw new ArcticFetchError(e);
}
```
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.
<!-- gh-comment-id:3385488490 -->
@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.
Might also want to try a bisection assuming this doesn't depend on your db's state.
<!-- gh-comment-id:3385659636 -->
@SigmaSquadron commented on GitHub (Oct 9, 2025):
Might also want to try a bisection assuming this doesn't depend on your db's state.
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.
<!-- gh-comment-id:3388387142 -->
@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.
<!-- gh-comment-id:3388757762 -->
@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.
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.
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.
<!-- gh-comment-id:3398946320 -->
@t984447 commented on GitHub (Oct 13, 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.
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.
<!-- gh-comment-id:3399269749 -->
@SigmaSquadron commented on GitHub (Oct 13, 2025):
OIDC did work because I was successfully using it since version 1.8.
OIDC did work because I was successfully using it since version 1.8.
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.
<!-- gh-comment-id:3402559943 -->
@t984447 commented on GitHub (Oct 14, 2025):
> OIDC did work because I was successfully using it since version 1.8.
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.
I am also having this issue with Pocket-ID. getting a timeout error when trying to authenticate with SSO
<!-- gh-comment-id:3402705401 -->
@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
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
<!-- gh-comment-id:3404436392 -->
@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_**
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
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.
<!-- gh-comment-id:3404572039 -->
@t984447 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_**
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
The main thing I am trying is auto-provisoning which sounds like a broken feature.
<!-- gh-comment-id:3404581333 -->
@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](https://github.com/fosrl/pangolin/issues/1381) 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.
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.
<!-- gh-comment-id:3417997310 -->
@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.
<img width="912" height="390" alt="Image" src="https://github.com/user-attachments/assets/f7857a20-2c95-4393-a908-feb8bef0afa7" />
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.
<!-- gh-comment-id:3427097909 -->
@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.
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.
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.
<!-- gh-comment-id:3430784947 -->
@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.
Logs show Pangolin is talking to localhost. Is this expected?
root@pangolin:~# docker logs -f pangolin | grep -i oidc
Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/4/oidc/generate-url
Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/4/oidc/validate-callback
at async validateOidcCallback (file:///app/dist/server.mjs:22995:20)
<!-- gh-comment-id:3431020329 -->
@shanelord01 commented on GitHub (Oct 22, 2025):
Logs show Pangolin is talking to localhost. Is this expected?
```
root@pangolin:~# docker logs -f pangolin | grep -i oidc
Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/4/oidc/generate-url
Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/4/oidc/validate-callback
at async validateOidcCallback (file:///app/dist/server.mjs:22995:20)
```
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/token
You 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.
<!-- gh-comment-id:3435410487 -->
@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/token` Token URL
For anything else use the one provided by Pocket ID for the Token URL.
Steps:
1. Added the Pocket ID docker compose section to my Pangolin docker-compose.yml so that it's on the same docker network and can talk directly:
```
pocket-id:
image: ghcr.io/pocket-id/pocket-id:v1
container_name: pocket-id
restart: unless-stopped
env_file: ./config/pocket-id/.env
ports:
- 1411:1411
volumes:
- ./config/pocket-id:/app/data
- ./config/maxmind:/maxmind:ro
healthcheck:
test: [ "CMD", "/app/pocket-id", "healthcheck" ]
interval: 1m30s
timeout: 5s
retries: 2
start_period: 10s
networks:
- default
```
2. Make sure your domain for Pocket ID is setup correctly and matching what you will set in step 3 below in your ./config/pocket-id/.env file:
```
APP_URL=https://pocketid.mydomain.com
INTERNAL_APP_URL=https://pocketid.mydomain.com
TRUST_PROXY=true
```
ie replace https://pocketid.mydomain.com with your actual address
3. Setup your resource for Pocket ID as a "local site" resource, no auth.
4. 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
5. 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/token`
You 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.
Pocket ID (1.14.0) running on another site, connection via Pangolin is working fine.
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?
<!-- gh-comment-id:3448362259 -->
@L0sWach0s commented on GitHub (Oct 26, 2025):
Hey!
Same issue here with Pangolin 1.11.1
Setup:
- no newt, "local" connection via Tailscale
- Pocket ID (1.14.0) running on another site, connection via Pangolin is working fine.
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?
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.
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
2025-11-04T09:42:38+00:00 [error]: Unexpected error response
Stack: Error: Unexpected error response
at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:43:19)
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) {"status":401}
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.
<!-- gh-comment-id:3484952875 -->
@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.
```
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
2025-11-04T09:42:38+00:00 [error]: Unexpected error response
Stack: Error: Unexpected error response
at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:43:19)
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) {"status":401}
```
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.
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.
<!-- gh-comment-id:3487400174 -->
@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.
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.
Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/3/oidc/validate-callback
2025-11-05T19:55:44+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:24317:20)
<!-- gh-comment-id:3493084934 -->
@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.
```
Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/3/oidc/validate-callback
2025-11-05T19:55:44+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:24317:20)
```
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.
<!-- gh-comment-id:3507120259 -->
@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.
<!-- gh-comment-id:3512957322 -->
@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
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.
<!-- gh-comment-id:3513540553 -->
@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.
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.
<!-- gh-comment-id:3517935068 -->
@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.
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
2025-11-11T17:26:38+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:24361:20)
<!-- gh-comment-id:3518000630 -->
@aweb-01 commented on GitHub (Nov 11, 2025):
I updated to 1.12.2, same issue:
```
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
2025-11-11T17:26:38+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:24361:20)
```
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.
<!-- gh-comment-id:3518163075 -->
@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.
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.
Yea, I get you.
I tried updating to Pangolin 1.12.2 and Traefik 3.6.0 but as aweb-01, no dice.
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-11-12T08:28:35+01: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:24361:20)
<!-- gh-comment-id:3520679705 -->
@t984447 commented on GitHub (Nov 12, 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.
Yea, I get you.
I tried updating to Pangolin 1.12.2 and Traefik 3.6.0 but as aweb-01, no dice.
```
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-11-12T08:28:35+01: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:24361:20)
```
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.
<!-- gh-comment-id:3544766607 -->
@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:
```yaml
extra_hosts:
- "authentik.example.com:123.123.123.123"
```
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.
I get this same issue with Authelia but going over my tailscale network.
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
2025-11-18T21:23:45+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:31110:20)
Making login request to: http://localhost:3000/api/v1/auth/login
<!-- gh-comment-id:3550415135 -->
@shrunbr commented on GitHub (Nov 19, 2025):
I get this same issue with Authelia but going over my tailscale network.
```
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
2025-11-18T21:23:45+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:31110:20)
Making login request to: http://localhost:3000/api/v1/auth/login
```
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.
This is interesting, is that for the Pangolin Docker then?
And this is not having Authentik running through Pangolin?
<!-- gh-comment-id:3553733374 -->
@t984447 commented on GitHub (Nov 19, 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:
>
> extra_hosts:
> - "authentik.example.com:123.123.123.123"
> 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.
This is interesting, is that for the Pangolin Docker then?
And this is not having Authentik running through Pangolin?
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.
This is interesting, is that for the Pangolin Docker then? And this is not having Authentik running through Pangolin?
correct the extra hosts config is being applied to the pangolin container. Access to Authentik does not go through pangolin.
<!-- gh-comment-id:3553741128 -->
@tylerobara commented on GitHub (Nov 19, 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:
> > ```
> > extra_hosts:
> > - "authentik.example.com:123.123.123.123"
> > ```
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > 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.
>
> This is interesting, is that for the Pangolin Docker then? And this is not having Authentik running through Pangolin?
correct the extra hosts config is being applied to the pangolin container. Access to Authentik does not go through pangolin.
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.
This is interesting, is that for the Pangolin Docker then? And this is not having Authentik running through Pangolin?
correct the extra hosts config is being applied to the pangolin container. Access to Authentik does not go through pangolin.
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.
2025-11-19T20:46:07+01:00 [debug]: POST /api/v1/auth/idp/3/oidc/validate-callback
2025-11-19T20:46:07+01:00 [debug]: State verified {"urL":"https://pocket.magic.com/api/oidc/token","expectedState":"grGPSGk7HJ4PbU3MaFDJ-af_ZauR6DPfku2y-gUiZVU","state":"grGPSGk7HJ4PbU3MaFDJ-af_ZauR6DPfku2y-gUiZVU"}
2025-11-19T20:46:07+01: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:24361:20)
<!-- gh-comment-id:3554580444 -->
@t984447 commented on GitHub (Nov 19, 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:
> > > ```
> > > extra_hosts:
> > > - "authentik.example.com:123.123.123.123"
> > > ```
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > 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.
> >
> >
> > This is interesting, is that for the Pangolin Docker then? And this is not having Authentik running through Pangolin?
>
> correct the extra hosts config is being applied to the pangolin container. Access to Authentik does not go through pangolin.
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.
```
2025-11-19T20:46:07+01:00 [debug]: POST /api/v1/auth/idp/3/oidc/validate-callback
2025-11-19T20:46:07+01:00 [debug]: State verified {"urL":"https://pocket.magic.com/api/oidc/token","expectedState":"grGPSGk7HJ4PbU3MaFDJ-af_ZauR6DPfku2y-gUiZVU","state":"grGPSGk7HJ4PbU3MaFDJ-af_ZauR6DPfku2y-gUiZVU"}
2025-11-19T20:46:07+01: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:24361:20)
```
Same issue for me. Used to work with authentik, now getting:
Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/1/oidc/validate-callback
2025-12-02T12:47:42+01:00 [error]: Unexpected error response
Stack: Error: Unexpected error response
at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:74:11)
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:24361:20) {"status":403}
I even deleted and recreated my IDP config in Pangolin, but it produces the same error.
<!-- gh-comment-id:3601804034 -->
@nmsw-phil commented on GitHub (Dec 2, 2025):
Same issue for me. Used to work with authentik, now getting:
```
Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/1/oidc/validate-callback
2025-12-02T12:47:42+01:00 [error]: Unexpected error response
Stack: Error: Unexpected error response
at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:74:11)
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:24361:20) {"status":403}
```
I even deleted and recreated my IDP config in Pangolin, but it produces the same error.
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
Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/3/oidc/validate-callback
2025-12-09T00:29:13+00:00 [error]: Unexpected error response
Stack: Error: Unexpected error response
at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:43:19)
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:24361:20) {"status":401}
<!-- gh-comment-id:3629650940 -->
@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
```
Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/3/oidc/validate-callback
2025-12-09T00:29:13+00:00 [error]: Unexpected error response
Stack: Error: Unexpected error response
at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:43:19)
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:24361:20) {"status":401}
```
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.
This is interesting, is that for the Pangolin Docker then? And this is not having Authentik running through Pangolin?
correct the extra hosts config is being applied to the pangolin container. Access to Authentik does not go through pangolin.
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.
2025-11-19T20:46:07+01:00 [debug]: POST /api/v1/auth/idp/3/oidc/validate-callback
2025-11-19T20:46:07+01:00 [debug]: State verified {"urL":"https://pocket.magic.com/api/oidc/token","expectedState":"grGPSGk7HJ4PbU3MaFDJ-af_ZauR6DPfku2y-gUiZVU","state":"grGPSGk7HJ4PbU3MaFDJ-af_ZauR6DPfku2y-gUiZVU"}
2025-11-19T20:46:07+01: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:24361:20)
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.
<!-- gh-comment-id:3640073831 -->
@tastycarbon commented on GitHub (Dec 11, 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:
> > > > ```
> > > > extra_hosts:
> > > > - "authentik.example.com:123.123.123.123"
> > > > ```
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > 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.
> > >
> > >
> > > This is interesting, is that for the Pangolin Docker then? And this is not having Authentik running through Pangolin?
> >
> >
> > correct the extra hosts config is being applied to the pangolin container. Access to Authentik does not go through pangolin.
>
> 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.
>
> ```
>
> 2025-11-19T20:46:07+01:00 [debug]: POST /api/v1/auth/idp/3/oidc/validate-callback
> 2025-11-19T20:46:07+01:00 [debug]: State verified {"urL":"https://pocket.magic.com/api/oidc/token","expectedState":"grGPSGk7HJ4PbU3MaFDJ-af_ZauR6DPfku2y-gUiZVU","state":"grGPSGk7HJ4PbU3MaFDJ-af_ZauR6DPfku2y-gUiZVU"}
> 2025-11-19T20:46:07+01: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:24361:20)
> ```
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.
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.
This is interesting, is that for the Pangolin Docker then? And this is not having Authentik running through Pangolin?
correct the extra hosts config is being applied to the pangolin container. Access to Authentik does not go through pangolin.
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.
2025-11-19T20:46:07+01:00 [debug]: POST /api/v1/auth/idp/3/oidc/validate-callback
2025-11-19T20:46:07+01:00 [debug]: State verified {"urL":"https://pocket.magic.com/api/oidc/token","expectedState":"grGPSGk7HJ4PbU3MaFDJ-af_ZauR6DPfku2y-gUiZVU","state":"grGPSGk7HJ4PbU3MaFDJ-af_ZauR6DPfku2y-gUiZVU"}
2025-11-19T20:46:07+01: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:24361:20)
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.
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.
2025-12-12T21:40:53+01:00 [debug]: Resource allowed because no auth
Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/3/oidc/validate-callback
2025-12-12T21:40:54+01:00 [debug]: POST /api/v1/auth/idp/3/oidc/validate-callback
2025-12-12T21:40:54+01:00 [debug]: State verified {"urL":"https://pocket.magic.com/api/oidc/token","expectedState":"6rRT0PYEsOCrWg21wBXIfKUwsIpI6pWUUmI963juqZE","state":"6rRT0PYEsOCrWg21wBXIfKUwsIpI6pWUUmI963juqZE"}
2025-12-12T21:40:54+01: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:103:5)
at async OAuth2Client.validateAuthorizationCode (file:///app/node_modules/arctic/dist/client.js:66:24)
at async validateOidcCallback (file:///app/dist/server.mjs:30388:20)
<!-- gh-comment-id:3648245813 -->
@t984447 commented on GitHub (Dec 12, 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:
> > > > > ```
> > > > > extra_hosts:
> > > > > - "authentik.example.com:123.123.123.123"
> > > > > ```
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > 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.
> > > >
> > > >
> > > > This is interesting, is that for the Pangolin Docker then? And this is not having Authentik running through Pangolin?
> > >
> > >
> > > correct the extra hosts config is being applied to the pangolin container. Access to Authentik does not go through pangolin.
> >
> >
> > 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.
> > ```
> >
> > 2025-11-19T20:46:07+01:00 [debug]: POST /api/v1/auth/idp/3/oidc/validate-callback
> > 2025-11-19T20:46:07+01:00 [debug]: State verified {"urL":"https://pocket.magic.com/api/oidc/token","expectedState":"grGPSGk7HJ4PbU3MaFDJ-af_ZauR6DPfku2y-gUiZVU","state":"grGPSGk7HJ4PbU3MaFDJ-af_ZauR6DPfku2y-gUiZVU"}
> > 2025-11-19T20:46:07+01: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:24361:20)
> > ```
>
> 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.
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.
```
2025-12-12T21:40:53+01:00 [debug]: Resource allowed because no auth
Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/3/oidc/validate-callback
2025-12-12T21:40:54+01:00 [debug]: POST /api/v1/auth/idp/3/oidc/validate-callback
2025-12-12T21:40:54+01:00 [debug]: State verified {"urL":"https://pocket.magic.com/api/oidc/token","expectedState":"6rRT0PYEsOCrWg21wBXIfKUwsIpI6pWUUmI963juqZE","state":"6rRT0PYEsOCrWg21wBXIfKUwsIpI6pWUUmI963juqZE"}
2025-12-12T21:40:54+01: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:103:5)
at async OAuth2Client.validateAuthorizationCode (file:///app/node_modules/arctic/dist/client.js:66:24)
at async validateOidcCallback (file:///app/dist/server.mjs:30388:20)
```
Running 1.13.1 and just discovered this issue too, with authentik.
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
Even though I had this working previously I made the identifier path change and this fixed my issue. Thanks for posting this.
<!-- gh-comment-id:3660558080 -->
@BeastleeUK commented on GitHub (Dec 16, 2025):
Running 1.13.1 and just discovered this issue too, with authentik.
> 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_**
Even though I had this working previously I made the identifier path change and this fixed my issue. Thanks for posting this.
Running 1.13.1 and just discovered this issue too, with authentik.
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
Even though I had this working previously I made the identifier path change and this fixed my issue. Thanks for posting this.
are you saying yours is working again? would you mind sharing what exactly you have changed?
<!-- gh-comment-id:3660949524 -->
@collse commented on GitHub (Dec 16, 2025):
> Running 1.13.1 and just discovered this issue too, with authentik.
>
> > 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_**
>
> Even though I had this working previously I made the identifier path change and this fixed my issue. Thanks for posting this.
are you saying yours is working again? would you mind sharing what exactly you have changed?
Running 1.13.1 and just discovered this issue too, with authentik.
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
Even though I had this working previously I made the identifier path change and this fixed my issue. Thanks for posting this.
are you saying yours is working again? would you mind sharing what exactly you have changed?
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.
<!-- gh-comment-id:3661174341 -->
@BeastleeUK commented on GitHub (Dec 16, 2025):
> > Running 1.13.1 and just discovered this issue too, with authentik.
> > > 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_**
> >
> >
> > Even though I had this working previously I made the identifier path change and this fixed my issue. Thanks for posting this.
>
> are you saying yours is working again? would you mind sharing what exactly you have changed?
Hi, mine had the error seen in [this comment](https://github.com/fosrl/pangolin/issues/1637#issuecomment-3484952875). 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.
No change here. Still getting State verified followed by
2025-12-16T15:52:40+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:103:5)
at async OAuth2Client.validateAuthorizationCode (file:///app/node_modules/arctic/dist/client.js:66:24)
at async validateOidcCallback (file:///app/dist/server.mjs:30379:20)
With any of preferred_username, sub, or email for identifier path. Based on Authentik logs, I don't suspect Pangolin is having trouble reaching Authentik.
<!-- gh-comment-id:3661243244 -->
@tylerobara commented on GitHub (Dec 16, 2025):
No change here. Still getting `State verified` followed by
```
2025-12-16T15:52:40+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:103:5)
at async OAuth2Client.validateAuthorizationCode (file:///app/node_modules/arctic/dist/client.js:66:24)
at async validateOidcCallback (file:///app/dist/server.mjs:30379:20)
```
With any of `preferred_username`, `sub`, or `email` for identifier path. Based on Authentik logs, I don't suspect Pangolin is having trouble reaching Authentik.
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.
2025-12-17T17:02:16+00:00 [error]: Unexpected error response
Stack: Error: Unexpected error response
at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:43:19)
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:24361:20) {"status":401}
<!-- gh-comment-id:3666334264 -->
@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.
```
2025-12-17T17:02:16+00:00 [error]: Unexpected error response
Stack: Error: Unexpected error response
at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:43:19)
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:24361:20) {"status":401}
```
@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:
/app # curl -v https://oauth2.googleapis.com/token
* Host oauth2.googleapis.com:443 was resolved.
* IPv6: 2800:3f0:4003:c03::5f
* IPv4: 172.217.192.95
* Trying [2800:3f0:4003:c03::5f]:443...
* Immediate connect fail for 2800:3f0:4003:c03::5f: Address not available
* Trying 172.217.192.95:443...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519MLKEM768 / id-ecPublicKey
* ALPN: server accepted h2
* Server certificate:
* subject: CN=upload.video.google.com
* start date: Nov 24 08:40:14 2025 GMT
* expire date: Feb 16 08:40:13 2026 GMT
* issuer: C=US; O=Google Trust Services; CN=WR2
* Certificate level 0: Public key type EC/prime256v1 (256/128 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 1: Public key type RSA (2048/112 Bits/secBits), signed using sha256WithRSAEncryption
* Certificate level 2: Public key type RSA (4096/152 Bits/secBits), signed using sha384WithRSAEncryption
* subjectAltName: "oauth2.googleapis.com" matches cert's "*.googleapis.com"
* SSL certificate verified via OpenSSL.
* Established connection to oauth2.googleapis.com (172.217.192.95 port 443) from 172.18.0.2 port 52630
* using HTTP/2
* [HTTP/2] [1] OPENED stream for https://oauth2.googleapis.com/token
* [HTTP/2] [1] [:method: GET]
* [HTTP/2] [1] [:scheme: https]
* [HTTP/2] [1] [:authority: oauth2.googleapis.com]
* [HTTP/2] [1] [:path: /token]
* [HTTP/2] [1] [user-agent: curl/8.17.0]
* [HTTP/2] [1] [accept: */*]
> GET /token HTTP/2
> Host: oauth2.googleapis.com
> User-Agent: curl/8.17.0
> Accept: */*
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/2 404
I have a similar issue but also see other messages
pangolin | 2025-12-22T11:13:05+00:00 [info]: Pangolin gathers anonymous usage data to help us better understand how the software is used and guide future improvements and feature development. You can find more details, including instructions for opting out of this anonymous data collection, at: https://docs.pangolin.net/telemetry
pangolin | 2025-12-22T11:13:06+00:00 [info]: API server is running on http://localhost:3000
pangolin | 2025-12-22T11:13:06+00:00 [info]: Internal server is running on http://localhost:3001
pangolin | 2025-12-22T11:13:09+00:00 [info]: Next.js server is running on http://localhost:3002
pangolin | 2025-12-22T11:13:10+00:00 [info]: Updated exit node with reachableAt to http://gerbil:3004
pangolin | 2025-12-22T11:13:13+00:00 [info]: Establishing websocket connection
pangolin | 2025-12-22T11:13:13+00:00 [info]: Client added to tracking - NEWT ID: --redacted--, Connection ID: --redacted-----redacted-----redacted-----redacted-----redacted--, Total connections: 1
pangolin | 2025-12-22T11:13:13+00:00 [info]: WebSocket connection established - NEWT ID: --redacted-- pangolin | (node:19) [DEP0169] DeprecationWarning: url.parse() behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for url.parse() vulnerabilities. pangolin | (Use node --trace-deprecation ... to show where the warning was created)
gerbil | INFO: 2025/12/22 11:24:23 Cleared 0 sessions for WG IP: internal_proxy_ip
pangolin | Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/2/oidc/generate-url
gerbil | INFO: 2025/12/22 11:24:49 Cleared 0 sessions for WG IP: remote_ip
pangolin | Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/2/oidc/validate-callback
gerbil | INFO: 2025/12/22 11:25:23 Cleared 0 sessions for WG IP: internal_proxy_ip
pangolin | 2025-12-22T11:25:28+00:00 [error]: Failed to send request
pangolin | Stack: Error: Failed to send request
pangolin | at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:35:15)
pangolin | at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
pangolin | at async OAuth2Client.validateAuthorizationCode (file:///app/node_modules/arctic/dist/client.js:66:24)
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.
<!-- gh-comment-id:3681682952 -->
@collse commented on GitHub (Dec 22, 2025):
I have a similar issue but also see other messages
> pangolin | 2025-12-22T11:13:05+00:00 [info]: Pangolin gathers anonymous usage data to help us better understand how the software is used and guide future improvements and feature development. You can find more details, including instructions for opting out of this anonymous data collection, at: https://docs.pangolin.net/telemetry
> pangolin | 2025-12-22T11:13:06+00:00 [info]: API server is running on http://localhost:3000
> pangolin | 2025-12-22T11:13:06+00:00 [info]: Internal server is running on http://localhost:3001
> pangolin | 2025-12-22T11:13:09+00:00 [info]: Next.js server is running on http://localhost:3002
> pangolin | 2025-12-22T11:13:10+00:00 [info]: Updated exit node with reachableAt to http://gerbil:3004
> pangolin | 2025-12-22T11:13:13+00:00 [info]: Establishing websocket connection
> pangolin | 2025-12-22T11:13:13+00:00 [info]: Client added to tracking - NEWT ID: --redacted--, Connection ID: --redacted-----redacted-----redacted-----redacted-----redacted--, Total connections: 1
> pangolin | 2025-12-22T11:13:13+00:00 [info]: WebSocket connection established - NEWT ID: --redacted--
> **_pangolin | (node:19) [DEP0169] DeprecationWarning: `url.parse()` behavior is not standardized and prone to errors that have security implications. Use the WHATWG URL API instead. CVEs are not issued for `url.parse()` vulnerabilities._**
> **_pangolin | (Use `node --trace-deprecation ...` to show where the warning was created)_**
> gerbil | INFO: 2025/12/22 11:24:23 Cleared 0 sessions for WG IP: internal_proxy_ip
> pangolin | Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/2/oidc/generate-url
> gerbil | INFO: 2025/12/22 11:24:49 Cleared 0 sessions for WG IP: remote_ip
> pangolin | Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/2/oidc/validate-callback
> gerbil | INFO: 2025/12/22 11:25:23 Cleared 0 sessions for WG IP: internal_proxy_ip
> pangolin | 2025-12-22T11:25:28+00:00 [error]: Failed to send request
> pangolin | Stack: Error: Failed to send request
> pangolin | at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:35:15)
> pangolin | at process.processTicksAndRejections (node:internal/process/task_queues:103:5)
> pangolin | at async OAuth2Client.validateAuthorizationCode (file:///app/node_modules/arctic/dist/client.js:66:24)
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.
<!-- gh-comment-id:3686226595 -->
@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
> pangolin | 2025-12-23T11:05:01+00:00 [warn]: Request to fetch latest Olm version timed out (1.5s)
pangolin | Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/2/oidc/generate-url
pangolin | Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/2/oidc/validate-callback
gerbil | INFO: 2025/12/23 11:07:10 Cleared 0 sessions for WG IP: A.B.C.D
pangolin | 2025-12-23T11:07:20+00:00 [error]: Failed to reach OIDC provider while exchanging authorization code {"error":"Failed to send request"}
gerbil | INFO: 2025/12/23 11:07:23 Cleared 0 sessions for WG IP: B.C.E.F
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?
> tcp 0 0 :::3001 :::* LISTEN
tcp 0 0 :::3000 :::* LISTEN
adding enable_ipv6: false to the docker compose networks: section ends with
> traefik | 2025-12-23T11:47:42Z ERR Provider error, retrying in 7.947110033s error="cannot fetch configuration data: do fetch request: Get \"http://pangolin:3001/api/v1/traefik-config\": dial tcp: lookup pangolin on 127.0.0.11:53: read udp 127.0.0.1:47679->127.0.0.11:53: read: connection refused" providerName=http
traefik | 2025-12-23T11:47:50Z ERR Provider error, retrying in 23.9112726s error="cannot fetch configuration data: do fetch request: Get \"http://pangolin:3001/api/v1/traefik-config\": dial tcp: lookup pangolin on 127.0.0.11:53: read udp 127.0.0.1:39279->127.0.0.11:53: read: connection refused" providerName=http
^^ until I force-recreate
but then services still spawn listeners on ipv6 and not ipv4 inside the pangolin container
> tcp 0 0 :::3001 :::* LISTEN
tcp 0 0 :::3000 :::* LISTEN
tcp 0 0 :::3002 :::* LISTEN
and an other update... since switching back from Tailscale to newt, the issue appears again...
<!-- gh-comment-id:3687620100 -->
@L0sWach0s commented on GitHub (Dec 23, 2025):
and an other update... since switching back from Tailscale to newt, the issue appears again...
Manually create the user with User Type as the Identity Provider, and make sure under Username you have the email of the Authentik user
Within the General Settings of the Identity Provider under Token Configuration change the Identifier Path to email
Within the General Settings of the Identity ProviderdisableAuto Provision Users
<!-- gh-comment-id:3688154567 -->
@robbbbbie commented on GitHub (Dec 23, 2025):
I got it working by doing the following:
1. Manually create the user with **User Type** as the **Identity Provider**, and make sure under **Username** you have the **_email_** of the Authentik user
2. Within the General Settings of the **Identity Provider** under **Token Configuration** change the **Identifier Path** to **_email_**
3. Within the General Settings of the **Identity Provider** _disable_ **Auto Provision Users**
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.
Quick update: Adding the extra_hosts solved my issue.
and an other update... since switching back from Tailscale to newt, the issue appears again...
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.
<!-- gh-comment-id:3694011548 -->
@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.
> edit: looking inside the pangolin container, am I correct in assuming the api service only runs on ipv6?
>
> > tcp 0 0 :::3001 :::* LISTEN
> > tcp 0 0 :::3000 :::* LISTEN
>
> adding enable_ipv6: false to the docker compose networks: section ends with
>
> > traefik | 2025-12-23T11:47:42Z ERR Provider error, retrying in 7.947110033s error="cannot fetch configuration data: do fetch request: Get "[http://pangolin:3001/api/v1/traefik-config\](http://pangolin:3001/api/v1/traefik-config%5C)": dial tcp: lookup pangolin on 127.0.0.11:53: read udp 127.0.0.1:47679->127.0.0.11:53: read: connection refused" providerName=http
> > traefik | 2025-12-23T11:47:50Z ERR Provider error, retrying in 23.9112726s error="cannot fetch configuration data: do fetch request: Get "[http://pangolin:3001/api/v1/traefik-config\](http://pangolin:3001/api/v1/traefik-config%5C)": dial tcp: lookup pangolin on 127.0.0.11:53: read udp 127.0.0.1:39279->127.0.0.11:53: read: connection refused" providerName=http
>
> ^^ until I force-recreate
>
> but then services still spawn listeners on ipv6 and not ipv4 inside the pangolin container
>
> > tcp 0 0 :::3001 :::* LISTEN
> > tcp 0 0 :::3000 :::* LISTEN
> > tcp 0 0 :::3002 :::* LISTEN
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.
> Quick update: Adding the extra_hosts solved my issue.
> and an other update... since switching back from Tailscale to newt, the issue appears again...
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.
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.
<!-- gh-comment-id:3694728060 -->
@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
> pangolin | Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/1/oidc/generate-url
pangolin | Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/1/oidc/validate-callback
pangolin | 2025-12-28T12:53:49+00:00 [error]: Failed to reach OIDC provider while exchanging authorization code {"error":"Failed to send request"}
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.
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:
2026-01-03T20:15:23+00:00 [error]: Failed to reach OIDC provider while exchanging authorization code {"error":"Failed to send request"}
I did NOT make any extra_hosts changes and am on v1.14.1 running in Podman.
<!-- gh-comment-id:3707343816 -->
@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:
> 2026-01-03T20:15:23+00:00 [error]: Failed to reach OIDC provider while exchanging authorization code {"error":"Failed to send request"}
I did NOT make any extra_hosts changes and am on v1.14.1 running in Podman.
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.
<!-- gh-comment-id:3707366716 -->
@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.
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:
Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/4/oidc/generate-url
Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/4/oidc/validate-callback
2026-01-04T23:51:36+00:00 [error]: OIDC provider returned an unexpected response during token exchange {"status":401}
Any help is appreciated
<!-- gh-comment-id:3708545594 -->
@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:
```
Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/4/oidc/generate-url
Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/4/oidc/validate-callback
2026-01-04T23:51:36+00:00 [error]: OIDC provider returned an unexpected response during token exchange {"status":401}
```
Any help is appreciated
@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.
<!-- gh-comment-id:3765310801 -->
@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://<my pocket-id domain>/.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.
@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.
<!-- gh-comment-id:3779016394 -->
@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.
Authentik public resource proxied to my homelab through newt. No HC, no platform SSO. Services in the homelab all are behind traefik, reachable via https.
Forward to Authentik when logging into Pangolin via SSO works fine, then
There was a problem connecting to Authentik. Please contact your administrator.Unable to reach the identity provider while exchanging the authorization code. Please try again.
Pangolin docker logs show same errors:
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-01-23T05:18:01+00:00 [error]: Failed to reach OIDC provider while exchanging authorization code {"error":"Failed to send request"}
<!-- gh-comment-id:3788325468 -->
@kapuett commented on GitHub (Jan 23, 2026):
Got the same issue. Setup:
- Pangolin running on VPS
- Authentik public resource proxied to my homelab through newt. No HC, no platform SSO. Services in the homelab all are behind traefik, reachable via https.
Forward to Authentik when logging into Pangolin via SSO works fine, then
> There was a problem connecting to Authentik. Please contact your administrator.Unable to reach the identity provider while exchanging the authorization code. Please try again.
Pangolin docker logs show same errors:
```
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-01-23T05:18:01+00:00 [error]: Failed to reach OIDC provider while exchanging authorization code {"error":"Failed to send request"}
```
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.
<!-- gh-comment-id:3789418786 -->
@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.
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
<!-- gh-comment-id:3795897622 -->
@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
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
VLAN(A)
Proxmox (A)
with Pangolin LCX
Proxmox (B) with different LXC / VMs
Authentik
Internal Zone
VLAN (B)
different clients
newt
VLAN (x,y,)
remote VPS
newt
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
<!-- gh-comment-id:3798985283 -->
@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
- - VLAN(A)
- - - Proxmox (A)
- - - - with Pangolin LCX
- - - Proxmox (B) with different LXC / VMs
- - - - Authentik
- Internal Zone
- - VLAN (B)
- - - different clients
- - - newt
- - VLAN (x,y,)
- remote VPS
- - newt
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
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.
<!-- gh-comment-id:3806054273 -->
@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.
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.
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.
<!-- gh-comment-id:3806955283 -->
@t984447 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.
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.
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.
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.
<!-- gh-comment-id:3807293993 -->
@aweb-01 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.
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.
meh I'm tired after wasting 90 minutes on this. Tried almost every solution listed here. Not sure how to proceed.
<!-- gh-comment-id:3843876169 -->
@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.
I've found a workaround some of you might be interested in.
My setup:
Pangolin on VPS in LXC
Authentik hosted at home
Public DNS for authentik points to VPS
Authentik setup as public resource in Pangolin (sso disabled)
Authentik setup as OIDC in Pangolin with public DNS info
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.
<!-- gh-comment-id:3877223134 -->
@StillLoading commented on GitHub (Feb 10, 2026):
I've found a workaround some of you might be interested in.
My setup:
* Pangolin on VPS in LXC
* Authentik hosted at home
* Public DNS for authentik points to VPS
* Authentik setup as public resource in Pangolin (sso disabled)
* Authentik setup as OIDC in Pangolin with public DNS info
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.
```
iptables -t nat -A PREROUTING -p tcp -d <your VPS IP> -j DNAT --to-destination <your gerbil/traefik IP>
```
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.
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.
<!-- gh-comment-id:3879787927 -->
@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.
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
Chain PREROUTING (policy ACCEPT 102 packets, 29463 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- * * 0.0.0.0/0 $vps_public_ip to:172.18.0.4
6 660 DOCKER all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
and after DOCKER target
Chain PREROUTING (policy ACCEPT 241K packets, 75M bytes)
pkts bytes target prot opt in out source destination
67516 4275K DOCKER all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
1 60 DNAT tcp -- * * 0.0.0.0/0 $vps_public_ip to:172.18.0.4
error message and log outputs stay the same. Also tried adding
extra_hosts:
- "authentik.example.com:172.18.0.4"
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.
<!-- gh-comment-id:3882472813 -->
@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
```
Chain PREROUTING (policy ACCEPT 102 packets, 29463 bytes)
pkts bytes target prot opt in out source destination
0 0 DNAT tcp -- * * 0.0.0.0/0 $vps_public_ip to:172.18.0.4
6 660 DOCKER all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
```
and after DOCKER target
```
Chain PREROUTING (policy ACCEPT 241K packets, 75M bytes)
pkts bytes target prot opt in out source destination
67516 4275K DOCKER all -- * * 0.0.0.0/0 0.0.0.0/0 ADDRTYPE match dst-type LOCAL
1 60 DNAT tcp -- * * 0.0.0.0/0 $vps_public_ip to:172.18.0.4
```
error message and log outputs stay the same. Also tried adding
```
extra_hosts:
- "authentik.example.com:172.18.0.4"
```
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.
@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:
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DOCKER all -- anywhere anywhere ADDRTYPE match dst-type LOCAL
DNAT tcp -- anywhere <my_vps_ip> to:172.18.0.3
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.
<!-- gh-comment-id:3892922548 -->
@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:
```
Chain PREROUTING (policy ACCEPT)
target prot opt source destination
DOCKER all -- anywhere anywhere ADDRTYPE match dst-type LOCAL
DNAT tcp -- anywhere <my_vps_ip> to:172.18.0.3
```
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.
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.
Seems to be a different issue then:
docker exec -it pangolin curl -L -v https://authentik.example.com
[...]
> GET / HTTP/2
> Host: authentik.example.com
> User-Agent: curl/8.17.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Request completely sent off
< HTTP/2 401
[...]
<
Unauthorized
* Connection #0 to host authentik.example.com:443 left intact
Makes sense as when clicking
authentik login prompt works and only after login the message
There was a problem connecting to Authentik. Please contact your administrator.
Unable to reach the identity provider while exchanging the authorization code. Please try again.
shows.
<!-- gh-comment-id:3903492603 -->
@kapuett commented on GitHub (Feb 15, 2026):
> 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.
Seems to be a different issue then:
```
docker exec -it pangolin curl -L -v https://authentik.example.com
[...]
> GET / HTTP/2
> Host: authentik.example.com
> User-Agent: curl/8.17.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Request completely sent off
< HTTP/2 401
[...]
<
Unauthorized
* Connection #0 to host authentik.example.com:443 left intact
```
Makes sense as when clicking
<img width="412" height="81" alt="Image" src="https://github.com/user-attachments/assets/04092336-e642-46ce-b546-6c2a32b20cb8" />
authentik login prompt works and only after login the message
>There was a problem connecting to Authentik. Please contact your administrator.
Unable to reach the identity provider while exchanging the authorization code. Please try again.
shows.
@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.
<!-- gh-comment-id:3904252016 -->
@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.
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
<!-- gh-comment-id:3904362245 -->
@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
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
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.
Does authentik.example.com resolve to your VPS from your client & Pangolin itself ?
You should also check this in the Browser dev tools to rule out any caching issues. (Network tab->Remote IP column)
Is SSO disabled for the public resource for Authentik ?
catch 22, can't auth if you can't auth yourself in Pangolin
Are rules enabled on the public resource ?
disable for testing
Does the public resource for Authentik work in general ?
Best to test with any resource that uses Authentik for auth from mobile wifi to rule out any DNS/routing shenanigans.
Does the Pangolin OIDC config point to authentik.example.com ?
What does the Pangolin log say when you start the login process ?
What does the Authentik log say when you start the login process ?
What does the Browser log say when you start the login process ?
<!-- gh-comment-id:3904439441 -->
@StillLoading 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
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.
* Does authentik.example.com resolve to your VPS from your client & Pangolin itself ?
* You should also check this in the Browser dev tools to rule out any caching issues. (Network tab->Remote IP column)
* Is SSO disabled for the public resource for Authentik ?
* catch 22, can't auth if you can't auth yourself in Pangolin
* Are rules enabled on the public resource ?
* disable for testing
* Does the public resource for Authentik work in general ?
* Best to test with any resource that uses Authentik for auth from mobile wifi to rule out any DNS/routing shenanigans.
* Does the Pangolin OIDC config point to authentik.example.com ?
* What does the Pangolin log say when you start the login process ?
* What does the Authentik log say when you start the login process ?
* What does the Browser log say when you start the login process ?
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.
Pass to Auth - Country - UK
Block Access - Country - ALL COUNTRIES
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-callback
Thanks again to those who gave me a steer in the right direction, it's much appreciated.
<!-- gh-comment-id:3913802310 -->
@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.
1. Pass to Auth - Country - UK
2. Block Access - Country - ALL COUNTRIES
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-callback`
Thanks again to those who gave me a steer in the right direction, it's much appreciated.
@bignick8t3 FYI you don't need to disable rules, just set it up like this
Bypass Auth - Country - UK
Bypass Auth - IP Range /IP - where your Pangolin auth requests originates from, should be docker network (usually 172.18.0.0/16)
Block Access - Country - ALL COUNTRIES
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.
<!-- gh-comment-id:3916206674 -->
@StillLoading commented on GitHub (Feb 17, 2026):
@bignick8t3 FYI you don't need to disable rules, just set it up like this
1. Bypass Auth - Country - UK
2. Bypass Auth - IP Range /IP - where your Pangolin auth requests originates from, should be docker network (usually 172.18.0.0/16)
3. Block Access - Country - ALL COUNTRIES
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!
<!-- gh-comment-id:3916528040 -->
@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!
@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:
Does authentik.example.com resolve to your VPS from your client & Pangolin itself ?
Yes. Tried from different end devices and public networks.
Is SSO disabled for the public resource for Authentik ?
Yes, see above
Are rules enabled on the public resource ?
There were and they were wrong, just like for @bignick8t3. I deleted them entirely, behaviour stays the same.
Does the public resource for Authentik work in general ?
Yes, I have SSO enabled for e.g OpenCloud and Immich and it works for both.
Does the Pangolin OIDC config point to authentik.example.com ?
Yes. This is my config:
What does the Pangolin log say when you start the login process ?
Pangolin:
pangolin | Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/1/oidc/validate-callback
pangolin | 2026-02-17T18:34:06+00:00 [debug]: POST /api/v1/auth/idp/1/oidc/validate-callback
pangolin | 2026-02-17T18:34:06+00:00 [debug]: State verified {"urL":"http://authentik.example.com/application/o/token/","expectedState":"HredacteduI","state":"HTedacteduI"}
pangolin | 2026-02-17T18:34:06+00:00 [error]: Failed to reach OIDC provider while exchanging authorization code {"error":"Failed to send request"}
What does the Authentik log say when you start the login process ?
What does the Browser log say when you start the login process ?
Unfortunately nothing helpful for me either
Much appreciate your support!
<!-- gh-comment-id:3916537135 -->
@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:
<img width="1264" height="948" alt="Image" src="https://github.com/user-attachments/assets/b6c64130-9bdb-4f8f-a7e5-1464317eda73" />
@StillLoading thanks for the detailed steps. Here's what I got:
- Does authentik.example.com resolve to your VPS from your client & Pangolin itself ?
- Yes. Tried from different end devices and public networks.
- Is SSO disabled for the public resource for Authentik ?
- Yes, see above
- Are rules enabled on the public resource ?
- There were and they were wrong, just like for @bignick8t3. I deleted them entirely, behaviour stays the same.
- Does the public resource for Authentik work in general ?
- Yes, I have SSO enabled for e.g OpenCloud and Immich and it works for both.
- Does the Pangolin OIDC config point to authentik.example.com ?
- Yes. This is my config:
<img width="655" height="875" alt="Image" src="https://github.com/user-attachments/assets/4de7de59-1f3a-4c73-9681-0888908dd4eb" />
- What does the Pangolin log say when you start the login process ?
- Pangolin:
```
pangolin | Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/1/oidc/validate-callback
pangolin | 2026-02-17T18:34:06+00:00 [debug]: POST /api/v1/auth/idp/1/oidc/validate-callback
pangolin | 2026-02-17T18:34:06+00:00 [debug]: State verified {"urL":"http://authentik.example.com/application/o/token/","expectedState":"HredacteduI","state":"HTedacteduI"}
pangolin | 2026-02-17T18:34:06+00:00 [error]: Failed to reach OIDC provider while exchanging authorization code {"error":"Failed to send request"}
```
- What does the Authentik log say when you start the login process ?
- Autentik server logs:
```
{
"action":"authorize_application",
"auth_via":"session",
"client_ip":"redacted",
"context":{
"asn":{
"as_org":"redacted",
"asn":"redacted",
"network":"8redacted"
},
"authorized_application":{
"app":"authentik_core",
"model_name":"application",
"name":"Pangolin",
"pk":"5redacted"
},
"flow":"eredactedc",
"geo":"removed",
"http_request":{
"args":{
"client_id":"redactedF",
"code_challenge":"credacted3A",
"code_challenge_method":"S256",
"redirect_uri":"https://pangolin.example.com/auth/idp/1/oidc/callback",
"response_type":"code",
"scope":"openid profile email",
"state":"a7redacted4"
},
"method":"GET",
"path":"/application/o/authorize/",
"request_id":"redacted",
"user_agent":"Mozilla/5.0 (Android 16; Mobile; rv:147.0) Gecko/147.0 Firefox/147.0"
},
"scopes":"profile email openid"
},
"domain_url":"authentik.example.com",
"event":"Created Event",
"host":"authentik.example.com",
"level":"info",
"logger":"authentik.events.models",
"pid":307176,
"request_id":"6redacted0",
"schema_name":"public",
"timestamp":"2026-02-17T18:38:52.806579",
"user":{
"email":"redacted",
"pk":7,
"username":"redacted"
}
}{
"auth_via":"session",
"domain_url":"authentik.example.com",
"event":"Task enqueued",
"host":"authentik.example.com",
"level":"info",
"logger":"authentik.tasks.middleware",
"pid":307176,
"request_id":"redacted",
"schema_name":"public",
"task_id":"1redacted6",
"task_name":"authentik.events.tasks.event_trigger_dispatch",
"timestamp":"2026-02-17T18:38:52.816975"
}{
"auth_via":"session",
"domain_url":"authentik.example.com",
"event":"/application/o/authorize/?response_type=code&client_iredacted&redirect_uri=https%3A%2F%2Fpangolin.example.com%2Fauth%2Fidp%2F1%2Foidc%2Fcallback&state=a7redacted&code_challenge_method=S256&code_challenge=credacted&scope=openid+profile+email",
"host":"authentik.example.com",
"level":"info",
"logger":"authentik.asgi",
"method":"GET",
"pid":307176,
"remote":"redacted",
"request_id":"6redacted0",
"runtime":110,
"schema_name":"public",
"scheme":"https",
"status":302,
"timestamp":"2026-02-17T18:38:52.841356",
"user":"redacted",
"user_agent":"Mozilla/5.0 (Android 16; Mobile; rv:147.0) Gecko/147.0 Firefox/147.0"
}
```
- What does the Browser log say when you start the login process ?
- Unfortunately nothing helpful for me either
<img width="1296" height="719" alt="Image" src="https://github.com/user-attachments/assets/7422b1ac-f417-4df4-a84a-d59b85235697" />
Much appreciate your support!
@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.
<!-- gh-comment-id:3917769032 -->
@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.
Well, that's embarassing: @StillLoading that was the issue. Thank you!
No worries 😉, glad it works for you now.
<!-- gh-comment-id:3919232578 -->
@StillLoading commented on GitHub (Feb 18, 2026):
> Well, that's embarassing: [@StillLoading](https://github.com/StillLoading) that was the issue. Thank you!
No worries 😉, glad it works for you now.
@StillLoading yep that got it, adding the local docker network as the second rule allows the geo blocks to still work.
Thanks again.
<!-- gh-comment-id:3926097260 -->
@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.
<!-- gh-comment-id:3975650867 -->
@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.
I don't see how that would achieve anything else than:
Allow your country to auth
Deny all countries
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.
<!-- gh-comment-id:3976601416 -->
@kapuett commented on GitHub (Feb 28, 2026):
I don't see how that would achieve anything else than:
1. Allow your country to auth
2. Deny all countries
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.
Same issue here, glad I'm not alone, Pangolin 1.11.1 going to Authentik:
pangolin | Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/2/oidc/generate-url
pangolin | Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/2/oidc/validate-callback
pangolin | 2025-10-29T04:36:03+00:00 [error]: Failed to send request
pangolin | Stack: Error: Failed to send request
pangolin | at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:35:15)
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:23235:20)
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:
Pangolin couldn't trust the TLS cert on my Authentik instance (issued by an internal CA). Fixed by mounting the root CA cert into the Pangolin container and setting NODE_EXTRA_CA_CERTS:
Pangolin couldn't reach the token URL because the OIDC token exchange request was trying to go out and come back in through the same host's port 443 (hairpin NAT). Fixed by adding a Docker network alias on the gerbil service so authentik.example.com resolves directly within the Docker network:
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.
<!-- gh-comment-id:4061609605 -->
@LoganRupe commented on GitHub (Mar 14, 2026):
> Same issue here, glad I'm not alone, Pangolin 1.11.1 going to Authentik:
>
> ```
> pangolin | Making OIDC URL generation request to: http://localhost:3000/api/v1/auth/idp/2/oidc/generate-url
> pangolin | Making OIDC callback validation request to: http://localhost:3000/api/v1/auth/idp/2/oidc/validate-callback
> pangolin | 2025-10-29T04:36:03+00:00 [error]: Failed to send request
> pangolin | Stack: Error: Failed to send request
> pangolin | at sendTokenRequest (file:///app/node_modules/arctic/dist/request.js:35:15)
> 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:23235:20)
> ```
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:
1. Pangolin couldn't trust the TLS cert on my Authentik instance (issued by an internal CA). Fixed by mounting the root CA cert into the Pangolin container and setting NODE_EXTRA_CA_CERTS:
```
pangolin:
volumes:
- ./certs/My_Root_CA.crt:/usr/local/share/ca-certificates/My_Root_CA.crt:ro
environment:
NODE_EXTRA_CA_CERTS: /usr/local/share/ca-certificates/My_Root_CA.crt
```
2. Pangolin couldn't reach the token URL because the OIDC token exchange request was trying to go out and come back in through the same host's port 443 (hairpin NAT). Fixed by adding a Docker network alias on the gerbil service so authentik.example.com resolves directly within the Docker network:
```
gerbil:
networks:
default:
aliases:
- authentik.example.com
```
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.
@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.
<!-- gh-comment-id:4188007171 -->
@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
<!-- gh-comment-id:4234046671 -->
@Streetlamp123 commented on GitHub (Apr 13, 2026):
It would be nice if all requests to internal resouces did this automatically
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
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?https://github.com/fosrl/pangolin/blob/b34c3db956868c304dc727752211fccbd4e6dc21/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:
https://github.com/fosrl/pangolin/blob/b34c3db956868c304dc727752211fccbd4e6dc21/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