When you use TAP, you are *bridged* to the remote network, so you become a proper member of that remote network. IOW, if the remote network is 192.168.1.0/24, your OpenVPN client is configured w/ an IP from that same network (e.g., 192.168.1.100). Therefore, accessing resources is typically much easier because for all intents and purposes, it's as if your OpenVPN client is plugged directly into the switch at home! Even network discovery works. But when you use TUN, you are *routed* to the remote network, meaning your OpenVPN client is on a *different* network (e.g., 10.8.0.0/24) from the remote network (and network discovery does NOT work). Now you are likely to run into personal firewall issues because the remote network sees your OpenVPN client as a potential threat. You will likely have to reconfigure those firewalls to allow access by the VPN's network, or disable their firewalls completely.
All that said, one "trick" to get around some of these personal firewall issues w/ TUN is to NAT the inbound traffic from the OpenVPN client w/ the LAN ip of the router as it's dropped on the private network, so it *appears* to the targeted device that the source IP is from the same local network.
Code:
iptables -t nat -I POSTROUTING -s 10.8.0.0/24 -o br0 -j SNAT --to $(nvram get lan_ipaddr)
The above would need to be added as a nat-start script.
Many users find this quite useful since it avoids having to reconfigure personal firewalls.