Snort blocks WAN IP….!
-
At least now we know what the problem is … :-[
We might have to look to Ermal for this fix. I am not too familiar with the details of that part of the code. I know it makes calls into other areas of pfSense to get IP address info for the interfaces.
You can try to workaround the issue for now by manually adding an Alias for your VIP and then putting that Alias into your whitelist.
Bill
-
I have both edited the Friendly_ip whitelist to include the IP range /26 but it doesnt get updated in the Snort code.
Other ranges are there no problem.
Update: I updated the friendlyip list manually and put in the range. Restarted Snort and it didnt give errors.
But there is definately something wrong in PFSense regarding this package and the way it is controlled by the GUI.
If I edit the friendlyIP alias in PfSense, then it doesnt update the list in Snort even though its an alias.
-
Did the new IP Range Alias show up in the Whitelist tab properly in the GUI after entering it via the GUI? Trying to establish if the code might be having a problem with the slash during the PHP post/get operations (maybe not properly URL-encoding the slash).
-
I edited an allready existing alias….and put it in there.
It has 3 IP ranges in there allready with /....
-
Still blocks the WAN IP….............!!
-
Possibly dumb question, but is the WAN VIP in the same subnet as the actual WAN IP of the box? It might be the "snort2c" and "pfctl" modules that are getting confused and not Snort directly. In pfSense the actual blocking by Snort is done by a third-party plug-in patched into the Snort code. That plug-in might be where the problem is, and if so, will be much harder to troubleshoot.
Bill
-
yes it is :) All part of the same range.
-
The last troubleshooting step to hopefully isolate the culprit:
If the whitelist file referenced in the snort.conf file for the interface on the "output alert_pf" line actually contains a properly constructed setting for your virtual IP, then in my view that narrows the problem down to the third-party plugin and not really with Snort itself. The values in that file are pulled out and compared to "offending" IP addresses, and if there is a match, then the offender IP is NOT put in the blocking table.
Someone with a lot more knowledge of the packet filtering engine in FreeBSD may have to take it from there.
EDIT: just one last clarifying question (I apologize if you have answered this previously) – is Snort blocking the WAN VIP, the WAN interface IP, or both?
Bill
-
Only WAN VIP. NOT the interface IP.
-
I am kind of leaning toward this being a problem with the snort2c plug-in that actually puts the temp rule in the packet filter engine. But as I've said a few times, I am not the subject-matter expert in this area.
Maybe one of the core pfSense developers can chime in here with an idea.
A general call out to the public using Snort on pfSense:
Does anyone else out there using virtual IPs in pfSense with Snort in blocking mode have a problem with Snort blocking the WAN virtual IP?Bill
-
Update: It blocks WAN interface IP as well. But that happened only after the addition of the /26 range in Snort including the /
When Alias is edited and /26 range is removed, SNORT DOESNT GET UPDATED in the txt file in /usr/local/snort/interfacexxx/
So there is definately a bug in the system!
-
I guess I need to setup a dual-firewall system in VMware Workstation with pfSense to play around with this. However, I've never set up CARP with pfSense. I have configure VRRP in Check Point firewalls, though. Should be similar in concept, just not identical in form and procedure.
Can you say when this issue started for you? Was it prior to January 1st this year, or only later? This might help pin down any changes in the PHP code that might be related.
Bill
-
Thats a good question… It has been a long journey with Snort since it has a lot of problems with PfSense. You helped to make the package significantly better and that helped a lot!
A fair guess would be after we had the last discussion and I implemented your fixes.
