Nat – How to port forward over a VPN NAT

There are several issues here, mixed into one.

1. If DC2 can ping DC1, but not the other way around, then it is likely that the pfSense firewall is doing masquerading for the 192.168.1.0/24 network behind it. This would result in a situation where in the rest of the network the packets originating from DC2 actually look as if they originated on 192.168.3.100. When they get back there, the firewall captures them, performs the de-masquerade and all is good.
   However, this now creates a problem, because to the world outside of 192.168.1.0/24, that network has become unroutable. Since all networks involved are private networks anyway, I would suggest to remove the masquerading and rather just have a firewall and some proper routing.

2. The Rv082(A) has no knowledge of the existence of the 192.168.1.0/24 network, since it is hidden behind the pfSense firewall. So the first thing to do is put a static route into that device telling it to route all traffic for 192.168.1.0/24 into the VPN tunnel.

3. Now make sure that in the pfSense firewall you only have the necessary filters in place and all NATting is disabled.

If for whatever reason you cannot or do not want to remove the masquerading, you will have to create port forwarding rules in the pfSense for every single device and service that must be reachable from the outside. And you need to run split DNS, because the same names now have to resolve to different IP addresses depending on where the client is. This can get very messy very quickly and I would recommend not to do unless there really is no other choice.

If you don't like static routing, you could also enable RIP or OSPF in pfSense (not sure whether it has these features) and in the RV082 devices (if they have it), but then this answers is going to get a whole lot longer, so try static routing first.

You should reconsider whether any of the DNAT rules are required. You haven't provided a reason for it. Same with the SNAT rules, as they're forcing all of the connections to appear local for no clear reason.

If the DNATs are required, use connmark to mark and restore packets coming from the openvpn-as tun interface in the PREROUTING chain of the mangle table, and add a -m mark ! --mark <the mark you set> condition on your nat PREROUTING port 443 DNAT rule. This will prevent outgoing connections from being DNAT'd back to your device.

Edited based on your network:

Remove all SNAT rules. You can't audit connections on the openvpn-as server with this in place.

Make sure the openvpn-as server is routing connections back through your gateway. Either set the default route to the gateway (simple), or policy route (complex).

Change all of your DNAT rules to ignore your local source range, ie ! -s 172.16.0.0/24. If openvpn-as isn't also performing MASQUERADE or SNAT, you may need to add the VPN IP ranges as well as additional ! -s base/mask per range.