As
@ColinTaylor suggests, this is NOT a port forwarding problem w/ the GUI vs. your own port forwarding rule. The GUI will do the job just fine.
The problem is that for clients on the LAN that are bound to the OpenVPN client, their replies from port forwarding over the WAN are being routed out the VPN (which the stateful firewall will NOT permit). And that's because the router doesn't have any known route back to the remote client other than the default gateway, which is pointing to the VPN.
There are several ways to address it.
1) Remove the server from the OpenVPN client by using Routing Policy and NOT including its source IP in your rule(s).
2) Use an OpenVPN client for remote access rather than access the server directly over the WAN.
3) If the remote client's public IP is well known (e.g., a workplace, frequented wifi cafe), add a static route that binds it to the WAN.
4) Port forward over the VPN rather than the WAN (assuming your VPN provider offers that feature).
5) Port-based PBR (policy based routing).
IOW, there are a multitude of ways to skin this cat, but you have to decide which best suits your purposes. Not all solutions are good in all situations.
FWIW, I recently helped someone configure their Plex server for remote access over the WAN using port-based PBR. Perhaps you'll find it helpful if you decide to take that approach.
Thanks for the link. Now I see why I was confused. I didn't realize table 254 was the main table. Usually when referencing tables, at least those well-known, you use the name, if only for reasons of clarity. ip rule add fwmark 0x7000/0x7000 table main prio 9990 Anyway, I have a problem w/...
www.snbforums.com