If you are still trying to setup:
You need to 2 openvpn instances on your local network (it’s perfectly acceptable to have both instances running on your router), one in server mode accepting connections (It sounds like you already have this working). You need a second openvpn instance in client mode connected to PIA.
You then need to swizzle the routing correctly and there are several ways to do it.
I find the simplest method (I do use debian instead of bsd and AWS instead of PIA, but those are interchangeable) is to setup a second routing table that has its default route the openvpn client’s interface).
So my main routing table (ipv4 version for brevity) remains unmodified:
main routing table
clifford@router:~$ ip route show
default via 68.224.108.1 dev enp6s0
10.0.0.0/24 dev enp7s0 proto kernel scope link src 10.0.0.3
10.0.10.0/24 dev enp2s0 proto kernel scope link src 10.0.10.3
10.0.20.0/24 dev br2 proto kernel scope link src 10.0.20.3
10.8.0.0/24 via 10.0.20.11 dev br2
10.8.10.0/24 via 10.0.20.20 dev br2
68.224.108.0/24 dev enp6s0 proto kernel scope link src 68.224.108.64
192.168.1.0/24 via 10.0.20.11 dev br2
alternate routing table with openvpn client default route
clifford@router:~$ ip route show table AWS
default via 10.0.20.11 dev br2
10.0.0.0/24 dev enp7s0 scope link
10.0.10.0/24 dev enp2s0 scope link
10.0.20.0/24 dev br2 scope link
10.8.0.0/24 via 10.0.20.11 dev br2
10.8.10.0/24 via 10.0.20.20 dev br2
68.224.108.0/24 dev enp6s0 scope link
192.168.1.0/24 via 10.0.20.11 dev br2
I find it convenient to have my openvpn client instance running in an LXC container acting as router, but you don’t have to do that, you can just as easily have the default route of your alternate routing table be the local peer address of the openvpn client’s tun interface:
default via (tun# peer address) dev tun#
Which is exactly what the routing table looks like in my openvpn client container:
openvpn client container's routing table
clifford@router:~$ sudo lxc-attach -n aws-openvpn-container -- ip route show
default via 10.8.0.5 dev tun0
10.0.0.0/24 via 10.0.20.3 dev eth0
10.0.10.0/24 via 10.0.20.3 dev eth0
10.0.20.0/24 dev eth0 proto kernel scope link src 10.0.20.11
10.8.0.0/24 via 10.8.0.5 dev tun0
10.8.0.5 dev tun0 proto kernel scope link src 10.8.0.6
10.8.10.0/24 via 10.0.20.3 dev eth0
192.168.1.0/24 via 10.8.0.5 dev tun0
None of that is unique to debian/aws (except for the actual commands), it’s the same concepts on a BSD/PIA solution.