Yes, then you do "traceroute 4.2.2.3" - you see that packets ARE TRYING to go through tun0. It doesn't mean they are reach other side.

First of all you HAVE to be able to ping other side of your tunnel. So, you have to ping 10.8.0.2 from 10.8.0.1, and 10.8.0.1 from 10.8.0.2. Your OpenVPN software has to create tunnel before.
When you get this, you can add route for OpenVPN IP, everything else will use GW on other side of the tunnel.
But, es I said before, first of all, the tunnel should work it self.

Right now, after you added "10.8.0.0/24 dev tun0 scope link" packets addressed to 10.8.0.x will definitely go to tun0. And if OpenVPN on other side works and connects to your computer you should "ping" its interface with IP=10.8.0.1.

That's right, but they are getting through because traceroute is pinging successfully through 10.8.0.1 then all the way to the US Server of 4.2.2.0/24.

That is successfully when doing the "route add -net 4.2.2.0 netmask 255.255.255.0 dev tun0" command first.

In that case add route for IP of your computer B = 10.8.0.1, like:
route add -net <IP> netmask 255.255.255.255 dev eth0

Delete default route trough eth0.
Add default route through tun0:
route add -net 0.0.0.0 netmask 0.0.0.0 dev tun0

Ok I just got it working, from a fresh start this is what was needed:
I just had to add a higher priority to 114.77.31.26 to route through eth0 (gateway 192.168.2.99) while let all other traffic route through tun0 (gateway 10.8.0.1) at a lower priority, therefor not breaking tun0. This is because 114.77.31.26 is the VPN gateway for tun0 so it needs to not route through tun0 (of course).

With that routing table shown all internet traffic routes through tun0 where only 192.168.2.0/24 and 114.77.31.26 route through eth0 (192.168.2.99).

Thanks for your help working this out nimnull22!

EDIT: I don't think the "gw 10.8.0.1" part is needed since 10.8.0.1 is the only peer on tun0

You can remove:
default via 192.168.2.99 dev eth0 metric 100

You do not need it any more.
And unfortunately you show your IP - it is not really good. I suggest to erase it.

yes you are right. if you are setting a default route that uses the vpn connection then, by defualt, linux will try to push all traffic out this way. what if you first define a route for the vpn network so that eth0 can use this then add the default route using the vpn tunnel? Something like this:
This is assuming that 4.2.2.1 is the ip of the vpn gateway or whatever you wan to call it at the far end and 192.168.2.99 is the ip of your regular gateway for your eth0 connection. If this doesn't work try playing around with the first route add command. Remove the default gw altogether and make sure the route add command works so that any traffic destined for 4.2.2.1 is working and that no other traffic that is not on your local network is working. If this works then try adding the second route add command, defining a default gw that uses the tun0 interface.

EDIT: I guess you can ignore what I wrote. I didn't notice that this continued on a second page

That's what I did and it worked
4.2.2.1 was just a test IP though. The other one was the global IP for the gateway, so adding that before the default route made it work.