Interpreting firewall logs
-
In my firewall logs, all I can see there are packets that were blocked by the default deny rule. Why can't I see packets that have an action of "pass"? I can browse the Internet outbound just fine so I was under the impression that those will appear in the logs but I could be wrong.
-
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.
-
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?
-
if you are capturing on the pfSense WAN interface (interface connected to your other firewall), it strongly implies that the packets are getting there. What you need to check is the dest addr of the packets: are they for your pfSense public IP or the IP of anything behind pfSense (should be the NAT address).
Your pfSense public WAN: is that fronted by the other firewall or does it bypass it? I'm assuming it's fronted, but just want to check.
-
@mer:
if you are capturing on the pfSense WAN interface (interface connected to your other firewall), it strongly implies that the packets are getting there. What you need to check is the dest addr of the packets: are they for your pfSense public IP or the IP of anything behind pfSense (should be the NAT address).
Your pfSense public WAN: is that fronted by the other firewall or does it bypass it? I'm assuming it's fronted, but just want to check.
Here's what I get when I try to RDP to a VM behind my firewall:
00:28:53.309033 IP source IP:source Port > destination IP (public WAN IP of pfsense):NAT'ted destination Port: tcp 0
00:28:53.309192 IP destination IP (public WAN IP of pfsense):NAT'ted destination Port > source IP:source Port: tcp 0
00:28:56.311073 IP source IP:source Port > destination IP (public WAN IP of pfsense):NAT'ted destination Port: tcp 0
00:28:56.324873 IP destination IP (public WAN IP of pfsense):NAT'ted destination Port > source IP:source Port: tcp 0
00:29:02.310346 IP source IP:source Port > destination IP (public WAN IP of pfsense):NAT'ted destination Port: tcp 0
00:29:02.331005 IP destination IP (public WAN IP of pfsense):NAT'ted destination Port > source IP:source Port: tcp 0Clearly, the destination port is the pfsense public IP which is what I expect.
The network config external to my pfsense firewall is the information that I'm not sure of. What our IT department did was to just give me two public IP's and that's what I was using. If my firewall catches those packets, then I'm assuming their not being blocked by anything before it. What do you think causes it not to connect? I mean, even the access to pfsense's GUI from outside does not work now (everything was working until yesterday). I just want to prove that the problem is outside of the firewall and what could be causing it.
-
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. :)
-
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.