Well if you have your vpn up, and it reports the vpn IP as your ddns name, and then you ping the ddns name - then yeah you would be pinging the vpn endpoint.
@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?
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.
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(!)
