Firewall dropping traffic destined to WAN address that should be allowed
Hello. I have a pfsense firewall with two interfaces, WAN and LAN, with a rule allowing traffic from a particular /24 to access the WAN interface on ports 22 and 443, so that we can manage this firewall from its external interface.
One of the IP addresses in the /24, let's say .5, is the NAT overload for our corporate users (NAT handled by a different firewall), and another, .6 is a web proxy I set up to test this.
Traffic sourced form .5, destined to the WAN address on port 443 is dropped - I see it in the firewall log.
Traffic sourced from .6, destined to the WAN address on port 443 is accepted, and I can log into the web interface.
If I reset the webconfigurator form the console, it does NOT fix the problem.
if I reboot the firewall, the problem goes away for a while, but eventually the firewall starts dropping https traffic from .5.
I have not been able to find any REASON in the logs - but I may not know what I'm looking for. We do not have Snort, Suricatia, or even pfblocker installed.
The only packages we have installed are the Open VM tools and the Postfix Forwarder. Oddly, if I telnet to the WAN address on port 25, sourced from.5, traffic is NOT dropped. It is handled by a different rule than the 443 access, but as the 443 access is supposed to allow the ENITRE /24 that .5 and .6 are contained in, I can't understand why my traffic gets dropped when sourced from .5
I have tried turning OFF the BEAST mitigation - doesn't work.
Firewall has routable IP's on both LAN and WAN, there are no NAT rules and NAT is set to manual.
I tried disabling DNS Rebinding checks. No luck,
I tried disabling the HTTP_REFERER enforcement check, no luck.
I made a rule above the /24 rule allowing .5 explicitly - didn't work.
I noticed that the person that set this up left the defaut web configurator cert on it, so I created a local CA, created a new server certificate, set the new cert on the web interface, and deleted the default. No change.
Does anyone have an idea what I can check? I don't want to reboot the box and lose whatever killed it…but I'm out of ideas on what to check for.
--2014-10-29 UPDATE-- OK, I found out how to fix it without a reboot. go to Diagnostics -> Tables and choose table webConfiguratorlockout. there is the .5 address, plain as day. What I'm still missing is the "why?" I have no idea what is causing this, and I'm still not sure what to look for. I didn't realize the firewall woudl dynamically block a host wihtout Snort or Suricatia installed. What is doing this? How do I find it in the logs?
That means you're failing authentication enough times for it to lock you out.
Fair enough, I'll test that too, but how do I exclude an IP form that mechanism? If I were running IDS/IPS I would know how, at least in Snort. But this is a very vanilla system, and I haven't found where it says there is a lockout without snort running. Not saying you are wrong, just that I can't find it :)
It's not configurable, nor able to be disabled (short of hacking the source if you want).
ooof. That's not optimal for my use case.
We are planning to use pfsense between our cloud product and the internet, and our NOC will manage each firewall on its public interface, and all sourced from one IP. They only have access to the public side, because the private side belongs to our customers. If the IP they come in from gets locked out, there is no mechanism I've found at the console to undo the block, and rebooting a customer firewall is a poor way to maintain access.
Now, since these will be VM's, our NOC will have access to the console without having to access the public IP - plus the lockout only seems to affect HTTPS, so I think they can SSH in too, even when the overload IP is blocked. We've been rebooting this firewall from the console up until I found the lockout - is there a way to remove an IP from lockout at the command line? I'm totally OK giving instructions to our support folks for checking/fixing this from there. Would that be possible?
You can remove table entries with pfctl via SSH.
Sorry for the very late reply. Thank you very much, that is what we tried and it worked!