The Internet Protocol looks only at the destination IP address when routing packets. They do not care where a packet came from. They do not care that the packet might be part of a larger session or connection or application. The only thing that matters is the destination IP address. IP then looks at the routing table to determine what to do with each packet, based solely on the destination address. (Technically, things like statefull firewalls and policing routing can make this a lie, but it will do for current purposes.)
As @Nikita points out, and the output of route(8) shows, hosts like 192.168.0.3 (and, presumably, other hosts on your network) only know to send packets to your router at 192.168.0.1. They do not have anything to tell them to send packets to your OpenVPN system at 192.168.0.2.. So .3 and friends will be sending all their traffic to your router. Your router doesn't know about your VPN. Your router will either discard the packets, or send them to the public Internet (where the next hop router will likely discard it).
The are multiple possible solutions.
Solution #1 - Easy But Inefficient
Tell your router that 10.8.0.0/24 is reachable via the gateway at 192.168.0.2. This will result in a hairpin route -- packets will go from hosts like .3, to your router's LAN interface at .1, and then back out the same router interface and to the OpenVPN gateway at .2. This is inefficient, but should work.
You don't say what your router is, but if it was Linux, the command would be something like:
ip route add 10.8.0.0/24 via 192.168.0.2
Solution #2 - Unintrusive But Tedious
You can configure a static route on each LAN host, telling them the same routing tidbit as #1, but everywhere. This would be a minor pain to configure and maintain, but would be the most efficient solution that keeps your existing network topology. Same command as above (for Linux), but you have to run it on every LAN host. You also need to do it on all other devices that should work over the VPN, including Windows boxes, printers, tablets, phones, wifi lightbulbs, etc. You'll eventually forget one and wonder why it doesn't work, spend time pulling your hair out, and then feel like a dope when you remember why.
Solution #3 - Sophisticated But Disruptive
You can put your VPN gateway on the routing path to the Internet. There are two sub-alternatives here.
Solution #3A - VPN On Router
Even consumer routers can sometimes run an OpenVPN implementation these days, especially if you use third-party firmware (OpenWRT, DD-WRT, etc.). However they often lack the CPU horsepower for adequate performance. You could also replace the consumer with something better -- a commercial router, or another Linux. You might even be able to retask your VPN gateway as VPN+router+firewall.
In this scenario, the VPN and the router are the same thing, so you don't have to worry about the router getting along with the VPN gateway. This is likely the most efficient, in terms of network design.
Solution #3B - Stack Gateway and Router
You can put the VPN gateway between the router and the rest of the LAN, with different IP subnets on either side of the VPN gateway. All other LAN hosts send to the VPN gateway to get to the Internet. The VPN gateway sends and forwards to the router to get to the Internet.
This will require putting two network interfaces in the VPN gateway -- one for the LAN, and one for the handoff to the rotuer. (Or do a hairpin route on the VPN gateway, which is worse than #1 because now all Internet traffic is hairpinning).
The main advantages to this approach are: You can keep your existing router (maybe your ISP makes you use their equipment, maybe it has some other useful property for you). If the VPN box breaks down, you can pull it out of the picture, and (maybe) quickly reconfigure the router to take its place.
