Docker running Traefik with CrowdSec Bouncer and PFsense as SE (LAPI)

1

I’ve spent the last several days trying to get this solution deployed. PFsense as SE (LAPI) on physical server is running fine. Traefik basic install on docker is working fine. The problem come after deployment of CrowdSec container then modifying the configuration where this blog post says to disable the API which makes it a “Log Processor” with the following

api:
server:
enable: false

Once I’ve made this small change and restarted the container (as the output says to run “systemctl reload crowdsec” it goes into a continuous boot loop (but container doesn’t have systemctl so I choose to restart). I’ve even tried adding config to config.yaml.local and got same results. I’m seriously questioning the accuracy of these documents.

Update: Something else I’ve noticed while search for a solution. The config.yaml within the crowdsec container is preconfigured with:

api:
  client:
    insecure_skip_verify: false
    credentials_path: /etc/crowdsec/local_api_credentials.yaml
  server:
    log_level: info
    listen_uri: 0.0.0.0:8080
    profiles_path: /etc/crowdsec/profiles.yaml
    trusted_ips: # IP ranges, or IPs which can have admin API access
      - 127.0.0.1
      - ::1
    online_client: # Central API credentials (to push signals and receive bad IPs)
      credentials_path: /etc/crowdsec//online_api_credentials.yaml
    enable: true             <<<===  I DON'T SEE THIS LINE IN OTHERS OUTPUT
prometheus:
  enabled: true
  level: full
  listen_addr: 0.0.0.0
  listen_port: 6060

Should the “enable: true” line exist? This is where I’ve been changing to “false”.

Can someone offer any reliable assistance?

2

(Limits to my knowledge, i don’t use traefik, and I don’t use crowdsec inside a docker container)

api:
  server:
    enable: true

This is only needed to be a LAPI server - if that’s the config from your docker container you can comment out that whole section, you only need one LAPI server, and it sounds like that’s your pfSense machine.

as long as you’ve done cscli lapi register ... on the docker host, and cscli machines validate ... on the pfSense host, you should be good to go.

You can test the LAPI is working properly with a cscli decisions add -i 23.23.23.23 on one machine, and a cscli decisions list on the other and it should show you a ban for 23.23.23.23

As far the the continuous boot loop, look at the crowdsec logs and see what it’s upset about. It could be something as simple as the LAPI server trying to start on a port that’s already in use by one of your docker containers.

It could be something else entirely, but the logs are a great starting point.

3

@lucas

Let me see if I understand your suggestion:

# server:
 #   log_level: info
 #   listen_uri: 0.0.0.0:8080
 #   profiles_path: /etc/crowdsec/profiles.yaml
 #   trusted_ips: # IP ranges, or IPs which can have admin API access
 #     - 127.0.0.1
 #     - ::1
 #   online_client: # Central API credentials (to push signals and receive bad IPs)
 #     credentials_path: /etc/crowdsec//online_api_credentials.yaml
 #   enable: true            <<<=== DOES THIS BELONG ?????????

I should comment out the whole server options? I have tried commenting

Regarding my question about disabling server.api section. This is an excerpt directly from the crowdsec repo v1.6.1 which I installed and yet different:

api:
  client:
    insecure_skip_verify: false
    credentials_path: /etc/crowdsec/local_api_credentials.yaml
  server:
    log_level: info
    listen_uri: 127.0.0.1:8080
    profiles_path: /etc/crowdsec/profiles.yaml
    console_path: /etc/crowdsec/console.yaml
    online_client: # Central API credentials (to push signals and receive bad IPs)
      credentials_path: /etc/crowdsec/online_api_credentials.yaml
    trusted_ips: # IP ranges, or IPs which can have admin API access
      - 127.0.0.1
      - ::1
#    tls:
#      cert_file: /etc/crowdsec/ssl/cert.pem
#      key_file: /etc/crowdsec/ssl/key.pem

Notice the “enable: true” is not displayed like it is in my docker install.

4

Within docker since we use environment variables there could be chances that the config.yaml is different to bare metal. We outline in documentation where the enable options goes. Please remember yaml can be quite temperamental if you use tabs then spaces, so best to always put the option directly below the parent key.

also if it is boot looping providing an excerpt of the logs may help us point you in the direction to rectify it.