If you ping from the pfSense GUI using the Ping tool with the default source (WAN IP) all devices on the 192.168.7.x network should response.
If they don't, but do if you ping from other machines in this network, there must be something wrong in the network settings on one involved device.
If you change the source to LAN it's expected that pings won't work, as long as the devices have no route for 192.168.6.124/25 pointing to pfSense. Responses will be sent to the default gateway.
I solved the issue a while ago and forgot to answer here.
After entering the IP in Captive Portal / Allowed IP Addresses, everything was perfect.
As my CP is authenticated, so I believe that the question was precisely at that point. The other end had no way to authenticate itself to be able to pass and from the moment I released the IP there, he started to communicate. I even thought about doing a test of this type, taking the CP's authentication to see if it worked directly, but I ended up not having time.
Anyway ... it's resolved.
Thanks to everyone who was willing to try to help.
If you are not using limiters, then note this from the guide;
The ALTQ framework is handled through pf and is closely tied to network card drivers. ALTQ can handle several types of schedulers and queue layouts. The traffic shaper wizard configures ALTQ and gives firewall administrators the ability to quickly configure QoS for common scenarios, and it allows custom rules for more complex tasks. ALTQ is inefficient, however, so the maximum potential throughput of a firewall is lowered significantly when it is active.
pfSense software also supports a separate shaper concept called Limiters. Limiters enforce hard bandwidth limits for a group or on a per-IP address or network basis. Inside of those bandwidth limits, limiters can also manage traffic priorities.
SOLVED - I figured out my problem. It was caused by this setting below (Static ARP under the DHCP Server configuration for the interface), which I had enabled on the interface because I interpreted it incorrectly. It essentially took precedence over any and all allow rules configured for the OPT2 interface, and prevented any host without a statically assigned DHCP address from communicating with the interface even though the host received the dynamic DHCP assignment from the OPT2 interface. I hope this saves other folks time and headache.
Screen Shot 2019-11-06 at 9.46.34 PM.png
As explained in docs.netgate[.]comScreen Shot 2019-11-06 at 10.40.04 PM.png
I think it is related to the P and C state settings in the BIOS.
It is possible that I changed one of them and just forgot.
P-state is the exact one I changed I think.
It has to be set to its default value (HW_ALL irc).
These may help: