If I try to perform the following command, on the VM in VLAN DMZ, it returns an error:
$ sudo cscli lapi register -u http://192.168.1.1:8080
FATA api client register: api register (http://192.168.1.1:8080/) http 400 Bad Request: http code 400, invalid body: invalid character 'C' looking for beginning of value
There seems to be an issue with the configuration of the OPNsense plugin crowdsec. If I perform a curl command:
$ curl http://192.168.1.1:8080
Client sent an HTTP request to an HTTPS server.
So in fact, it seems like port 8080 delivers HTTPS:
$ curl https://192.168.1.1:8080
curl: (35) error:0A000438:SSL routines::tlsv1 alert internal error
$ sudo cscli lapi register -u https://192.168.1.1:8080
FATA api client register: api register (https://192.168.1.1:8080/): Post "https://192.168.1.1:8080/v1/watchers": remote error: tls: internal error
Now I am unsure, how to solve it. If it helps, this is my firewall rule in DMZ:
Action Protocol Source Destination Port Description
Pass IPv4 TCP AppNextcloud 192.168.1.1/24 8080 Allow access to CrowdSec LAPI on OPNsense
AppNextcloud is an alias for IP 192.168.80.10
Other plugins installed: os-caddy (1.6.2)
So use https:// in the URL? ???
This would be too easy, as there seems to be an error with TLS then:
tls: internal error
Perhaps post the output of
sudo cscli lapi register -u https://192.168.1.1:8080
Sorry, but.. ::) I already did that. So your first question already made no sense.
Quote from: Baender on August 16, 2024, 09:59:15 PM
So in fact, it seems like port 8080 delivers HTTPS:
$ curl https://192.168.1.1:8080
curl: (35) error:0A000438:SSL routines::tlsv1 alert internal error
$ sudo cscli lapi register -u https://192.168.1.1:8080
FATA api client register: api register (https://192.168.1.1:8080/): Post "https://192.168.1.1:8080/v1/watchers": remote error: tls: internal error
If I visit https://192.168.1.1:8080 with my browser, I get this:
Secure Connection Failed
An error occurred during a connection to 192.168.1.1:8080. Peer reports it experienced an internal error.
Error code: SSL_ERROR_INTERNAL_ERROR_ALERT
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.
Learn more...
What do you have on your OPN crowdsec plugin settings:
LAPI listen address:
LAPI listen port:
And can you share the result of $sudo sockstat -l | grep crowdsec
Quote from: cookiemonster on August 16, 2024, 10:27:16 PM
What do you have on your OPN crowdsec plugin settings:
LAPI listen address:
LAPI listen port:
And can you share the result of $sudo sockstat -l | grep crowdsec
I didn't touch them and left them at the default values. In case it is relevant over 5 corners: I had to change the port of the WebGUI of the OPNsense to 8443 to use Caddy.
- LAPI listen address: 127.0.0.1
- LAPI listen port: 8080
root@OPNsense:/usr/local/etc/crowdsec # sudo sockstat -l | grep crowdsec
root crowdsec 89455 16 tcp4 127.0.0.1:8080 *:*
root crowdsec 89455 108 tcp4 127.0.0.1:6060 *:*
Ah, I see..
# sudo sockstat -l
[...]
root caddy 62076 11 tcp46 *:8080 *:*
root caddy 62076 12 udp46 *:8080 *:*
[...]
This is the default config created with crowdsec /usr/local/etc/crowdsec/config.yaml (the relevant snippet):
api:
client:
credentials_path: /usr/local/etc/crowdsec/local_api_credentials.yaml
insecure_skip_verify: false
server:
console_path: /usr/local/etc/crowdsec/console.yaml
enable: true
listen_uri: 127.0.0.1:8080
log_level: info
online_client:
credentials_path: /usr/local/etc/crowdsec/online_api_credentials.yaml
profiles_path: /usr/local/etc/crowdsec/profiles.yaml
trusted_ips:
- 127.0.0.1
- ::1
Now:
# cat /usr/local/etc/crowdsec/local_api_credentials.yaml
login: localhost
password: eXcsUxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
url: http://127.0.0.1:8080/
If you have it on localhost, either fix the listen interface, or use port forward, not allow rule.,
Now, I do not think that anything beyond this absolutely basic config is supported via the GUI, and no idea about what you have done to cause crowdsec use TLS. This definitely will NOT work out of the box. Also, apparently you already have something else listening on 8080.
I solved it, by the following actions:
- Removed custom caddy file from /usr/local/etc/caddy/caddy.d (it remained there after some recent tries in order to redirect an Unifi Controller
- Change LAPI listen address to 192.168.1.1 in CrowdSec plugin settings
- Restart Caddy
- Stop CrowdSec and Start it
$ sudo cscli lapi register -u http://192.168.1.1:8080
INFO Successfully registered to Local API (LAPI)
INFO Local API credentials written to '/etc/crowdsec/local_api_credentials.yaml'
WARN Run 'sudo systemctl reload crowdsec' for the new configuration to be effective.
Thank you guys, for the hint with sockstat -l . I had already suspected Caddy, but I would not have thought that the reason lay in a long-forgotten Caddy configuration.
nothing like a good old console to dig into the problems. One reason I dislike strongly this latest madness with docker and their ilk.
And yes I was going to suggest to change to the IP from the loopback. Unless I have bad sectors in my brain, I read somewhere crowdsec-related about it.
Quote from: Baender on August 16, 2024, 10:57:55 PM
Removed custom caddy file from /usr/local/etc/caddy/caddy.d (it remained there after some recent tries in order to redirect an Unifi Controller
Eh. Wouldn't bother, except for the controller GUI to be accessible via normal 443 and without having to deal with their non-existent certificate management. (Piece of junk, really.) Using HAproxy for this.