I am having a bit more look into this again.
It is possible I am misreading you at some point. But just to clarify; I have no issues with traffic being initiated from inside of my (home/OpenWRT) LAN and through the tunnell. I reach my external LAN (behind the OpenVPN server and PFsense) perfectly fine. With every services I need. Not quite sure if my OpenVPN server is running the traffic through NAT or routes, though. Maybe that has anything to do with this whole mix as well.
EDITED AFTER I WROTE THE LAST WORD UNDERNEATH: Yeah. Why would I need static ROUTES defined on the OpenVPN server if traffic isn't being routed anyway? Then it has nothing to say, except of what is inside the openvpn config file? Or am I wrong here?
Usually, I have a line in my OpenVPN server config that pushes the route to the client, and another for the DNS:
push 'route 10.0.1.0 255.255.255.0'
push 'dhcp-option DNS 10.0.1.1'
When you are saying that it pushes it to the clients: You're referring to the VPN clients right? Because the traffic FROM the client/OpenWRT side of things, are just fine. As mentioned.
The "From Proxmox" rule you have defined explicitly has a source of vpn and a destination of lan. The forwarding rule that has the same source and destination already does this exact thing. The "From Proxmox" rule is redundant.
In general, the rules that allow forwarding between two zones (say a > b) will also allow the return traffic (so b > a when b is replying).
And also, am I reading you right and you're applying that the rule that allows traffic from my LAN/OpenWRT and to the tunneling interface also allows traffic initiated from the external/VPN-network? I sure hope not! That would've allowed anything back from your every WAN and in to the local network, if working that way. You have to have one rule per direction, if you want to allow initiated traffic from both sides. I strongly assume.
I am getting return-packets from whatever PID initiates traffic from my (Home) LAN and --> through the VPN-server --> The Proxmox server/PFsense LAN... That works.
The only thing that doesn't, is to reach my (home/OpenWRT) LAN from the OpenVPN-server - through the tunnel - through the OpenWRT fw - to the whatever VLAN I define.
I did some research again the other day, and I found something interesting. Maybe you guys can have a look and see if this is something you have experience with: https://backreference.org/2009/11/15/openvpn-and-iroute/
This has examples in it, and explains a lot about what routes that shall be used. And that iroute line. And why it matters. The thing is just that this postings from 2009. Much have probably changed in OpenVPN software since then. And it's a little unwise to follow that old articles when it comes to network security in general
@stephendt ; I haven't tried this yet. But maybe I'll try it soon - In combination with a static route or two.
I have understood this much:
I reach the subnet defined on the OpenVPN-server's tun-adapter (which is the default one's being used: 10.8.0.0/24) from the subnet which is on the OpenVPN-serves' NIC - Which again is the LAN with the reset of my VMs on, all behind the PFSense.
If I try to ping one jump further, which will then be the 10.8.0.0/24-address assigned to the tun0-device on my OpenWRT firewall, I'm not getting there.
Which means, that it's the jump between 10.8.0.1 OpenVPN-server and OpenWRTs tun0 with 10.8.0.x.
In theory I should be able to ping the tun0 of my OpenWRT making sure I'm pinging from the right interface, on the OpenVPN-server. If not, there should be a fundamental issue. For instance some accept-rule missing on my OpenWRT. Or some obvious config blocking all traffic that way around. Maybe I'm scoping within the size of the issue. I know I remembered to enable kernel IP forwarding. But still I suspect that this has something to do with the OpenVPN NAT. I have no running software firewall on that VM.
My thoughts next will be to try to follow the advice of the OpenVPN server config change as in the link above. Next, find the correct static routes to define on the OpenVPN server kernel. I think that pinging the mentioned IP again, but first defining which source interface/IP-address for the ping I might get an idea of what route is missing. At least as the first step further.
Because so far I'm actually not sure from which of the interfaces I tried to ping from.
Maybe it tries both, as default ..? I don't know.
Give me all your thoughts and feedback here. I appreciate it. And don't worry - I will take it all in the best of ways.