I found my solution. The problem was virtualization specific. I was passing through my ethernet adapter via bridging on Unraid . Although the VM had sole access to the ethernet, this was breaking port forwarding due to some deeper technical stuff I cannot explain. Long story sort, switching to PCI passthrough fixed this. Enabling Multi-Function PCIe ACS override, binding the ethernet card to VFIO at bootup, and then assigning the VM the PCI devices directly in the VM settings resolved this. Another note, after hours of work, I could NOT get a Realtek RTL8125 based ethernet card working. PCI passthrough would entirely fail, and using bridging with Unraid resulted in WAN working but the LAN port failing to operate at all. That ethernet card not working was a massive part in this taking me forever to troubleshoot. Everything is working great and with the preferred method of PCI passthrough with an Intel I225 based ethernet card. If I had started with the I225 card instead of trying to save some money with the RTL8125 I would have saved myself some serious effort. Lesson learnt.

https://redmine.pfsense.org/issues/14619 This helps explain it. [image: 1705532631812-screenshot-2023-12-15-at-10.53.07-pm-resized.png] Separators cause issues if you’re using them.

@eeebbune not for the handshake.. Those are tiny syn and syn,ack Where exactly is that sniff from, and I am not sure what you show blocked is actually the same traffic in your sniff.. Without timestamps to reference.. For all I know that is some other connection on same ports that were blocked.. Here is the thing - if what your talking to takes seconds to respond to a syn vs milliseconds - your going to have a bad day no matter how you look at it. edit: here is an answer from a syn.. It is less than 1 ms.. Not 28 seconds.. If the device your sending a syn too doesn't answer in 20 some seconds you have something wrong with that box.. Or its just never seeing the syn at all.. Even if we take the time of the last retrans which it got??? It took 13 seconds to send a syn,ack? here is normal sort of response time talking to something - here talking to my nas.. You can see the time sent the syn, and when got back the syn,ack [image: 1705504079320-answer.jpg] Its less than 1 ms.. here is talking to something out on the internet.. 11ms not 27 seconds.. [image: 1705504233698-11.jpg] edit2: So if this is the same session.. The ports match up, once you sent syn,ack that .6 box answered with ack in like less than 1 ms.. So why is 18.88 taking 27 seconds to respond? Maybe the hamster is tired running around the wheel powering it? [image: 1705504512866-ack.jpg]

I found everything I needed to know and better here pfSense baseline guide with VPN, Guest and VLAN support.

@DGG I found the solution. I need to bound the firewall states to the interfaces. This is the quote from the pf.conf manual page set state-policy The state-policy option sets the default behaviour for states: _ if-bound States are bound to interface. _ floating States can match packets on any interfaces (the default). Now I have to figure out if it is possible do it from Web interface, in OPNsense it is. PfSense manual say nothing about it.

@norcimo yeah as mentioned pfsense has zero to do with talking devices on the same network.. host unreachable for something on your own network points to not getting the mac address back from an arp.. example if I just ping some IP that I know there is no device on. $ ping 192.168.9.42 Pinging 192.168.9.42 with 32 bytes of data: Reply from 192.168.9.100: Destination host unreachable. Reply from 192.168.9.100: Destination host unreachable. Reply from 192.168.9.100: Destination host unreachable. Reply from 192.168.9.100: Destination host unreachable. Ping statistics for 192.168.9.42: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Are your devices wireless/wired - could have AP isolation set? Where you don't allow clients to talk to each other. Wired could be a private vlan setup on the switch. Normal layer3 firewalls don't block arp.. So host unreachable is not what you would see, you would just see a timeout.

@kahodges1721 you need to allow TCP port 8883 and TCP 443

@JonathanLee not a thing.. not sure what your issue was, but it wasn't related to that..

@CZvacko said in Lots of blocks in log - any comments: implicit/hidden firewall rules are generally evaluated last No not the case at all.. For example there are hidden rules for dhcp, etc.. Yes the default deny rule is last.. If you explicit say block IPv6 by unchecking that box, then yes those are first.. How could that sort of rule not be first, you might have created rules that allow IPv6.. And since there is a default deny at the end any way for both ipv4 and ipv6.. Then yes wanting block all IPv6 would have to be first on the list.

The rule numbers do not change with the added blocks so I do not think it seems them

@johnpoz I know KISS but I think the issue is I have Mac for all source and none for ffffffffffff broadcast set up….. maybe it’s now blocking that in 23.09 So I should have each interface have a approve ffffffffff MAC address also

@Sorjal those lists like *.domain.com are for use when you use like proxy.. Or some form of web filtering where a name is checked before your allowed. Those would be handy for dns filtering for example.. But for a layer 3 firewall that filters on IP, you need to scroll down on the link(s) you provide where they list IP ranges.. And allow those. here is like a tiny snip from that first link you provided *.manage.microsoft.com manage.microsoft.com 104.46.162.96/27 13.67.13.176/28 13.67.15.128/27 13.69.231.128/28 13.69.67.224/28 13.70.78.128/28 13.70.79.128/27 There is no possible way to convert a wild card to an IP.. Because it could be anything that could resolve to any IP at all really.. *.domain.tld = anything.domain.tld - how could you possible go through and resolve every possible combination of anything.domain.tld, could be alsjdfdlsjdsf.domain.tld could be 903y4rnsoduf.whatever.something.otherthing.domain.tld Really the possibilities are almost infinite.. The only way you can use such an entry is when your allowing based on something that has the name, like a proxy, or dns query where you allow to query anything.domain.tld, but not say baddomain.tld Your firewall that that filters on IP would need to know exactly what your client resolved, to be able to allow or block it based on name. While you can do what with a specific say www.domain.tld, where pfsense queries that every so often and say ok www.domain.tld = 1.2.3.4 and 5.6.7.8, etc.. allow those.. But you can still run into problems where there might be a mismatch where firewall resolved it to 1.2.3.4, but client resolved and tries to go to 4.3.2.1

@johnpoz Ah, I was just looking in the wrong place. Thanks!

I'm with @bmeeks here - schools and companies quite often block web based email, that they allow gmail might be because they use gmail. Many companies block that for sure. It could be its blocked and the block page coming up via an https link is what your browser is complaining about, redirection to a block page normally will force a browser to complain, hey I was trying to go to www.emaildomain.com why is the certs sending back www.somethingelse.com in the cert.. if you admin the pfsense box at this school - we can for sure help you figure out how to allow what you want to allow, etc. But if this is school pfsense box that you do not admin - you need to get with the school IT admins. Also agree with not connecting schools equipment to non school network, ie your phone hotspot.

@mathieur geo filtering for something like a p2p prob not a good thing ;) hehehe You really have no clue to where traffic might come from.. I had sim sort of problem when I started filtering based on geoip and a test plex does for if your plex is available remote.. Some of the testing comes from non US ips, same goes for stuff like uptime robot and status cake.. They leverage global resources to check stuff, and if your filtering to only allow IPs from certain regions you can run into issues. I just found where these services list what IPs can be used as source of the traffic, and allowed them - the lists of IPs do change now and then.. And just added them to my pfblocker alias that I use to allow. [image: 1704721515406-allow.jpg] But with something like p2p, that would be pretty impossible..

You can grep the file /tmp/rules.debug to search for that rule indentifier as follows: Execute this command from a shell prompt on the firewall: grep 1770009125 /tmp/rules.debug and see what it shows. The file contains the full firewall rule set currently in use by the packet filter. That is an odd-looking rule identifier, though. Not sure where that is coming from. To the best of my knowledge, pfBlockerNG is the only package that creates firewall rules on its own.