This is a big mess and you would honestly be better served by renumbering than by creating a web of ugly NATs with conflicting addresses. The other solutions you will need to support this (eg. split-horizon DNS with multiple zones, possibly with automatic updating) will be difficult and messy and every subsequent person who has to deal with this network will curse your name forever and burn effigies of you and your team.
Nonetheless, it looks like the problem you are having is that the hosts on one side of the NAT (see? I can't even describe the sides of the NAT properly, because it is messy) don't have a path back to hosts on the other side. You have to add a NETMAP rule for the return path too (packets incoming from eth1 I presume).
But wait! That's done in the prerouting chain. So, the destination address will be set before the routing decision is made, which is pretty much the way it has to work... but your router has two routes for the "conflicting" network. So, it will prioritize by the usual means (narrowest matching prefix first; metric to break ties), causing some packets to be reflected back onto the network they came from instead of being routed across the NAT. They will be source-natted too. Unfortunately, the source address isn't used in routing, so you can't use the source address. The input interface isn't used in routing either, and once the routing decision is made you can't rewrite the destination address again.
So, you find, this cannot be done. You have two options. Preferably, you would renumber one of the subnets with the network address conflict because you are a good network engineer rather than an incompetent one and you make networks that are not unnecessarily complicated. Renumbering VPN subnets tends to be an uncomplicated task which at worst will require the use of sed, but perhaps you have one of those weird situations where renumbering either subnet is an inhumanly difficult task. OK.
If for whatever reason you can't do that, you will need an additional router to go with your split-horizon DNS. Set up a router for each subnet (in effect this means one router for the VPN clients, and one router for the hosts on the network which unfortunately uses the prefix you'd staked out for the VPN). Pick some other address range (and it would have to be one you could otherwise renumber one of the subnets to...) to be the "foreign" one.
Now, suppose we call the network with the VPN hosts side A, and the network with the non-VPN hosts side B. Suppose on router A you choose the "foreign" prefix to be 192.0.2.0/24, and on router B, it's 198.51.100.0/24. These will be the fake prefixes you use for hosts on that subnet to contact hosts with the conflicted prefix on the other subnet (don't use these they're reserved for documentation purposes in RFC5737).
The below rules are complicated because you can't use the input interface as a predicate in the POSTROUTING chain, and the source subnet is non-unique, so we have to prevent spoofing using a filter rule. It's also confusing because NETMAP decides whether to change the source or destination address based on what chain it's in.
In router A and B, add a rule for incoming traffic on the point to point link between the routers which I shall call ptp0:
router-a # iptables -t nat -A PREROUTING -i ptp0 -d 198.51.100.0/24 -j NETMAP --to 10.0.77.0/24
router-a # iptables -t nat -A POSTROUTING -d 10.0.77.0/24 -j NETMAP --to 192.0.2.0/24
router-a # iptables -t filter -A FORWARD -i \!ptp0 -s 10.0.77.0/24 -j DROP
router-b # iptables -t nat -A PREROUTING -i ptp0 -d 192.0.2.0/24 -j NETMAP --to 10.0.77.0/24
router-b # iptables -t nat -A POSTROUTING -d 10.0.77.0/24 -j NETMAP --to 198.51.100.0/24
router-b # iptables -t filter -A FORWARD -i \!ptp0 -s 10.0.77.0/24 -j DROP
Now, this part of the problem is solved, because you no longer have a single router which has both prefixes in its routing table. No solution which requires you to have the same prefix referring to two different networks with two different hosts on them in the same routing table can work; it is intrinsically impossible because of how routing works.
Oh, and I almost forgot - I believe your SNAT rule is not getting processed because nothing is matching it, but it's important to remember that once a connection gets stored in the NAT state table, it no longer gets processed by the SNAT rule and no longer gets counted in the statistics if I recall.
If you don't actually require that the subnets be separate, just use layer 2 bridging. It will make your life a lot easier.
Best Answer
It is in the man page. It means packets written/read to tun/network:
from --verb:
5 -- Output R and W characters to the console for each packet read and write, uppercase is used for TCP/UDP packets and lowercase is used for TUN/TAP packets.