@stephenw10 I understand. Thanks for the info.

Then syslog. That was my second thought.

@Shan-lapierre said in Monitor NAT rules:

And infact my NAT rule was created whit "Pass" flag and pf doesn't created any fw rule.

I'm still looking for a usage of that "Pass" case ^^

Normally, a NAT rule translates traffic coming (initiated) somewhere on 'the WAN' (the Internet) and the address (WAN IP) (and port) has to be mapped == translated (a,d port) to a LAN addresses, so it can reach this device.
This needs of course a WAN 'firewall' rules, as by default nothing can enter the WAN - everything is blocked by default.
A NAT rule without an accompanying firewall rule .... won't work, as traffic will never reach the NAT rule, as traffic can not enter into the WAN interface.

I'm not saying other types of NAT exit, they do.

From what I've read :

receive traffic to my firewall on a specific port from a specific public IP.

Everything is working (so the external traffic reaches me on an endpoint inside my network that is listening on that specific port).

your use the classic method, and you need a auto generated firewall rule on the WAN interface.

The logging used by pfSense can be seen here: /var/etc/syslog.d/pfSense.conf
As it says there though that file is auto-generated and should not be edited directly.

However if you look there you will see that kern.debug is already being written to the system log so I would expect that to include anything at the lower priority level 'info'.

Steve

ntopng, darkstath, bandwidthd probably there are other packages now that can give you a better log view, idk, personally i send everything to grafana and i let the firewall do the firewall.

@bob-dig said in IP logs are not being created/populated:

It is odd that this problem still exists for so long now. Sure, it is just an Package but it is the most important one in my book.

Yeah, @BBcan177 is likely a busy gentleman, but I’m sure a new build will surface eventually.

But pfBlockerNG is much more than “just a package”. I’ll bet you pfBlockerNG is BY FAR the most used package on pfSense. In fact I’d highly recommend Netgate to find the currency needed to purchase the talents of bbcan177 and the pfBlockerNG name, and start including it as a bulitin feature of pfsense. With the same development/maintenance and continuity as pfSense itself.

Without pfBlockerNG, pfSense would be a much much less relevant product.

@renemg glad things are working as desired. I too noticed that it took a few minutes before I started getting the logs to output in the format you were seeing. Just depends on the number of times things hit on your firewall rules. Happy packet pushing!

@ibbetsion said in sshguard complaining about an attack from the pfSense system itself?:

192.168.1.2 is assigned IP of the pfSense firewall from my ISP router. It is the only device connected to the ISP router

This is a WAN interface ...

192.168.7.1 is the IP of the pfSense firewall itself (WAN1)

Another WAN interface ...

192.168.5.2 is the assigned IP of the second WAN port on the pfSense firewall (WAN2)

And another WAN interface ...

No LAN(s) ?

Remove all rules on all WAN interfaces.
The default action will be block all (DROP) - so sshguard won't be bothered again.

Technically, these are NOT called rule names, but descriptions instead.

The description of my firewall rules (on LAN is where I'm logging) are in my firewall logs. If you've got no rules created, you'll have to make some that actually log the data. After that, if you look in Status -> System Logs -> Firewall in the Rule column it lists the rule description(s).

There's also the 10 digit unique (I think) tracking ID code to make them quick to find or index.

The only restriction listed for rule descriptions is max of 52 characters. Don't know anything about special characters, however. Here's some talk about some description stuff.

https://forum.netgate.com/topic/92254/firewall-rule-description-length-limitation

Jeff

Sorry for the delay, I finally fell asleep. I did, on one link only. I think it was indeed Squid though. IT started [everything] deteriorating fast just a tiny bit later. Downloads were and SSH connections to local hosts would return "broken pipes". I has seen this behavior before this time I almost went insane trying to fix it, even got an SNMP tool, in itself a major undertaking because downloads kept freezing the whole network and failing to complete--finally set it up and the big red indicator that I couldn't clear was something about a DHCP ram disk, which is supposed to be full--the conclusion I kept drawing, still, I stopped DHCP and deploy another box just for DHCP.

In the end, I gave up and decided to make the best out of a bad situation and decided to start over installing very carefully the whole network, I had already wiped a couple of times pfSense, BTW, but I was restoring from backup and that last time when I didn't I discovered the backups were snowballing the bad from before. Everything was super fast again, like unbelievably so. I kept the DHCP though, and, I added to that another 4 additional pfSense boxes, RADIUS, 2x DNS and proxied DNS (it dials VPN) these were thin clients with some weird architecture that's 64-bit "but not really", something called i586/i686, I think it's from the '90s. The 32-bit pfSense got them working again. This whole thing pushed me to get creative. :) I'm just happy to help, if I can.

I'll keep an eye on that, already wrote it down on the file I write the history of changes I make, my memory sucks. I assume the first one is the same that's downloadable as backup--I'll find out. Anyway, thanks; I doubt it happens again but in a weird way I'm kinda hoping it does out of sheer curiosity.