It's probably this:
https://docs.netgate.com/pfsense/en/latest/firewall/troubleshooting-blocked-log-entries-for-legitimate-connection-packets.html
It could be this:
https://docs.netgate.com/pfsense/en/latest/firewall/troubleshooting-blocked-log-entries-due-to-asymmetric-routing.html
Steve
@marvosa Thanks for the follow-up. Not sure what changed, or if I'm just impatient... Before I posted that last comment I had enabled dhcp for VLAN 300 and everything worked. Then I disabled dhcp and reconnected the external dhcp server and it didn't work. So I posted the comment and went upstairs and ate lunch.
Came back downstairs to continue troubleshooting and everything is working using the external dhcp server.
Thanks again for your help.
@stephenw10 yep. Spot on I just hadn't replied yet. Reassigned the IP on the bge0 interface and it automatically enabled the interface again. Many thanks for the help from all on this thread.
I did work it out myself but knowing others would have got it as well makes a difference. Thanks.
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..
