@stephenw10

Yes it is. And I disabled vmware virtual network local dhcp

ANd it works. Thank you for your patience ! You really helped me out on this, have a nice day/night

c3e53068-4ad2-4014-9e91-1c1ec4ab18d3-image.png

@sabrielandoj
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.

Thanks for the suggestion but unfortunately no PING.
Since I am able to ping 172.30.2.1 (but not 172.30.2.2), could it be something related to firewall or routing?

@autourdupc said in VLAN to LAN ping always possible despite rules:

Next time, i will ask community before spending soo much time !

What we are here for.. If there is some issue you have question on - or not sure if your understanding something correctly.. Yup just stop on by, here to help.

@johnpoz

Yap! You are right... Some times we don’t think as it should be. It’s exactly the same situation that I’ve with the printer – just an IP assign and everything is working.

As far as I know, TrueNAS (before FreeNAS) has not any internal firewall. At least configurable with the GUI. I’ll investigate deeper.

Maybe it’s the gateway (I’ve some doubts that is wrong), so I’ve to confirm.

For testing, I’ll also change the NAS to the LAN (same net where I’ve also the pfSense) and check if anything changes.

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

@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