Difference between revisions of "Talk:OpenVPN"

Revision as of 16:05, 25 August 2012

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 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 [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)

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)

Verbosity of article

I thought one mantra of the archwiki was "Don't just give me the 'how' - give me the 'why'", is that no longer so? Seeing that I don't seem to be able to be as terse as you guys want me to be, maybe I'd better leave the article in your hands instead? jhernberg (talk) 14:33, 17 August 2012 (UTC)

#"Don't just give me the 'how' - give me the 'why'", is that no longer so?

The answer is absolutely yes.

#Seeing that I don't seem to be able to be as terse as you guys want me to be maybe I'd better leave the article in your hands instead?

In the talk page, we talk about the page not the author. And it is a wiki page, it belongs to nobody. Everyone can improve it.

This page is in very high quality and help the Arch users a lot. Your effort are appreciated and please do not leave. :)

As the page length, it is only a suggestion. Many long pages on Arch Wiki duplicate text from upstream document. When upstream change something, these text may quickly become out of date. This is why stick to the upstream become a part of Arch philosophy.

-- Fengchao (talk) 03:32, 18 August 2012 (UTC)

Instructions on adding tun/tap support to the kernel configuration

If no one objeccts I will remove the instructions on how to add tun/tap support to the kernel configuration. After all the default kernel has the module, so it really doesn't belong in this article? -- Jhernberg (talk) 13:25, 23 August 2012 (UTC)

The default kernel is already properly configured, but if you build your own kernel make sure to enable the TUN/TAP module.

Kernel config file

Device Drivers --->
   Network device support --->
[*]Network device support
<M>   Universal TUN/TAP device driver support 

To see if your running kernel has this support enabled, run the following and check the output:

[myuser@rpi0 ~]# zgrep CONFIG_TUN /proc/config.gz 
CONFIG_TUN=m

CONFIG_TUN should be either 'm' or 'y'.

I'll leave this information here for a while

-- Jhernberg (talk) 08:25, 25 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.

-- Jhernberg (talk) 15:56, 25 August 2012 (UTC)

Moving the Creating a Public Key Infrastructure (PKI) section

Maybe it would be a good idea to move the creating a PKI section to its own page (easy-rsa) would be a good idea? It would make this article a lot terser and more to the point. Any comments? -- Jhernberg (talk) 11:45, 24 August 2012 (UTC)

This has also been done now.

-- Jhernberg (talk) 16:05, 25 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)

Proposed sections for future expansion of the article

To make the article shorter I move this previously html hidden stuff into the talk page.

-- Jhernberg (talk) 11:18, 25 August 2012 (UTC)

Pushing DHCP options to clients

Configuring client-specific rules and access policies

Routing all client traffic through the server

Running an OpenVPN server on a dynamic IP address

Implementing a load-balancing/failover configuration

Locking down security

Security through obfuscation

Port knocking

Running in unprivileged mode

Running in a chroot jail

Larger RSA keys

Enable the 256 bit AES (Advanced Encryption Standard) instead of the default 128 bit blowfish cryptographic cipher:

/etc/openvpn/server.conf

;cipher BF-CBC        # Blowfish (default)
;cipher AES-128-CBC   # AES
;cipher DES-EDE3-CBC  # Triple-DES
cipher AES-256-CBC

Revoking certificates

Configuring iptables for use with OpenVPN

Add a rule for the tun devices on both the server and the client.

/etc/iptables/iptables.rules

-A INPUT -i tun+ -j ACCEPT

Add a rule to accept connections on the OpenVPN UDP port (1194) on the server.

/etc/iptables/iptables.rules

-A INPUT -p udp --dport 1194 -j ACCEPT

If you use the iptables firewall on the server (elmer) add the following rules to /etc/iptables/iptables.rules, then restart iptables:

/etc/iptables/iptables.rules

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -j REJECT

If you use the iptables firewall on the client (bugs) add the following rules to /etc/iptables/iptables.rules, then restart iptables:

/etc/iptables/iptables.rules

-A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT
-A FORWARD -s 10.8.0.0/24 -j ACCEPT
-A FORWARD -j REJECT