Duplicate Crowdsec Bouncers #139

New Issue

2025-11-13T11:51:10-06:00

GiteaMirror commented

2025-11-13 11:51:10 -06:00

Originally created by @MED1975 on GitHub (Mar 12, 2025).

Hi - I have done an install of Pangolin 1.01 and included Crowdsec.

When I ran the command

docker exec crowdsec cscli bouncers list

I can see two bouncers have been created, however only one of them is active. I previously tested v1.0 on a different server and it created only a single bouncer. Any advice?

Name IP Address Valid Last API pull Type Version Auth Type

traefik-bouncer 172.18.0.4 ✔️ 2025-03-11T14:00:38Z Crowdsec-Bouncer-Traefik-Plugin 1.X.X api-key
traefik-bouncer@172.18.0.2 172.18.0.2 ✔️ 2025-03-12T14:56:24Z Crowdsec-Bouncer-Traefik-Plugin 1.X.X api-key

Originally created by @MED1975 on GitHub (Mar 12, 2025). Hi - I have done an install of Pangolin 1.01 and included Crowdsec. When I ran the command `docker exec crowdsec cscli bouncers list` I can see two bouncers have been created, however only one of them is active. I previously tested v1.0 on a different server and it created only a single bouncer. Any advice? -------------------------------------------------------------------------------------------------------------------------- Name IP Address Valid Last API pull Type Version Auth Type -------------------------------------------------------------------------------------------------------------------------- traefik-bouncer 172.18.0.4 ✔️ 2025-03-11T14:00:38Z Crowdsec-Bouncer-Traefik-Plugin 1.X.X api-key traefik-bouncer@172.18.0.2 172.18.0.2 ✔️ 2025-03-12T14:56:24Z Crowdsec-Bouncer-Traefik-Plugin 1.X.X api-key --------------------------------------------------------------------------------------------------------------------------

GiteaMirror added the config label 2025-11-13 11:51:10 -06:00

GiteaMirror closed this issue

2025-11-13 11:51:10 -06:00

GiteaMirror commented

2025-11-13 11:51:11 -06:00

@oschwartz10612 commented on GitHub (Mar 13, 2025):

I dont think this is a problem but if you are concerned you can remove the other bouncer. https://docs.crowdsec.net/docs/cscli/cscli_bouncers_delete/

@oschwartz10612 commented on GitHub (Mar 13, 2025): I dont think this is a problem but if you are concerned you can remove the other bouncer. https://docs.crowdsec.net/docs/cscli/cscli_bouncers_delete/

GiteaMirror commented

2025-11-13 11:51:11 -06:00

@MED1975 commented on GitHub (Mar 14, 2025):

thanks for your reply

@MED1975 commented on GitHub (Mar 14, 2025): thanks for your reply

GiteaMirror commented

2025-11-13 11:51:11 -06:00

@MED1975 commented on GitHub (Mar 16, 2025):

Hi - something odd definitely happening - a secondary bouncer keeps appearing. Anyone else getting this?

@MED1975 commented on GitHub (Mar 16, 2025): Hi - something odd definitely happening - a secondary bouncer keeps appearing. Anyone else getting this?

GiteaMirror commented

2025-11-13 11:51:12 -06:00

@MED1975 commented on GitHub (Mar 18, 2025):

Just tried to delete the extra bouncer that is not updating and got this error

sudo docker exec crowdsec cscli bouncers delete traefik-bouncer@172.18.0.2

level=warning msg="bouncer 'traefik-bouncer@172.18.0.2' is auto-created and cannot be deleted, delete parent bouncer traefik-bouncer instead"

@MED1975 commented on GitHub (Mar 18, 2025): Just tried to delete the extra bouncer that is not updating and got this error ``` sudo docker exec crowdsec cscli bouncers delete traefik-bouncer@172.18.0.2 level=warning msg="bouncer 'traefik-bouncer@172.18.0.2' is auto-created and cannot be deleted, delete parent bouncer traefik-bouncer instead" ```

GiteaMirror commented

2025-11-13 11:51:12 -06:00

@oschwartz10612 commented on GitHub (Mar 20, 2025):

This behavior seems to be by design - Crowdsec appears to be automatically creating child bouncers for each connection from the parent bouncer. The extra bouncer that's "not updating" might be from a previous container instance or IP that's no longer active but still registered in the system.

I think because its called traefik-bouncer it was the parent created during the install process.

This might be more of a crowdsec question - not sure.

@oschwartz10612 commented on GitHub (Mar 20, 2025): This behavior seems to be by design - Crowdsec appears to be automatically creating child bouncers for each connection from the parent bouncer. The extra bouncer that's "not updating" might be from a previous container instance or IP that's no longer active but still registered in the system. I think because its called `traefik-bouncer` it was the parent created during the install process. This might be more of a crowdsec question - not sure.

GiteaMirror commented

