The "session created" and "session deleted" messages were useful when a single OPENVPN_SERVER object handled multiple UDP sessions.
Now that each session has its own OPENVPN_SERVER object and session creations/deletions are logged by PROTO, the messages are redundant.
In future we will change the OpenVPN implementation so that the multi-session handling code is deleted.
The messages were like this:
OpenVPN Module: The OpenVPN Server Module is starting.
OpenVPN Session 1 (192.168.122.211:47390 -> 0.0.0.0:1194): A new session is created. Protocol: UDP
OpenVPN Session 1 (192.168.122.211:47390 -> 0.0.0.0:1194): Deleting the session.
OpenVPN Module: The OpenVPN Server Module is stopped.
ProtoOptionsGet command - Lists the options for the specified protocol
Help for command "ProtoOptionsGet"
Purpose:
Lists the options for the specified protocol
Description:
This command can be used to retrieve the options for a specific protocol.
Detailed info (e.g. value type) will be shown.
You can change an option's value with the ProtoOptionsSet command.
Usage:
ProtoOptionsGet [protocol]
Parameters:
protocol - Protocol name.
ProtoOptionsSet command - Sets an option's value for the specified protocol
Help for command "ProtoOptionsSet"
Purpose:
Sets an option's value for the specified protocol
Description:
This command can be used to change an option's value for a specific protocol.
You can retrieve the options using the ProtoOptionsGet command.
To execute this command, you must have VPN Server administrator privileges.
Usage:
ProtoOptionsSet [protocol] [/NAME:option_name] [/VALUE:string/true/false]
Parameters:
protocol - Protocol name.
/NAME - Option name.
/VALUE - Option value. Make sure to write a value that is accepted by the specified protocol!
Previously, the file needed to be present in order for the setup to work.
This commit removes the requirement so that the setup can be ran from the build directory without the need to copy the file (which is now removed from the repository).
SoftEther VPN originally created the NIC in the UP state and never changed it, even when the the client was not connected.
The behavior was changed in 59e1483dbf, which also added the NicDownOnDisconnect option
The option was disabled by default for backwards compatibility with scripts that don't check whether the NIC is down, but it's not ideal.
This commit forces the correct behavior and removes the commands "TUNDownOnDisconnectEnable", "TUNDownOnDisconnectDisable" and "TUNDownOnDisconnectGet".
PortsUDPSet: This command can be used to specify a single or multiple UDP ports the server should listen on. "0" can be specified to disable the UDP listener.
Administrator privileges are required to execute the command.
PortsUDPGet: This command can be used to retrieve the UDP ports the server is listening on.
The two commands replace the functionality that was previously provided by OpenVpnEnable and OpenVpnGet, respectively.
Now that Proto supports UDP, the server can handle multiple protocols on each UDP port.
The UDP ports are specified by the "OpenVPN_UdpPortList" configuration setting, because:
- OpenVPN is currently the only UDP protocol supported by SoftEther VPN to allow a custom port number.
- Before Proto was introduced, a unified interface for the protocols didn't exist; each protocol implementation had to create its own listener.
In preparation for the upcoming WireGuard implementation, this commit renames "OpenVPN_UdpPortList" to "PortsUDP", which should clarify that the setting is global.
The change is reflected in the code. Also, the ports are now stored in a LIST rather than a string. The conversion between string and LIST only happens when loading/saving the configuration.
The default UDP ports are now the same as the TCP ones (443, 992, 1194, 5555).
This allows an OpenVPN client to bypass a firewall which is aware of the protocol and is able to block it.
The XOR mask set on the server has to be the same on the client, otherwise it will not be able to connect with certain obfuscation modes.
A special OpenVPN client built with the "XOR patch" is required in order to use this function, because it has never been merged in the official OpenVPN repository.
Two parameters are added to the server configuration: "OpenVPNObfuscationMethod" and "OpenVPNObfuscationMask".
Their value can be retrieved with "OpenVpnObfuscationGet" and set with "OpenVpnObfuscationEnable" in the VPN Command Line Management Utility.
With server certificate validation enabled, vpnclient unconditionally
stopped connection on untrusted server certificate. Added account
configuration parameter to retry connection if server certivicate failed
validation.
On startup client creates TUN interface in UP state and kept it UP even
if connection to the server was lost. Creating interface in DOWN state,
turning it UP on successful (re-)connection to server and DOWN on either
disconnect or connection loss would enable DHCP client (say dhclient5)
to detect necessity for lease renewal.
Added a client configuration parameter to create TUN interface in DOWN
state and commands to enable, disable, and query the configuration
parameter.
Enabling the parameter causes client to put all unused TUN interfaces
DOWN, create new TUN interfaces in DOWN state, and turn TUN interfaces
corresponding to active sessions DOWN on connection loss or
disconnecting from server.
Disabling the parameter forces client to turn all TUN interfaces UP and
create new TUN interfaces in UP state.
Default value is 'Disable'.
* Improvements on the behavior of the reinstall command of Windows Virtual Network Adapters.
When reinstalling the device driver of the Virtual Network Driver card, we changed the behavior as to cleanup the older driver before installing the newer driver.
* Improvement of the senetence. Add the same sentence to the Taiwan language file.
* Delete the old MsUpgradeVLanWithoutLock_old() function.
Fixed an issue that the VPN Client Virtual Network Driver fails to communicate when LTE or 3G wireless modems are used to connect to the internet by the computer running Windows 10 Spring Creators Update (version 1803). Please be careful that It is necessary to reinstall the device driver of the Virtual Network Adapter after upgrading the VPN client to build 9666 or later in order to solve the problem.
