Messages

I have upgraded to latest OPNsense business 23.4 and the issue persists so this definitely seems to be a bug, hope the development team could have a look and fix

Any clues in /var/log/suricata/latest.log ?

No, just IPS alerts logged, the same alerts shown in GUI Services>Intrusion Detection>Administration>Alerts

My policy is configured as follows:

Enabled checked
Priority 0
Rulesets all selected
Action Alert,Drop
Rules
affected products Any
all the remaining items Nothing selected
New action Drop

I have enabled IPS for WAN interface only and added my WAN IP subnet to Home Networks, IPS mode enabled, Promiscuous mode enabled, Pattern matcher set to Hyperscan, Detect profile set to High, Hardware offloading disabled in Interface>Settings as indicated official documentation
The only rules enabled and downloaded are ET Pro Telemetry Edition from OPNsense with valid subscription

Ok I missed that .  If you go to Administration | Rules . There Filters drop down and chose Action: Action/Drop, do you get your rules there appearing?
This is to verify, not to set.
My policies are slightly different, maybe you can try that:
Action (at top) is Alert, Drop.
New action (at bottom) is Drop.

My policy is exactly configured like that, also rules are appearing in the drop down selector, I selected them all.
It's just that the policy doesn't get applied and can't understand why.

I enabled IPS mode and followed exactly the steps described in official OPNsense documentation however it's not working, any help in sorting out this issue would be greatly appreciated.

I made no progresses so far, was anybody else using latest OPNsense 22.10.2 commercial edition able to configure IPS and get it working to drop incoming WAN traffic instead of just getting alerts ?
I carefully read the official documentation multiple times however the traffic is not dropped

I forgot to mention I am running latest OPNsense business  22.10.2.

One thing I ran into that confused me is that the policy has a 'from' action (at the top) and a 'to' action (at the end). The top action is by default set to 'Drop'. So, if you change the bottom one to 'Drop' you are in effect saying: if the action is 'Drop' change it to 'Drop'.

Make sure that you create a policy to change (Action, top) 'Alert' to (New Action, bottom)'Drop'.

I created a Policy and did exactly that however I am still getting alerts instead of drops

I have configured Suricate on WAN interface, enabled IPS mode, downloaded and installed ET Telemetry rules and added token, created policy with all rulesets selected, action set to Alert and new action set to Drop, the other parameters have all been left to default values.
I started getting alerts in Services>Intrusion Detection>Administration>Alerts however it shows 'allowed' in action column instead of blocked.
Kindly could anyone please shed some light on how to properly configure Suricata in IPS mode to actually block traffic?

I don't see any evidence supporting this yet. Make it sound like we don't generally test firmware upgrades for a major upgrade...
Connectivity audits now please. Change your mirror to see if that helps.

As previously reported I already tried switching to many different mirrors and the result is the same.
Also there are no issues with the connectivity from my side

Is your date/time set accurately ?
If not, is your dns working ?

If not, temporarily set dns to something simple like 8.8.8.8, then sync clock

I tried this as well and still not working, anyway this issue appeared just after upgrading to 22.7 so there must be something broken with this release.

***GOT REQUEST TO CHECK FOR UPDATES***
Currently running OPNsense 22.7_4 (amd64/OpenSSL) at Sun Jul 31 12:30:48 BST 2022
Fetching changelog information, please wait... fetch: transfer timed out
Updating OPNsense repository catalogue...
pkg: Repository OPNsense has a wrong packagesite, need to re-create database

Same issue here after upgrading from 22.1 to 22.7, updates failing with transfer timed out error, tried other mirrors and failing as well

Hi all, I am experiencing some issues with getting captive portal LDAP authentication working. The external LDAP authentication server was configured correctly in OPNsense and it works fine when testing via System > Access > Tester, however the captive splash screen authentication returns authentication failed.
Does anybody have any hints on what could be the root cause of this issue ?
I am running latest 21.1.5 release.

I did some more tests and this definitely looks to me like a BUG, even disabling the ftp proxy in web GUI the process remains in memory, therefore something is not working.
I have just installed the ftp-proxy plugin and configured as per the tutorial in this forum on 20.1.7 release therefore i cannot say whether it was working before or not.

Also it seems like ftp-proxy is running

# ps aux | grep ftp-proxy
proxy   54011   0.0  0.1 1057704   2728  -  Ss   09:35    0:00.00 /usr/sbin/ftp-proxy -b 127.0.0.1 -p 8021 -a <WAN_CARP_IP> -R <Internal_FTP_Server_IP> -v -D 7

however no PID file

# ls /var/run/osftpproxy*
ls: No match.

I am currently running 20.1.7 with latest updates applied, anybody else is experiencing such issue ?

Maybe I hit a bug in current release ?

Hello all, i am trying to setup ftp-proxy to allow external FTP clients to connect to internal FTP server, i followed the wiki and the setup should be ok however ftp-proxy is not starting (yellow background shown).
Starting from CLI it shows the following

# /usr/local/etc/rc.d/os-ftp-proxy start
osftpproxy is not running.
Starting osftpproxy.
ftp-proxy: bind failed: Address already in use
/usr/local/etc/rc.d/os-ftp-proxy: WARNING: failed to start osftpproxy

however there is nothing already bound to 127.0.0.1:8021

# netstat -ln | grep 127.0.0.1
tcp4       0      0 127.0.0.1.27017                               127.0.0.1.10607                               ESTABLISHED
tcp4       0      0 127.0.0.1.10607                               127.0.0.1.27017                               ESTABLISHED
tcp4       0      0 127.0.0.1.27017                               127.0.0.1.34104                               ESTABLISHED
tcp4       0      0 127.0.0.1.34104                               127.0.0.1.27017                               ESTABLISHED
udp4       0      0 127.0.0.1.53                                  *.*                                           
udp4       0      0 127.0.0.1.123                                 *.*                                           
udp4       0      0 127.0.0.1.46849                               127.0.0.1.9996                               
udp4       0      0 127.0.0.1.60625                               127.0.0.1.9996                               
udp4       0      0 127.0.0.1.27715                               127.0.0.1.9996                               
udp4       0      0 127.0.0.1.2056                                *.*                                           
udp4       0      0 127.0.0.1.2055                                *.*                                           
udp4       0      0 127.0.0.1.29634                               127.0.0.1.2055       

Any ideas about what could be causing this issue ?

ftp-proxy setup is the same shown in reverse FTP proxy tutorial on this forum, I have just set the source address to match the WAN CARP address where the remote FTP clients will connect to and the reverse address to match the internal FTP server IP address.