@JW0914 - thanks for the response and for inviting @stangri. (@stangri -- I'd love to hear your thoughts if you get a chance, too).
I think that one of my general concerns, maybe as related to my 3rd question, is that many people look at the Wiki article (which is really well done, btw!) as the gospel when it has to do with OpenVPN on OpenWRT. With respect to the point about the knowledge level and the level of explanation -- I agree that it is a complex balancing act, but interestingly, from this thread today, the use of the word 'mandates' shows that some readers are not looking at the guide as a generalized template:
Maybe the wiki could list the key configuration assumptions/prerequisites, and for it to state that this is a template that may require some adjustments to work if those configuration details are different than assumed in the guide. This might help suggest in more explicit terms that it is a good idea for the user to learn (or ask) about the purpose and meanings of each of the directives.
Back to my first 2 questions:
In my experience with OpenVPN on OpenWRT, the default route and gateway come from the server directive implicitly without the need to push route-gateway dhcp or push route of the server/network (server 192.168.200.0 255.255.255.0 --> server @ 192.168.200.1, clients get issued an IP address, subnet mask, and gateway upon connect and therefore have that information inherently). Maybe there's no harm in pushing this to make it explicit? Maybe it is required on other platforms?
As I mentioned when I opened this thread,I have found that I need to push the route to the LAN (assumed here to be 192.168.1.0 255.255.255.0), else the LAN (and I think internet, too) will not be accessible. Why does the wiki's push route directive not specify this network? Is the push to the 200 network a typo? is the 1 network not recommended or just not needed in the original author's use-case?
While we're discussing this wik article, a few other things I thought might be interesting... I'm mainly bringing these up to learn from @JW0914, @stangri, and others who may have insight/thoughts/recommendations/reasons for things to be done a certain way:
There are a few other differences in how I've set my server config -- for example, I declare the topology subnet on the server but I don't push it to the client (and it is not declared in my client configs). Again, maybe the explicit push is harmless (or required for certain platforms, but I haven't seen any issues without it (my platforms: server is OpenWRT, clients are OpenWRT travel router, Mac w/ Tunnelblick, and iOS devices).
And there are three other push directives in the wiki's server that seem redundant -- the client already has persist-key, persist-tun, and compress lzo which are also in the push directives. Again, not sure if this s best practice, required for certain platforms, or redundant, but I don't push those directives and things work well in my environments.
Finally, I don't push the redirect-gateway def1 directive -- instead, I include (or exclude) it from my client configs so that I can opt to/not to send all traffic through the tunnel. I do this because then I can have 2 client configs (one with the redirect, one without) to use based on my connection needs (do I intend to tunnel all traffic through the VPN or am I just looking to gain remote access to certain network resources without the need to redirect unrelated traffic?). Is there a better way for me to achieve the same result (i.e. decide the connection type from the client side as needed)? In the wiki's context, it describes gaining access to the router/network from afar, but doesn't describe the use case of tunneling all traffic through the VPN, so strictly speaking, the redirect is not entirely necessary based on the wiki's stated use case. With that in mind, should the redirect be removed or explained or should the tunneling use-case be added to the description at the top?