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. As explained in docs.netgate[.]com

@stephenw10 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: https://www.supermicro.com/support/faqs/faq.cfm?faq=29482 https://www.thomas-krenn.com/en/wiki/Processor_P-states_and_C-states

How about LAN to the IPv6 address on the pfSense WAN interface? How about LAN to the very next IPv6 hop outside the WAN? Packet capture on WAN. If the echo requests are being sent but no reply is being received, there's nothing pfSense can do about it. Complain to the ISP. It is very possible they could have something different configured (perhaps unintentionally) for the interface address/prefix and the routed, delegated /60 prefix.

After looking closely at my rules, I found that my source was set for an address as opposed to the network. One quick change and all was good in the Universe!

Nat reflection is ALWAYS the worse option to choose.. I don't understand why anyone would ever want to nat reflect.. if host.domain.tld is on the same network next to you - then why would you not just resolve host.domain.tld to that IP.. Why would you ever want to go to the public IP to be reflected back in?? As to forwarding port X to port Y.. That is always a work around in itself to all to go to the same service with the limitation of napt and only 1 public IP, etc. If you want to go to host.domain.tld:port then go there where host.domain.tld resolves to the local IP and not the public ip..

Ok, final update. Eliminated everything that had to do with this VPN, interface, rules, etc. Started all over, following all the steps, and everything is working as it should, without the manual routes. By the way, if you run into the routing problem, you can change the "Gateway creation" to BOTH or to IPv4 ONLY and apply/save ont both server and client side(!) That creates the new route. Thanks all for your time and effort

@andyc Yeah, i want to have access to my ESXi management from work and at home. (only for a while, as I am preparing everything for my VM ect ..) i will make a IP restriction or something like that if it's possible, to allow only my home public IP and the work IP Or i can just do a VPN with my pfSense (i saw come options to do this), i don't know, i'll think about it