@firewalluser:
@kevindd992002:
@divsys:
By default "Pass" rules are not logged (to save log space).
If you need to ensure a rule gets logged, check the "Log" box while editing the rule.
https://doc.pfsense.org/index.php/Firewall_Rule_Troubleshooting has more info.
Got it, thanks!
I have an issue with the firewall though. It's been working fine since yesterday. I have different NAT rules to forward connections and other services through NAT (RDP and mail servers included). This is in a test network inside our company. For some reason, I cannot access these services from an external network since yesterday and I've made no changes in the firewall rules.
I highly suspect that this is a configuration change in our front end firewall (which I don't have access since my pfsense firewall is just a backend firewall) but I need to confirm if this is really the case. I've been given two public IP's. One public IP is the main WAN connection of my pfsense box and the other is in a NAT 1:1 rule. I don't see any blocks on the firewall logs but when I do a packet capture, I do see that the connections are being logged. That means that the packets do reach my pfsense backend, right?
Also setup a separate device running a syslog server of sorts, rsyslog is more compatible, this way if your fw gets targetted you have a separate device with historical logs to check through anything thats been going on as its quite easy to hide activity on pfsense as the gui log only goes back 2000 entries.
System log, Settings tab, scroll down the bottom, tick everything and put in the ip address of the syslog server.
Dont forget to use a firewall on the device running the syslog server at the very least as well.
The more you log everything from every device on your network and isolation the devices on your network, the easier it becomes at spotting anomolies which could be bugs which have exploitable potential, also test how things react when things are not working properly, ie a public facing server when pfsense goes down for example. Sometimes its when things go wrong that new exploits present themselves in conditions which are not usually tested for, aka break things. :)
Thanks for the suggestion but I'll have to plan that for a later date as my pfsense VM is more for personal purposes than for production.