1. Use "tun", that is for routing between different subnets at each site. "tap" is for bridging, when you want the same subnet everywhere and broadcast traffic to go across the OpenVPN and be seen everywhere.
2. You don't need to change any NAT. NAT is not needed between the subnets on your private intranet - they can route happily to each other across the secure OpenVPN links. The internet traffic at each office goes straight out the office WAN/s and the automatic outbound NAT takes care of it. (If, one day, you want to send internet traffic from a branch office across the OpenVPN to the main office, then out to the internet, then you have to mess with manual NAT)
3. Each office has a LAN subnet, and each OpenVPN link is a subnet - this is the "Tunnel Subnet". Technically the tunnel subnet for a single site-to-site connection can be just 4 addresses (a "/30"). But it is much easier on the brain to give it a "/24". e.g.
Main Office - 10.77.0.0/24
Branch 1 - 10.77.1.0/24
Branch 2 - 10.77.2.0/24
OpenVPN Tunnel Main to Branch 1 - 10.78.1.0/24
OpenVPN Tunnel Main to Branch 2 - 10.78.2.0/24
Make up 10.n.n.0/24 numbers to your liking.
4. The OpenVPN client keeps trying every 60 seconds, forever until it gets a response. In my experience, OpenVPN is very good at reestablishing itself after 1 end has gone away and come back again.
If you need Branch 1 and Branch 2 to talk to each other, then make another OpenVPN site-to-site between the 2. Then if Main office is down, branch 1 and 2 can still communicate. Note: It is possible to route from branch 1 to branch 2 via main office, but in this 3 office triangle it is simple to add the 3rd OpenVPN link.
