Even "dirty websites" use TLS these days. Easy to recognize, their URL starts with https://
Without drastic measure on your LAN, that is, all your web visiting devices and pfSense, you can't redirect https://"dirty websites" to https://DuckDuckGo
Your browser won't allow this.
The test : is the host name "dirty websites" present in the certificate obtained ? will fail.
Have a look :
That's doesn't look like "dirty websites" : your browser will refuse the connection.
If it was possible, you would also be able to redirect https://some-bank-acess-you-use to https://some-bank-access-you-use, and because you control some-bank-access-you-use (and your site looks identical to some-bank-acess-you-use), now you get the access credentials.
And five minutes later you can access https://some-bank-acess-you-use with the credentials you've obtained, and do what you want.
The thing is, why would you ask if something if possible if you don't want it to be possible ?
After all, https://"dirty websites", or https://facebook.com or https://some-bank-acess-you-use or https://some-bank-acess-you-use, for your PC, switch, pfsense, upstream routers of your ISP etc, its all the same : a connection to some server over port 443, TCP.
So, do I miss knowledge with CP behavior or should I modify something?
You might as well check (== read and understand what happens when and why etc) this file /usr/local/captiveportal/index.php
It's the file that's get 'executed' when a users is redirected that the portal login interface.
Read that file carefully - and also check this one : /etc/inc/captiveportal.inc which contains all the functions.
For instance, you'll find why/where/when a string like $PORTAL_ACTION$ is replaced by the correct URL before getting send to the client.
Throwing $PORTAL_ACTION$ at the client's web browser who throws it back to the captive portal web server will produce 404 errors.