OpenVPN wiki article: server push config

Talk about Documentation
1

@JW0914 -

You're listed as the most recent editor of the OpenVPN wiki article, so I'm directing my question to you for the moment (obviously loop in other contributors, if any, as you see fit).

My question is about the following push statements in the server setup:

  uci add_list openvpn.vpnserver.push='route-gateway dhcp'
  uci add_list openvpn.vpnserver.push='route 192.168.200.0 255.255.255.0'
  uci add_list openvpn.vpnserver.push='dhcp-option DNS 192.168.1.1'

In the "Installing and using OpenWRT" forum section, there have been a bunch of threads (some of which I have contributed to) where the users have had issues connecting to their local network and/or the internet via their VPN. The solution has often been to remove the first quoted line, and to adjust the other two lines to match their main LAN config as shown below (I changed only the pushed route, but both of these would be changed to another network if 192.168.1.0/24 was not the default).

  uci add_list openvpn.vpnserver.push='route 192.168.1.0 255.255.255.0'
  uci add_list openvpn.vpnserver.push='dhcp-option DNS 192.168.1.1'

So my questions are as follows:

  1. Why does the wiki recommend pushing the route of the VPN server itself -- I think that this is not necessary since the VPN client will get an IP in the VPN server's network and will already understand that route. Further, from what I can tell, the push directive should provide the route that is not already known -- that is, to the main LAN/gateway address.
  2. Why does the wiki suggest pushing route-gateway dhcp? Based on my first question, it seems that just pushing the route to the LAN/gateway does the trick.
  3. Would it make sense to add a note to the wiki that states a key assumption -- that the main LAN is 192.168.1.0/24 and that it is assumed that the router and DNS services are on 192.168.1.1 (the typical default address of an OpenWRT router). If this is not the case (a non-default config) obviously the dhcp-option DNS (and the push route to the main LAN) would need to be modified to match the user's currently configured LAN and router address?

I'll fully admit that maybe there are some things about the OpenVPN configuration recommendations in the wiki that I am missing, but based on a number of threads (and the resolutions of those issues), I am wondering why the recommendations are they way they are. Maybe you can shed some light on what I'm missing and/or test to see if my solutions/suggestions are worthy of being included/updated in the Wiki (or maybe as troubleshooting/alternative methods of configuration).

Thanks!

1 Like
2

I've invited @stangri to the conversation, as I'm assuming he originally wrote some of the steps for a Linux distro other than OpenWrt, or referenced from a source that did, as a couple of options (route_gateway & redirect_gateway) are usually required in most, if not all, other Linux distros, but not required in OpenWrt.

  • I'm not implying, nor should any infer, the usage of these options in OpenWrt is wrong, as there's multiple ways to get to the same solution.

Questions

  1. I've never had a use for Gateway Redirect, so I'm not familiar with options pertaining to it, such as route_gateway and the reasoning for it's usage. The best I can do, until Stan replies, is quote from the man page
    • --route-gateway gw|'dhcp'
      • Specify a default gateway gw for use with --route
      • If dhcp is specified as the parameter, the gateway address will be extracted from a DHCP negotiation with the OpenVPN server-side LAN.

  2. Same as #1

  3. That's not a bad idea, however Stan may have reasons for not doing so, or he may have taken the stance I did when I wrote the Comprehensive wiki:
    • I purposefully chose not to explain what any specific config option meant, because once you start explaining the purpose of any one config option, you inevitably walk into "which ones do explain and which ones don't I".

      This leads to more questions regarding an arbitrary user's knowledge and that it's likely any two users will have different experience levels, so where does the explaining of config options stop? Ultimately, for aesthetics and the wiki's ease of use, a wiki author will likely choose an all or nothing approach of either explaining every config option used or explaining no config option.
      • I personally am a big believer in self-help, especially if the knowledge is fairly easy to find, and its because of this mindset I chose to not only link to the OpenVPN Man Page and HowTo repeatedly in the Comprehensive wiki, but also mention both repeatedly throughout the wiki.

        Perhaps providing a sentence directing users to the Man Page for config option definitions would be more fulfilling to a user, killing two birds with one stone... What are your thoughts?
    • Stan, what would you think about adding something similar to the VPN Wikis section that's located at the bottom of the Comprehensive wiki?
3

@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?

1 Like
4

As @Per points out, route-gateway dhcp probably should be removed from the wiki:

According to the linked article, that directive is supposed to be used only with TAP configurations, not TUN:
The problem is that "route-gateway dhcp" only works on platforms where the TAP driver negotiates a DHCP client handshake. Currently, only Windows support this out-of-the-box (Windows supports it not because of any special code in the Windows TAP driver, but because the Windows DHCP client automatically binds to TAP adapter instances when they transition to the "up" state).

So maybe the original guide worked well on another platform but needs to be adjusted slightly for OpenWRT?

5

I've only seen one thread to that effect, please post links to the "bunch".

You may have linked a wrong comment, because the one you've linked doesn't state @Per's opinion that that line should be removed from wiki.

Obviously, the goal of the simplified OpenVPN server setup page is to get majority of users going with the little effort on their part. If it turns out that:

  uci add_list openvpn.vpnserver.push='route-gateway dhcp'
  uci add_list openvpn.vpnserver.push='route 192.168.200.0 255.255.255.0'

are breaking something for a lot of users, they should be removed. I'm yet to see the evidence of that and ultimately I'd prefer @JW0914 to make that call.

Alternatively, there was a link (or a paragraph) to "Fine-tuning" OpenVPN setup, maybe some information can be kept there for a while as a test wherever the main instructions should be changed.

6

Sure. In no particular order, listing threads I have contributed to since January:
One
Two
Three
Four
Five
Six

Sure... while @Per did not explicitly state that it should be removed from the wiki, the comment that it is supported only on Windows implies that may cause problems on client platforms other than Windows. Further, when I clicked through that link, it indicated that the directive is intended for TAP implementations, and since the wiki sets up OpenVPN with tun, it would seem to be unnecessary at best, and problematic at worst.

I do believe that those two lines are either breaking OpenVPN on OpenWRT, or at least not achieving the functionality described by the wiki's preamble. This can be said for at least those users who have asked for help on the forum (there is obviously no data on how many users were successful directly from the wiki and/or who made modifications to their configurations without commenting on the forums).

1 Like
7

Thank you! I've updated the article for now, will be able to test the new config within a few days.