Bug #6559
closed
OpenVPN 'mode server' directive missing
Added by Geoff Jones almost 9 years ago.
Updated almost 8 years ago.
Description
When creating a new OpenVPN server, the "server mode" web interface drop down does not influence the written configuration file.
By default, no "mode" directive is specified in the written server configuration, resulting in OpenVPN defaulting to a peer-to-peer configuration (behavior since ovpn 2.0). This changes the behavior of the management socket (preventing the status overview page from detailing connected clients), and only allows one client at a time to connect (subsequent connections will terminate the original connection).
This bug is "masked" if a tun interface is specified, as the 'server' helper directive is written to the configuration file, which changes the default mode to 'server'. It is therefore only noticeable with a tap device type.
Correct behavior should be a 'mode server' line is written to the configuration file if any of the "remote access" modes are selected in the gui, and no 'mode' line written to the configuration file if a peer-to-peer server mode is selected.
Ref: https://openvpn.net/index.php/open-source/documentation/manuals/65-openvpn-20x-manpage.html
Files
Workaround is to set 'mode server' in the advanced options section.
It's not quite that simple. There are cases when it must be omitted as well, such as some tap bridge scenarios, or OpenVPN will throw a configuration error. Unless that's changed recently.
What are the exact settings in use on the OpenVPN server that lead to it being omitted when you believe it should be present?
Jim Pingle wrote:
What are the exact settings in use on the OpenVPN server that lead to it being omitted when you believe it should be present?
Simply setting the device type to 'tap' and server mode to 'Remote Access', with no other settings, should lead to it being present in my opinion - it is after all a client-server model at that point. This obviously requires a bridge to be configured between the OpenVPN server adapter and some other adapter to function. It should not be present however, if peer-to-peer mode is selected.
I've just taken a closer look at this and found that setting 'Bridge DHCP' to 'true' and selecting a random 'Bridge Interface' (the actual interface selected appears to have no effect on the config that I can see), results in the 'mode server' being written. I haven't seen the configuration error you mention being thrown - what combination of settings do you believe results in the error?
- Status changed from New to Feedback
The config either ends up with "mode server" or "server-bridge" depending on the specifics of your config. That's in accordance with the OpenVPN man page:
Don't use --server if you are ethernet bridging. Use --server-bridge instead
In OpenVPN 2.3, it doesn't complain if you specify both server-bridge and 'mode server'. I believe what JimP is recalling is that used to be an invalid config in older OpenVPN versions if you specified both.
Valid or not, I don't see where that's ever necessary, or why it'd be desirable. server-bridge expands to include 'mode server'. So adding "mode server" to something that has "server-bridge" is a no-op.
Could you provide a config that exhibits a problem?
Chris Buechler wrote:
The config either ends up with "mode server" or "server-bridge" depending on the specifics of your config.
My generated config has neither "mode server" nor "server-bridge". This is when all tunnel settings are left as default. I'm suggesting the default should be 'mode server', if 'Remote Access' is selected (as OpenVPN must be run in server mode for remote access clients).
Generated config:
dev ovpns2
verb 1
dev-type tap
dev-node /dev/tap2
writepid /var/run/openvpn_server2.pid
#user nobody
#group nobody
script-security 3
daemon
keepalive 10 60
ping-timer-rem
persist-tun
persist-key
proto udp
cipher <REDACTED>
auth <REDACTED>
up /usr/local/sbin/ovpn-linkup
down /usr/local/sbin/ovpn-linkdown
local <REDACTED>
engine cryptodev
tls-server
tls-verify "/usr/local/sbin/ovpn_auth_verify tls '<REDACTED>' 1"
lport <REDACTED>
management /var/etc/openvpn/server2.sock unix
ca /var/etc/openvpn/server2.ca
cert /var/etc/openvpn/server2.cert
key /var/etc/openvpn/server2.key
dh /etc/dh-parameters.<REDACTED>
crl-verify /var/etc/openvpn/server2.crl-verify
tls-auth /var/etc/openvpn/server2.tls-auth 0
- Status changed from Feedback to Not a Bug
No response or confirmation from anyone else seeing the issue on recent versions.
As stated before, it isn't that simple. You have to give it something to work with. A tunnel network with a mask bigger than a /30 size network will kick it into server mode, or you have to setup bridging, etc.
It is only doing what it is told (or not told, as the case may be), to do.
Jim Pingle wrote:
or you have to setup bridging, etc.
It is only doing what it is told (or not told, as the case may be), to do.
We are talking specifically about TAP here (i.e. bridging). If you configure pfsense as a "remote access" TAP server, one would expect 'mode server' to be written to the configuration file. Currently it does not, and you need to add it manually in the 'Custom options' section (unless you also select the 'Bridge DHCP' option). To clarify, there is no issue if using TUN.
If it's remote access, you need to give it a tunnel network. It is not valid for remote access without a tunnel network.
Or if it's a bridge, you have to configure the bridging options.
What you made is not a valid configuration for either case, but may be valid for some other use, so it isn't rejected via input validation.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 