From ArchWiki
Revision as of 16:00, 16 January 2016 by Ptolom (talk | contribs)
Jump to navigation Jump to search

Missing details

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" 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 [1] ). 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)

Personally and at the moment I don't have much time nor interest in updating this article. But I also think it could really benefit from having sections written on IPv6, L2 bridging and possibly a related article describing how to use iptables and other firewall software with VPN. I really hope that someone can step up to the plate and write the missing sections and to correct whatever I got wrong! Jhernberg (talk) 14:33, 14 June 2014 (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)

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)


If someone could add this section, it would be very much appreciated. Jhernberg (talk) 01:05, 28 June 2014 (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


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...

-- Jhernberg (talk) 21:58, 28 August 2012 (UTC)

Using resolvconf with user nobody


user nobody

is used in the client's config, the update-resolv-conf on down fails, because it is executed as nobody.

Using could be used as a workaround:

plugin /usr/lib/openvpn/ "script_type=down /usr/share/openvpn/update-resolv-conf"
-- DarkForce (talk) 01:35, 29 November 2012 (UTC)

Connecting to vpn server from Android

I recommend using OpenVPN for Android by Arne Schwabe which give allot of detail that can help troubleshooting. The ovpn file with embedded keys & certificates need to be used, See a proper example in the the link bellow. The reduced privileges won't work on android and also "key-direction 1" should be added. Server side configs are the same as in the wiki. --Dhead (talk) 22:51, 5 March 2013 (UTC

IPv4 forwarding

I'd like to suggest adding a section on IP packet forwarding info to this page. If you follow the instructions for setting up forwarding using iptables and ufw only, it still won't work without forwarding packets.

Traditionally, this has been a simple process of:

# sysctl net.ipv4.ip_forward=1

(or editing /etc/sysctl.d/30-ipforward.conf for a more permanent change)

But there is a bug right now where systemd-networkd overrides net.ipv4.ip_forward. This might be good to point out for people trying to setup OpenVPN on Arch.

As of now, someone setting up OpevVPN could only find this out from from a small link to enable packet forwarding and then catching the bug note on that page. Setting up OpenVPN was a frustrating experience since this was buried; I was stuck on this for several hours, and finally found the solution.

Thought this might be helpful for others out there. Respectfully, Jr000 (talk) 00:13, 29 May 2015 (UTC)

OpenVPN#Routing_all_client_traffic_through_the_server already says "Now you need to enable packet forwarding on the server.", with a link to Internet_sharing#Enable_packet_forwarding which contains the instructions and the note you mentioned. There is no point in duplicating the instructions, because sooner or later one version would inevitably become outdated/inaccurate. -- Lahwaacz (talk) 09:36, 29 May 2015 (UTC)

OpenVPN in a container

This is a good solution instead of messing around with iptables: —This unsigned comment is by Hendry (talk) 03:39, 6 August 2015‎. Please sign your posts with ~~~~!

Dropping root privileges: sub-section in DNS is out-of-sync

This edit reverted an explanation for setup with dropped root privileges. Now, the sub-section on this topic in the DNS section is out-of-sync because it depends on the reverted changes. If granting restricted sudo rights is indeed a hack, then that sub-section in DNS should be removed completely because that is exactly what it describes. The current state of the page is confusing because there are references to removed content.

That said, how does one run openvpn as an unpriviledged user without "sudoers hacks"? That's what the linked OpenVPN page advocates. If one were to write a section on this topic, then it would again be disqualified if this is really a "hack". Care to suggest an alternative?

Last comment: the policy of "not duplicating external pages" is detrimental. Everything on this wiki is a duplication of man pages and thousands of external forum posts. The point is to condense, adapt, and gather in one place, which was what the removed edit did, not blind copy-pasting. Please consider fixing this policy. —This unsigned comment is by Alexeicolin (talk) 16:21, 8 September 2015‎. Please sign your posts with ~~~~!

DNS section was removed, closing. [2] -- Alad (talk) 14:49, 8 September 2015 (UTC)
I added a paragraph to refer to the openvpn wiki with [3]. Please have a look and improve, thanks.
I sure agree that the sudo method described previously by Alexeicolin was not a hack, rather the opposite - good practice (why not?). But I believe Alad meant 'hack' positively and the main point is that we should try to reference upstream documentation (like from openvpn at hand) whereever possible.
Alexeicolin, please re-open this item if you want to discuss how to improve it further. Most readers of this article will be "openvpn client" users; to get DNS flying with it is interesting for all of them. --Indigo (talk) 15:30, 8 September 2015 (UTC)
Yes, also please coordinate with users of the upstream wikis, particularly when an existing effort on the topic was made. The current wording looks good to me. -- Alad (talk) 17:33, 8 September 2015 (UTC)
Re-opening, I am unsure what you mean. Which part c/should be coordinated with upstream wiki in this case?
For the wording: One part is handled, but the DNS part is not. Current instructions don't work for a non-root openvpn after [4].
Upstream has a method for it ([5] see also #Using_resolvconf_with_user_nobody), but I just tried because of this discussion item and have troubles as well to get it to work (anyone more luck? On debian that works just dandy for ages).
What problem do you see with Alexeicolin's work-around? --Indigo (talk) 23:22, 8 September 2015 (UTC)
The previous section was almost a word-for-word copy of what's in the openvpn wiki, respectively their documentation. Unless this is specific to Arch, expand there for more than just Arch readers to benefit, rather than duplicate efforts here.
As to sudoers, it's easy to misconfigure it and poke more holes in security, rather than plug them. And when you give the openvpn user/group unrestricted sudo access to /usr/bin/ip, you might as well make ip setgid to root.
The actual question would be why users have to resort to any of these methods. Were capabilities considered? Is there a bug report or feature request on this? -- Alad (talk) 00:01, 9 September 2015 (UTC)
Well, we now crosslinked the openvpn part that was duplicate in the adaptation. Managing resolv is distro-specific, I'd say. Capabilites: not sure, right off hand I would say it weakens security, because it would likely imply granting a non-root openvpn capabilities to net_admin whcih is (like setgid) more ACL than access to ip/resolv with a /bin/false user.
Let's wait a bit. So the questions are:
  1. Why does #Using resolvconf with user nobody not work (bug report?)?
  2. Is there a better work-around to restrict root openvpn while allowing it to manage DNS on disconnect, than the one added with [6]?
[7] --Indigo (talk) 10:57, 9 September 2015 (UTC)

update-resolv-conf causing DNS leaks

The update-resolv-conf script at is causing DNS leaks because resolvconf retains the old dns servers from before the script is called. I suggest adding the -x flag to resolvconf to exclusively use the new nameserver.

echo -n "$R" | $RESOLVCONF -x -a "${dev}.inet"

Ptolom (talk) 16:00, 16 January 2016 (UTC)