@karldonteljames:

I don't really want to set a rule that allows all, then another to block DMZ to LAN; I would much rather set a rule that allows DMZ to access the internet only.

Problem is that you cannot define "the internet" in an alias or CIDR notation.
You could make a single rule with a negotiation "allow all but LAN" with the "NOT" checkbox. Deny LAN will finally catch with the hidden/invisible "block everything else" rule at the bottom of your ruleset. Problem is that such a rule implies something that is not expressively written and thus makes it hard to understand what you were doing in future reviews/changes. With two separate rules it's obvious and visible.

@karldonteljames:

I think I've got this now, please correct me if I wrong.

Nothing to correct, well done! And I mean really well done. You learned a lot, didn't you!

@karldonteljames:

Enable "Block private networks and loopback addresses" and "Block bogon networks" on all interfaces except LAN.

That's usually not really needed and if you use it then that'll be on WAN at best. The "Bogon" part can come handy there but better ISP filter that anyways. Except for edge-cases you will not have traffic from private IPs to your WAN anyways.
On local interfaces the "Block private networks" can do more harm than good. All local interfaces usually belong to private networks, aka  RFC1918.

Without knowing exactly how you have the NAT set up, the A pfsense will NAT to the (going to get this wrong as I don't see the diagram anymore) 10.0.8.1 IP as the client goes to the web server. Meaning, the rule is not to allow that internet client(it's internet IP) access but to allow the 10.0.8.1 IP access over port 80.

This is under the assumption that OpenVPN has routing information for the 192.168.125.x, and that network exists in both pfsenses as a routable network. Internet clients will be nat'd to the IP of the interface you specify, in this case, the openVPN IP of 10.0.8.1.

Again, going on conjecture and assumption of how the rules may be set up.

<breaks out="" dead="" horse="" beatin'="" stick="">Oh wait, nevermind.
So, I finally found time to upgrade from 2.3.4 to 2.4.0.
This upgrade seems to have fixed the rule issue I originally posted about. I upgraded and didn't have to do any wonky LAN setting changes to get IPv4 working again.
So I'm going to chalk this up to weirdness in 2.3.4 since 2.4.0 doesn't seem to have this issue and since everyone should probably update to 2.4.x I'm guessing this will get no more traction as it's now out of date. Upgrades /woot.

Now, to figure out why my dashboard says 2.4.2. is available but the update says I'm up to date at 2.4.0.</breaks>

Have a look at his earlier thread concerning this: https://forum.pfsense.org/index.php?topic=140777.0

That makes sense, thanks for the clarification!

You might try OpenVPN with a TAP interface, rather than TUN, as described here:
https://openvpn.net/index.php/open-source/documentation/miscellaneous/76-ethernet-bridging.html

Dear Sir
Thanks for your valiable information.Now I am able to block the free DNS also.I have made an allias and apply in the NAT rule.Contents are filtering as well as free DNS are being blocked.But this is a tidious and lengthy process.There are thousands of free DNS IP are exisitng. pfSense doesn't alowing me at all to put that huge amount of ip's in my allias list. Restriction is there for the number of entries.My question is there that is there any rule will be possible in pfSense that all the request will come to the pfSense and pfSense will reject if the DNS request are not matching which are mentioned in the DNS Server of the pfSense section.
Thanks in advance.

Thank you mate!!!! yes, corrected firewall rule and works immediately as expected! :-)

It still makes no sense. What is "Static routing network" and how does it work with the OpenVPN tunnels?

I might need a picture. I don't immediately see the topology based on your description.

See dig for a diagram with the sort of information that makes it easy for someone to help you.

I have the same problem in version 2.4.1. Did you find any solution?

Post a description of exactly what you're trying to do (example, I'm trying to forward port 1234/tcp and ports 4000-6000/udp to server at LAN address 10.x.y.z blah blah blah) and include screenshots of your port forwards and WAN firewall rules.

My initial guess would be either you're missing some ports in your NAT definitions, or ts requires static ports outbound.  I don't have the time now to look into that.

i had this issue with my unraid plex server , i had to change privilege on - off and off - on , also bridge to host or host to bridge till it works

You only need outbound NAT if you care what IP addresses are used by those servers for connections they INITIATE outbound.

There are several.  For me, the quickest is to go to Diagnostics - States and filter based on the IP of the NAS.

In general, I recommend against placing these types of services so that the public can access them.  Configure OpenVPN and then connect to your LAN via VPN, then hop over to the NAS.

The sticky is right at the top of this board, use your eyes and brain: https://forum.pfsense.org/index.php?topic=15811.0

Most residential ISP's do not allow port 25 or 80. Especially if those services are dynamically assigned IP's.
But it's worth a call to them to check it out. Maybe they can offer an upgrade.

PfSense be default doesn't know what the upstream end of the tunnel is doing with regards to routing. There is no routing protocol in existence (well at least with VPN solutions) that would tell pfSense that the upstream is actually forwarding traffic for your LAN network back over the VPN link to have two-way routing between the ends of the VPN tunnel. Such routing scenarios are always set up explicitly in coordination with both parties.