2025-11-13 11:51:12 -06:00

@MED1975 commented on GitHub (Mar 20, 2025):

Cheers. Yes I presume it's CrowdSec doing it. Seems a bit unintuitive but beyond Pangolin control. More of a Docker thing.

@MED1975 commented on GitHub (Mar 20, 2025): Cheers. Yes I presume it's CrowdSec doing it. Seems a bit unintuitive but beyond Pangolin control. More of a Docker thing.

GiteaMirror commented

2025-11-13 11:51:12 -06:00

@hokeye commented on GitHub (Apr 8, 2025):

I seemed to have found a pattern, after each docker compose down/up the default network has a new subnet and a new IP assigned to each container. I noted the last entry's IP address from the bouncers list (ex. 172.16.0.3). Then changed the docker compose network to have hard coded subnet and assigned a static ip to Gerbil container (172.16.0.3). This has stopped any more "duplicate" bouncer entries from showing up. I'll need to delete the original bouncer and re-configure it to clean up the bouncers list and the crowdsec console.

@hokeye commented on GitHub (Apr 8, 2025): I seemed to have found a pattern, after each docker compose down/up the default network has a new subnet and a new IP assigned to each container. I noted the last entry's IP address from the bouncers list (ex. 172.16.0.3). Then changed the docker compose network to have hard coded subnet and assigned a static ip to Gerbil container (172.16.0.3). This has stopped any more "duplicate" bouncer entries from showing up. I'll need to delete the original bouncer and re-configure it to clean up the bouncers list and the crowdsec console.

GiteaMirror commented

2025-11-13 11:51:12 -06:00

@hokeye commented on GitHub (Apr 9, 2025):

I seemed to have found a pattern, after each docker compose down/up the default network has a new subnet and a new IP assigned to each container. I noted the last entry's IP address from the bouncers list (ex. 172.16.0.3). Then changed the docker compose network to have hard coded subnet and assigned a static ip to Gerbil container (172.16.0.3). This has stopped any more "duplicate" bouncer entries from showing up. I'll need to delete the original bouncer and re-configure it to clean up the bouncers list and the crowdsec console.

Confirmed, after setting static ip. Deleted the parent bouncer "traefik-bouncer" that removed the duplicates with @ip. Then created a new bouncer, received the API key. Replaced the API key located ~/config/traefik/dynamic_configuration.yml, attribute: crowdsecLapiKey. Then restarted the stack, and it seems to be working. No more duplicates!

@hokeye commented on GitHub (Apr 9, 2025): > I seemed to have found a pattern, after each docker compose down/up the default network has a new subnet and a new IP assigned to each container. I noted the last entry's IP address from the bouncers list (ex. 172.16.0.3). Then changed the docker compose network to have hard coded subnet and assigned a static ip to Gerbil container (172.16.0.3). This has stopped any more "duplicate" bouncer entries from showing up. I'll need to delete the original bouncer and re-configure it to clean up the bouncers list and the crowdsec console. Confirmed, after setting static ip. Deleted the parent bouncer "traefik-bouncer" that removed the duplicates with @ip. Then created a new bouncer, received the API key. Replaced the API key located ~/config/traefik/dynamic_configuration.yml, attribute: crowdsecLapiKey. Then restarted the stack, and it seems to be working. No more duplicates!

GiteaMirror commented

2025-11-13 11:51:13 -06:00

@oschwartz10612 commented on GitHub (Apr 9, 2025):

@hokeye good to know thanks for figuring that out!

Im not sure if anyone would like to chime in if we should or should not have a network defined in the default stack or not. I am not sure if there are any downsides to doing so...

@oschwartz10612 commented on GitHub (Apr 9, 2025): @hokeye good to know thanks for figuring that out! Im not sure if anyone would like to chime in if we should or should not have a network defined in the default stack or not. I am not sure if there are any downsides to doing so...

GiteaMirror commented

2025-11-13 11:51:13 -06:00

@hokeye commented on GitHub (Apr 11, 2025):

@oschwartz10612, welcome!

The only issue I've encountered on rare occasion is IP collision, if another container receives a DHCP ip prior to the static ip container's creation. That can be "fixed" by doing another down/up.

Some of my brainstorms:

Reordering container creation hierarchy to allow Gerbil container to spawn first and others will wait on its Service Healthy state.
Setting the static IP to a larger value.
Hardcoding all containers on default network to receive static IPs

@hokeye commented on GitHub (Apr 11, 2025): @oschwartz10612, welcome! The only issue I've encountered on rare occasion is IP collision, if another container receives a DHCP ip prior to the static ip container's creation. That can be "fixed" by doing another down/up. Some of my brainstorms: - Reordering container creation hierarchy to allow Gerbil container to spawn first and others will wait on its Service Healthy state. - Setting the static IP to a larger value. - Hardcoding all containers on default network to receive static IPs