Hi @johnpoz

I have NAT enabled on both pfSense firewalls, however as a test I disabled NAT to ensure all natting was handled by the Cisco router and I was still unable to reach the 10.0.20.10 client.

RFC1918 blocking is disabled on all the pfSense interfaces.

I can access all clients on the LAN network of the pfSense LAB with NAT enabled. I also have a static route on the Cisco router for 10.0.15.0/24 via 10.0.50.10 and I can access any host on that network with no issues.

After some more playing around today I got it working.
Firstly I had to assignin the ovpns1 interface and enable it under the Interfaces > Interface Assignments.
Then I was required to add the 10.0.100.0/24 network into the “IPv4 Local network(s)” under the OpenVPN Tunnel Settings, however this setting wouldn't apply until a reboot of the pfSense.

Thanks to everyone for the suggestions.

Tyler

Look at Redmine, and the Github repos (on the RELENG_2_4_5 branches) and see what's there.

The snapshots are automated and on a timer. There will not be a per-snapshot set of release notes.

The address does not change. Most devices use dynamic IP addresses, which are assigned by the network when they connect and change over time.

After attempting to manually start vnstatd, you can check its status using the following command:
service vnstatd status
You should ensure that the configuration file for vnstatd is correctly set up. You can find the configuration file at /usr/local/etc/rc.d/vnstatd. See if any parameters or settings that might have changed in the new version. If your system uses systemd, there might be conflicts between the init system and systemd. Ensure that vnstatd is configured to work correctly with your init system. Even though you haven't found anything in the General logs, it's worth checking other logs such as /var/log/messages for any potential vnstatd-related issues.

If its yours - I might steal it, I like it a lot ;)

But it would sound better if said in French I think ;) Love to use it on a call when dealing with some of my French speaking colleagues ;)

@johnpoz
You are 100% correct.
pfSense can port forward at any subnet behind other routers as NAT and Routing tables are correct. The problem was on my ISP and the new Public IP he gave me which was blocked in inbound traffic. SOLVED. Thanks a lot for your time.

Cool, thanks for confirming. 👍

@Gertjan I figured out it was a firewall issue within Windows just in time! That was my next step though :) Thank you for your offer of assistance! - Nic.

Thank you for your time Derelic. I looked at the interfce settings and found out, that I had left the subnet-setting for the interface at /32 instead of changing it to /24.
Maybe this setting is bit confusing, because if I should set a single IP-address for the router interface and not a subnet. I suggest giving this setting a separate line or at least a caption "subnet size" or something similar.
Anyway - excuse my dumbness.
Best, Karl

@grimm-spector Exactly, it will work just fine :)