Bug 181000 - net-misc/openvpn-2.1 initscript breaks non client-server setups
Bug#: 181000 Product:  Gentoo Linux Version: unspecified Platform: All
OS/Version: Linux Status: RESOLVED Severity: normal Priority: P2
Resolution: FIXED Assigned To: uberlord@gentoo.org Reported By: gentoo.daniels@chacal.com.ar
Component: Applications
URL: 
Summary: net-misc/openvpn-2.1 initscript breaks non client-server setups
Keywords:  
Status Whiteboard: 
Opened: 2007-06-05 20:20 0000
Description:   Opened: 2007-06-05 20:20 0000
Initscript for openvpn 2.1 assumes a client/server setup. It relies on finding
a "remote" setting in the config file to decide this is the client side of the
connection. In such case it starts openvpn with special "client" arguments like
"--no-bind" and up/down scripts to handle DNS configuration.

However, openvpn is also used in true "peer" mode with a static key, like when
connecting two routers to route traffic between different networks. Although
"remote" options are usually present on both sides, none of them is a "client"
in the way initscript considers it. They should be started in the way
initscript now starts a "server".

In this scenario DNS configuration is usually static or managed outside of
openvpn configuration, but I will not reopen the discussion in bug#132932.

The biggest problem lies in the argument "nobind" that intiscript uses to start
what it considers a "client", it makes both enpoints to talk on random ports,
not listening on the right port for the other side (it gets more funny if you
consider firewall rules).

I don't see an easy way to decide between "I am a client in a client/server
configuration" or "I am a peer in a peer configuration", since "mode p2p" just
means "I am NOT a server". 


Reproducible: Always

Steps to Reproduce:

------- Comment #1 From Jakub Moc (RETIRED) 2007-06-05 23:48:45 0000 -------
*** Bug 181031 has been marked as a duplicate of this bug. ***

------- Comment #2 From Roy Marples (RETIRED) 2007-06-29 09:19:30 0000 -------
Good points.

I've added DETECT_CLIENT variable to /etc/conf.d/openvpn which toggles this
behaviour which should fix this.