There are some things that I think would have been extremely helpful to add in this article, primarily relating to iptables. For example, in Routing_the_LAN_of_a_client_to_the_server it might have been useful to say, "do something like iptables -t nat -A POSTROUTING -o eth1 -j SNAT --to 10.4.4.30" rather than "Use the iptables NAT feature to masquerade the IP packets."
I think more handholding would help this article a lot--it certainly would have helped me figure this out much faster. If no one disagrees, I'd like to add several sections on appropriate iptables rules to add. Buhman 17:11, 9 April 2012 (EDT)
- No objections, all constructive contributions are welcome, just remember that an article shouldn't be just a list of instructions: "handholding" is fine as long as it also explains why something needs to be done, so in your example above the existent sentence should be kept and your iptables line should be presented just as an example. -- Kynikos 08:46, 10 April 2012 (EDT)
- To be honest, I think this article, the way it is now, uses way too much handholding. (I liked it more the way it was  ). It have things like: "Edit /root/easy-rsa/vars and at a minimum set the KEY_COUNTRY, KEY_PROVINCE, KEY_CITY, KEY_ORG, and KEY_EMAIL parameters (do not leave any of these parameters blank)", instead of just "Edit /root/easy-rsa/vars according to your preferences"
- Maybe the solution could be the path Beginners' Guide and Installation Guide took; One, super handholding-type guide, and the other as a checklist-type guide... hmm, maybe I'll write such article Chrisl (talk) 18:48, 16 August 2012 (UTC)
- I have some time to work on this again (vacation), hopefully I'll get at least some more stuff done. If someone wants to add iptables instructions please go ahead. There is some preliminary stuff that Kynikos uncovered :) Too much, too little handholding, it's hard too say, and it looks like opinions differ. Maybe let me be verbose and then try to tighten it up and remove unwanted verbosity? jhernberg 21:50, 16 August 2012 (UTC)
In any case, the article still needs a lot more information about the various ways that openvpn can be configured, and any help would be very much appreciated...:) jhernberg 21:55, 16 August 2012 (UTC)
- Well, I have created the checklist-type article, is here: OpenVPN Checklist Guide Right now, it has lots of things of the old openvpn article, but shorter. The idea is that it have links like "click here to see more details" pointing to the section of a full article explaining something, to avoid repetition. I must add that I think this way is more KISS. Chrisl (talk) 04:55, 17 August 2012 (UTC)
Link to upstream document instead of duplicating
This page is already a little long. OpenVPN has lots of good document here. It is better give some entry point and link to the upstream document instead of duplicate info here. After all, it is Arch Wiki, not OpenVPN wiki. -- Fengchao (talk) 03:38, 17 August 2012 (UTC)
Using openvpn scripts to set promiscious mode (and ipforwarding)
To me it appears a bad idea to use scripts to do this, as a server might conceivably have it enabled for other reasons than openvpn. Personally I'd be inclined in having the administrator hard code such changes to the system. If no one objects, i'll remove the accuracy template. Who knows maybe it could be added to a tips section or as its own entry. -- Jhernberg (talk) 17:10, 23 August 2012 (UTC)
- Have removed the accuracy template from the main page and put it here. Additional reasons to the above is that upstream has by default disabled scripts for security reasons, also the configs in this article drop root privs again for security reasons.
L2 ethernet bridging
I was going to add this information today, but realized that there have been so many changes in the init system, and that network configuration has gotten a lot more complex. I need to figure out what set of scripts to use to create the bridge interface, at the moment I'm inclined to go with the netcfg scripts. Any opinions? -- Jhernberg (talk) 16:40, 24 August 2012 (UTC)
Firewalls imo are really out of scope and would make the article even longer.. Any opinions on what and how much to add? Maybe something simple like these iptable rules:
-A INPUT -i tun+ -j ACCEPT
-A FORWARD -i tun+ -j ACCEPT -A FORWARD -i eth+ -j ACCEPT -A FORWARD -j REJECT
But then how much of a disclaimer would one write as someone could compromise the entire corporate security plan with an insecure nat translating VPN...
Proposed sections for future expansion of the article
Removed the stuff I had parked here. At the most it will become a tips and tricks section with links to the official documentation...
Using resolvconf with user nobodyIf
user nobodyis used in the client's config, the update-resolv-conf on down fails, because it is executed as nobody.
Using openvpn-down-root.so could be used as a workaround:
plugin /usr/lib/openvpn/openvpn-down-root.so "script_type=down /usr/share/openvpn/update-resolv-conf"