When accessing my public resources, I noticed that some of them are not available. I noticed that I get the following error messages in the logs when accessing a page (regardless of whether the access works or not). I suspect that a successful access is delivered from the local browser cache and bypasses authentication. (wild guess)
Accessing the Pangolin UI (which is also randomly available) there are the following related access log entries:
I also noticed that access to resources works for a while after restarting the Pangolin Docker Compose stack (down & up) before the problems reappear. However, I couldn't find anything in the logs that pointed to the cause of the problems. It seems that this is the case when no service/resource is called for a longer period of time.
Komodo is just one example, all other resources are also affected.
I use Pocket ID as an IDP, but access still does not work via the local Pangolin user in the event of an error.
When the error occurs, I am redirected to the Pangolin login page. The login appears to be successful, but I am then redirected back to the login page. (No error message in the UI, entries in the log as shown above).
Since I can see the Pangolin page, I don't expect there to be a problem with Crowdsec.
Unfortunately, I have no idea what the cause could be, but I am happy to provide any information that might help identify the cause.
Docker Compose
services:pangolin:image:fosrl/pangolin:1.15.4# https://github.com/fosrl/pangolin/releasescontainer_name:pangolinrestart:alwaysvolumes:- ./config:/app/confighealthcheck:test:["CMD","curl","-f","http://localhost:3001/api/v1/"]interval:"3s"timeout:"3s"retries:15gerbil:image:fosrl/gerbil:1.3.0# https://github.com/fosrl/gerbil/releasescontainer_name:gerbilrestart:alwaysdepends_on:pangolin:condition:service_healthycommand:- --reachableAt=http://gerbil:3003- --generateAndSaveKeyTo=/var/config/key- --remoteConfig=http://pangolin:3001/api/v1/gerbil/get-config- --reportBandwidthTo=http://pangolin:3001/api/v1/gerbil/receive-bandwidthvolumes:- ./config/:/var/configcap_add:- NET_ADMIN- SYS_MODULEports:- 51820:51820/udp# WireGuard port# - 21820:21820/udp # Client connection port- 443:443# Port for traefik because of the network_mode- 80:80# Port for traefik because of the network_modetraefik:image:traefik:v3.6.8# https://hub.docker.com/_/traefikcontainer_name:traefikrestart:alwaysnetwork_mode:service:gerbil# Ports appear on the gerbil servicedepends_on:pangolin:condition:service_healthycommand:- --configFile=/etc/traefik/traefik_config.ymlvolumes:- ./config/traefik:/etc/traefik:ro# Volume to store the Traefik configuration- ./config/letsencrypt:/letsencrypt# Volume to store the Let's Encrypt certificates- ./config/traefik/logs:/var/log/traefik# Volume to store Traefik logsenv_file:- .enverror-pages:image:ghcr.io/tarampampam/error-pages:3.8.0# https://github.com/tarampampam/error-pages/releasesrestart:alwaysenvironment:- TEMPLATE_NAME=connectiongeoipupdate:container_name:geoipupdateimage:ghcr.io/maxmind/geoipupdaterestart:alwaysenv_file:- .envvolumes:- "./config/GeoLite2:/usr/share/GeoIP"crowdsec:command:-tcontainer_name:crowdsecenvironment:COLLECTIONS:crowdsecurity/traefik crowdsecurity/appsec-virtual-patching crowdsecurity/appsec-generic-rules crowdsecurity/linux crowdsecurity/iptablesENROLL_INSTANCE_NAME:pangolin-crowdsecENROLL_TAGS:dockerGID:"1000"PARSERS:crowdsecurity/whitelistshealthcheck:interval:10sretries:3start_period:30stest:- CMD- cscli- lapi- statustimeout:5simage:docker.io/crowdsecurity/crowdsec:latestlabels:- traefik.enable=false# ports:# - 6060:6060restart:alwaysvolumes:- ./config/crowdsec:/etc/crowdsec- ./config/crowdsec/db:/var/lib/crowdsec/data- ./config/traefik/logs:/var/log/traefik- /var/log/journal:/var/log/host:rocrowdsec-web-ui:image:ghcr.io/theduffman85/crowdsec-web-ui:latestcontainer_name:crowdsec_web_uiports:- "100.90.80.137:3000:3000"environment:- CROWDSEC_URL=http://crowdsec:8080- CROWDSEC_USER=crowdsec-web-ui- CROWDSEC_PASSWORD=<password># Optional: Lookback period for alerts/stats (default: 168h/7d)- CROWDSEC_LOOKBACK_PERIOD=5d# Optional: Backend auto-refresh interval. Values: 0 (Off), 5s, 30s (default), 1m, 5m- CROWDSEC_REFRESH_INTERVAL=30s# Optional: Idle Mode settings to save resources# Interval to use when no users are active (default: 5m)- CROWDSEC_IDLE_REFRESH_INTERVAL=5m# Time without API requests to consider system idle (default: 2m)- CROWDSEC_IDLE_THRESHOLD=2m# Optional: Interval for full cache refresh (default: 5m)# Forces a complete data reload when active, skipped when idle.- CROWDSEC_FULL_REFRESH_INTERVAL=5mvolumes:- ./crowdsec-ui-data:/app/datarestart:alwaysnetworks:default:driver:bridgeenable_ipv6:truename:pangolin
I think if it were a general problem, I wouldn't be the first to notice it. Generally speaking, I believe the problem must have come with one of the latest releases, otherwise I would have noticed it sooner. Could it be related to a particular version of Traefik?
Expected Behavior
Reliable access to all resources
Originally created by @elcajon on GitHub (Feb 18, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2501
### Describe the Bug
When accessing my public resources, I noticed that some of them are not available. I noticed that I get the following error messages in the logs when accessing a page (regardless of whether the access works or not). I suspect that a successful access is delivered from the local browser cache and bypasses authentication. (wild guess)
```
pangolin | 2026-02-18T11:02:19+00:00 [info]: Resource access not allowed. Resource ID: 16. IP: 2a02:xxx.
pangolin | 2026-02-18T11:02:19+00:00 [info]: Resource access not allowed. Resource ID: 16. IP: 2a02:xxx.
pangolin | 2026-02-18T11:02:19+00:00 [info]: Resource access not allowed. Resource ID: 16. IP: 2a02:xxx.
pangolin | 2026-02-18T11:02:20+00:00 [info]: Resource access not allowed. Resource ID: 16. IP: 2a02:xxx.
pangolin | 2026-02-18T11:02:20+00:00 [info]: Resource access not allowed. Resource ID: 16. IP: 2a02:xxx.
pangolin | 2026-02-18T11:02:20+00:00 [info]: Resource access not allowed. Resource ID: 16. IP: 2a02:xxx.
pangolin | 2026-02-18T11:02:20+00:00 [info]: Resource access not allowed. Resource ID: 16. IP: 2a02:xxx.
```
Accessing the Pangolin UI (which is also randomly available) there are the following related access log entries:
<img width="1490" height="189" alt="Image" src="https://github.com/user-attachments/assets/6020e024-c7e8-4d2a-8928-a4b70468deaa" />
I also noticed that access to resources works for a while after restarting the Pangolin Docker Compose stack (down & up) before the problems reappear. However, I couldn't find anything in the logs that pointed to the cause of the problems. It seems that this is the case when no service/resource is called for a longer period of time.
Komodo is just one example, all other resources are also affected.
I use Pocket ID as an IDP, but access still does not work via the local Pangolin user in the event of an error.
When the error occurs, I am redirected to the Pangolin login page. The login appears to be successful, but I am then redirected back to the login page. (No error message in the UI, entries in the log as shown above).
Since I can see the Pangolin page, I don't expect there to be a problem with Crowdsec.
Unfortunately, I have no idea what the cause could be, but I am happy to provide any information that might help identify the cause.
<details><summary>Docker Compose</summary>
<p>
```yaml
services:
pangolin:
image: fosrl/pangolin:1.15.4 # https://github.com/fosrl/pangolin/releases
container_name: pangolin
restart: always
volumes:
- ./config:/app/config
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:3001/api/v1/"]
interval: "3s"
timeout: "3s"
retries: 15
gerbil:
image: fosrl/gerbil:1.3.0 # https://github.com/fosrl/gerbil/releases
container_name: gerbil
restart: always
depends_on:
pangolin:
condition: service_healthy
command:
- --reachableAt=http://gerbil:3003
- --generateAndSaveKeyTo=/var/config/key
- --remoteConfig=http://pangolin:3001/api/v1/gerbil/get-config
- --reportBandwidthTo=http://pangolin:3001/api/v1/gerbil/receive-bandwidth
volumes:
- ./config/:/var/config
cap_add:
- NET_ADMIN
- SYS_MODULE
ports:
- 51820:51820/udp # WireGuard port
# - 21820:21820/udp # Client connection port
- 443:443 # Port for traefik because of the network_mode
- 80:80 # Port for traefik because of the network_mode
traefik:
image: traefik:v3.6.8 # https://hub.docker.com/_/traefik
container_name: traefik
restart: always
network_mode: service:gerbil # Ports appear on the gerbil service
depends_on:
pangolin:
condition: service_healthy
command:
- --configFile=/etc/traefik/traefik_config.yml
volumes:
- ./config/traefik:/etc/traefik:ro # Volume to store the Traefik configuration
- ./config/letsencrypt:/letsencrypt # Volume to store the Let's Encrypt certificates
- ./config/traefik/logs:/var/log/traefik # Volume to store Traefik logs
env_file:
- .env
error-pages:
image: ghcr.io/tarampampam/error-pages:3.8.0 # https://github.com/tarampampam/error-pages/releases
restart: always
environment:
- TEMPLATE_NAME=connection
geoipupdate:
container_name: geoipupdate
image: ghcr.io/maxmind/geoipupdate
restart: always
env_file:
- .env
volumes:
- "./config/GeoLite2:/usr/share/GeoIP"
crowdsec:
command: -t
container_name: crowdsec
environment:
COLLECTIONS: crowdsecurity/traefik crowdsecurity/appsec-virtual-patching crowdsecurity/appsec-generic-rules crowdsecurity/linux crowdsecurity/iptables
ENROLL_INSTANCE_NAME: pangolin-crowdsec
ENROLL_TAGS: docker
GID: "1000"
PARSERS: crowdsecurity/whitelists
healthcheck:
interval: 10s
retries: 3
start_period: 30s
test:
- CMD
- cscli
- lapi
- status
timeout: 5s
image: docker.io/crowdsecurity/crowdsec:latest
labels:
- traefik.enable=false
# ports:
# - 6060:6060
restart: always
volumes:
- ./config/crowdsec:/etc/crowdsec
- ./config/crowdsec/db:/var/lib/crowdsec/data
- ./config/traefik/logs:/var/log/traefik
- /var/log/journal:/var/log/host:ro
crowdsec-web-ui:
image: ghcr.io/theduffman85/crowdsec-web-ui:latest
container_name: crowdsec_web_ui
ports:
- "100.90.80.137:3000:3000"
environment:
- CROWDSEC_URL=http://crowdsec:8080
- CROWDSEC_USER=crowdsec-web-ui
- CROWDSEC_PASSWORD=<password>
# Optional: Lookback period for alerts/stats (default: 168h/7d)
- CROWDSEC_LOOKBACK_PERIOD=5d
# Optional: Backend auto-refresh interval. Values: 0 (Off), 5s, 30s (default), 1m, 5m
- CROWDSEC_REFRESH_INTERVAL=30s
# Optional: Idle Mode settings to save resources
# Interval to use when no users are active (default: 5m)
- CROWDSEC_IDLE_REFRESH_INTERVAL=5m
# Time without API requests to consider system idle (default: 2m)
- CROWDSEC_IDLE_THRESHOLD=2m
# Optional: Interval for full cache refresh (default: 5m)
# Forces a complete data reload when active, skipped when idle.
- CROWDSEC_FULL_REFRESH_INTERVAL=5m
volumes:
- ./crowdsec-ui-data:/app/data
restart: always
networks:
default:
driver: bridge
enable_ipv6: true
name: pangolin
```
</p>
</details>
<details><summary>Resource Configuration</summary>
<p>
```yaml
public-resources:
[...]
komodo:
name: Komodo
protocol: http
full-domain: komodo.example.com
ssl: true
targets:
- site: pangolin
hostname: 100.90.80.137
method: http
port: 8080
healthcheck:
hostname: 100.90.80.137
port: 8080
auth:
sso-enabled: true
auto-login-idp: 1
rules:
- action: allow
match: path
value: /listener/*
- action: pass
match: country
value: DE
- action: deny
match: country
value: ALL
```
</p>
</details>
### Environment
- OS Type & Version: docker compose
- Pangolin Version: 1.15.4
- Gerbil Version: 1.3.0
- Traefik Version: 3.6.8
- Newt Version: 1.9.0
- Olm Version: n/a
### To Reproduce
Not sure to be honest.
I think if it were a general problem, I wouldn't be the first to notice it. Generally speaking, I believe the problem must have come with one of the latest releases, otherwise I would have noticed it sooner. Could it be related to a particular version of Traefik?
### Expected Behavior
Reliable access to all resources
I have the same issue, specifically with Komodo but also withh more services (Ansible). Something in the pipeline seems to have changed, dunno whether it's related to Pangolin, Komodo or PocketId.
<!-- gh-comment-id:3921321009 -->
@kebel87 commented on GitHub (Feb 18, 2026):
I have the same issue, specifically with Komodo but also withh more services (Ansible). Something in the pipeline seems to have changed, dunno whether it's related to Pangolin, Komodo or PocketId.
@marcschaeferger commented on GitHub (Mar 1, 2026):
I can confirm that this issue also exists in Pangolin 1.16.2 but with a bit different effects at least for me, as i can access the ressources.
Environment
OS Type & Version: Alpine 3.23.3 (Docker Compose)
Pangolin Version: 1.16.2
Gerbil Version: 1.3.0
Traefik Version: 3.6.9
Newt Version: 1.10.1
Olm Version: n/a
Additional Observations
I tested authentication using the same browser session where I am already logged into the Pangolin Dashboard/UI.
I also tested using a different browser.
In both cases:
The login form appears.
Authentication appears to be successful.
I am redirected to the resource.
However, in the logs I see both failed login and successful login entries.
All requests originate from the same static public IPv4 address (company-owned). And it can only be me doing the requests.
When the issue occurs:
I get redirected to the Pangolin login page.
Login appears successful.
No visible error message in the UI.
Logs contain Resource access not allowed entries.
This affects multiple resources, not just a single one.
I’ve attached a screenshot of the log behavior as well.
<!-- gh-comment-id:3979730328 -->
@marcschaeferger commented on GitHub (Mar 1, 2026):
I can confirm that this issue also exists in **Pangolin 1.16.2** but with a bit different effects at least for me, as i can access the ressources.
### Environment
* OS Type & Version: Alpine 3.23.3 (Docker Compose)
* Pangolin Version: 1.16.2
* Gerbil Version: 1.3.0
* Traefik Version: 3.6.9
* Newt Version: 1.10.1
* Olm Version: n/a
### Additional Observations
* I tested authentication using the **same browser session** where I am already logged into the Pangolin Dashboard/UI.
* I also tested using a **different browser**.
* In both cases:
* The login form appears.
* Authentication appears to be successful.
* I am redirected to the resource.
* However, in the logs I see both **failed login** and **successful login** entries.
* All requests originate from the **same static public IPv4 address (company-owned)**. And it can only be me doing the requests.
When the issue occurs:
* I get redirected to the Pangolin login page.
* Login appears successful.
* No visible error message in the UI.
* Logs contain `Resource access not allowed` entries.
This affects multiple resources, not just a single one.
I’ve attached a screenshot of the log behavior as well.
<img width="1520" height="833" alt="Image" src="https://github.com/user-attachments/assets/a31c7b30-59bd-4db4-af29-d82e3b582e8e" />
I'm seeing this issue as well and it seems to be an issue with newly created rules after upgrading Pangolin to one of the newer versions. Uncertain which specific version introduced this issue as I have not created new rules for every version.
In my case, I have public resources which are protected but have a "Bypass auth" rule for my home IP. This simple rule works for public resources created in earlier versions of Pangolin. Even though my home IP is shown correctly in the Request Logs of the Pangolin dashboard I can see a "No Valid Auth" reason for a Denied action to this request.
The error logs for the docker compose stack matches those posted above, ie.: pangolin | 2026-03-05T12:47:00+00:00 [info]: Resource access not allowed. Resource ID: 16. IP: XX.XX.XX.XX..
Rules which have not changes since some of the last few releases still work, ie. the rules created in earlier versions with the very same "Bypass auth" rule for my home IP, is shown in the Request Logs of the Pangolin dashboard as "Allowed by Rule".
<!-- gh-comment-id:4004897493 -->
@pierreminik commented on GitHub (Mar 5, 2026):
I'm seeing this issue as well and it seems to be an issue with newly created rules after upgrading Pangolin to one of the newer versions. Uncertain which specific version introduced this issue as I have not created new rules for every version.
In my case, I have public resources which are protected but have a "Bypass auth" rule for my home IP. This simple rule works for public resources created in earlier versions of Pangolin. Even though my home IP is shown correctly in the Request Logs of the Pangolin dashboard I can see a "No Valid Auth" reason for a Denied action to this request.
The error logs for the docker compose stack matches those posted above, ie.: `pangolin | 2026-03-05T12:47:00+00:00 [info]: Resource access not allowed. Resource ID: 16. IP: XX.XX.XX.XX.`.
Rules which have not changes since some of the last few releases still work, ie. the rules created in earlier versions with the very same "Bypass auth" rule for my home IP, is shown in the Request Logs of the Pangolin dashboard as "Allowed by Rule".
@github-actions[bot] commented on GitHub (Mar 20, 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:4094610782 -->
@github-actions[bot] commented on GitHub (Mar 20, 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.
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 @elcajon on GitHub (Feb 18, 2026).
Original GitHub issue: https://github.com/fosrl/pangolin/issues/2501
Describe the Bug
When accessing my public resources, I noticed that some of them are not available. I noticed that I get the following error messages in the logs when accessing a page (regardless of whether the access works or not). I suspect that a successful access is delivered from the local browser cache and bypasses authentication. (wild guess)
Accessing the Pangolin UI (which is also randomly available) there are the following related access log entries:
I also noticed that access to resources works for a while after restarting the Pangolin Docker Compose stack (down & up) before the problems reappear. However, I couldn't find anything in the logs that pointed to the cause of the problems. It seems that this is the case when no service/resource is called for a longer period of time.
Komodo is just one example, all other resources are also affected.
I use Pocket ID as an IDP, but access still does not work via the local Pangolin user in the event of an error.
When the error occurs, I am redirected to the Pangolin login page. The login appears to be successful, but I am then redirected back to the login page. (No error message in the UI, entries in the log as shown above).
Since I can see the Pangolin page, I don't expect there to be a problem with Crowdsec.
Unfortunately, I have no idea what the cause could be, but I am happy to provide any information that might help identify the cause.
Docker Compose
Resource Configuration
Environment
To Reproduce
Not sure to be honest.
I think if it were a general problem, I wouldn't be the first to notice it. Generally speaking, I believe the problem must have come with one of the latest releases, otherwise I would have noticed it sooner. Could it be related to a particular version of Traefik?
Expected Behavior
Reliable access to all resources
@kebel87 commented on GitHub (Feb 18, 2026):
I have the same issue, specifically with Komodo but also withh more services (Ansible). Something in the pipeline seems to have changed, dunno whether it's related to Pangolin, Komodo or PocketId.
@marcschaeferger commented on GitHub (Mar 1, 2026):
I can confirm that this issue also exists in Pangolin 1.16.2 but with a bit different effects at least for me, as i can access the ressources.
Environment
Additional Observations
I tested authentication using the same browser session where I am already logged into the Pangolin Dashboard/UI.
I also tested using a different browser.
In both cases:
All requests originate from the same static public IPv4 address (company-owned). And it can only be me doing the requests.
When the issue occurs:
Resource access not allowedentries.This affects multiple resources, not just a single one.
I’ve attached a screenshot of the log behavior as well.
@pierreminik commented on GitHub (Mar 5, 2026):
I'm seeing this issue as well and it seems to be an issue with newly created rules after upgrading Pangolin to one of the newer versions. Uncertain which specific version introduced this issue as I have not created new rules for every version.
In my case, I have public resources which are protected but have a "Bypass auth" rule for my home IP. This simple rule works for public resources created in earlier versions of Pangolin. Even though my home IP is shown correctly in the Request Logs of the Pangolin dashboard I can see a "No Valid Auth" reason for a Denied action to this request.
The error logs for the docker compose stack matches those posted above, ie.:
pangolin | 2026-03-05T12:47:00+00:00 [info]: Resource access not allowed. Resource ID: 16. IP: XX.XX.XX.XX..Rules which have not changes since some of the last few releases still work, ie. the rules created in earlier versions with the very same "Bypass auth" rule for my home IP, is shown in the Request Logs of the Pangolin dashboard as "Allowed by Rule".
@github-actions[bot] commented on GitHub (Mar 20, 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.