Ok so you can see what those values are in the RRD update script /var/db/rrd/updaterrd.sh, specifically:
pfctl_si_out="` /sbin/pfctl -si > /tmp/pfctl_si_out `"
pfctl_ss_out="` /sbin/pfctl -ss > /tmp/pfctl_ss_out`"
pfrate="` cat /tmp/pfctl_si_out | egrep "inserts|removals" | awk '{ pfrate = $3 + pfrate } {print pfrate}'|tail -1 `"
pfstates="` cat /tmp/pfctl_ss_out | egrep -v "<\-.*?<\-|\->.*?\->" | wc -l|sed 's/ //g'`"
pfnat="` cat /tmp/pfctl_ss_out | egrep '<\-.*?<\-|\->.*?\->' | wc -l|sed 's/ //g' `"
srcip="` cat /tmp/pfctl_ss_out | egrep -v '<\-.*?<\-|\->.*?\->' | grep '\->' | awk '{print $3}' | awk -F: '{print $1}' | sort -u|wc -l|sed 's/ //g' `"
dstip="` cat /tmp/pfctl_ss_out | egrep -v '<\-.*?<\-|\->.*?\->' | grep '<\-' | awk '{print $3}' | awk -F: '{print $1}' | sort -u|wc -l|sed 's/ //g' `"
So that looks like the number of unique source IPs on outgoing states. If you only have a single WAN and you're NATing out of it that's probably going to be 1.
And the number of unique destination IPs on incoming states. A lot higher since that includes all the external IPs on states
opened on LAN by clients.
Looking at the output there though it looks like there may be room for improvement. It doesn't handle IPv6 addresses and counts blank lines.
Steve
The only way I can see this behaviour happening is if you're trying to connect to those hosts using only the host name and not the fqdn. Like: ping preauth.
If that's true then yeah it will only resolve hosts in the same domain as the client in general.
Steve
Dick? Really? Calling you out on calling yourself a ccie when clearly everyone knows that is not even close to true is not being a dick... That is just calling someone out on their BS!
So what was the problem, only tcp for the rule? Wrong source?
Maybe you had policy route on the rule? But that wouldn't of stopped ping to pfsense IP? Only ping to other lan.. That is another common mistake.
Because the NAT IP is set to 192.168.1.4, the proxy.
The destination IP defined what traffic that port forward will match on coming into the WAN. Unless you have more than one public IP on the WAN it can only be the WAN IP.
Steve
What port test are you using? 192.168.1.146 should report success on port 8443.
You won't be able to test the forward from pfSense itself. But if you try some external test such as canyouseeme and then check the state table for :25565 you should see the NAT'd state with traffic both ways.
Steve
I've never used Vultr so I have no way to know if this fits you usage....
https://www.vultr.com/docs/configuring-private-network
I note that: "Private networks are only available on Vultr compute and dedicated compute instances."
Steve
So in this scenario both your DCs are down? Because AD can for sure share their dns info.
If both your DCs are down - you have bigger problems then a copy of your dns records running on pfsense ;)
But sure running bind on pfsense would allow for zone xfers from your AD dns..
@marvosa said in how to block bad guys who is sharing internet by laptop:
We even have a few clinics that are sharing a single T1...
A real T1? These days, those are generally emulated over Ethernet. I first did that over 10 years ago. They have also been run over SHDSL for many years. I was working with that stuff back in the early '90s.
I suppose there are still some parts of the world that rely on 2 cans and a string.
Possible solution here: https://forum.netgate.com/topic/141034/rate-limit-on-radius-reply-attributes-for-pppoe-connections-not-working/3
Pretty hacky though....
Steve
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.
