This commit also fixes a bug which caused the server to initialize all boolean options to false.
It was caused by SiLoadProtoCfg() not checking whether the item exists in the configuration file.
CfgGetBool() always returns false if the item doesn't exist.
From a functional point of view, the main improvement is that GetIP() now always prioritizes IPv6 over IPv4.
The previous implementation always returned an IPv4 address, unless not available: in such case it failed.
This means that now connections to hostnames should be established via IPv6 if available.
From a programmer point of view, getting rid of the insane wrappers is enough to justify a complete rewrite.
As an extra, several unrelated unused global variables are removed.
Before this commit, the IP address reported by the NAT-T server was immediately discarded.
That's because the peer should be accessible via the IP address used to establish the TCP connection.
User "domosekai" (https://www.domosekai.com) pointed out that the NAT-T IP address should be taken into account.
In his case it's required due to his broadband carrier's NAT causing TCP and UDP to have different external IPs.
Co-authored-by: domosekai <54519668+domosekai@users.noreply.github.com>
This greatly improves performance and reduces the binary's size (~0.2 MB vs ~5 MB).
All recent Windows versions are supported, starting with Vista.
No dialogs are created, aside from error/warning ones in case of failure.
The only dependency (aside from Windows libraries) is libhamcore.
BOOL was just an alias for bool, this commit replaces all instances of it for consistency.
For some reason bool was defined as a 4-byte integer instead of a 1-byte one, presumably to match WinAPI's definition: https://docs.microsoft.com/en-us/windows/win32/winprog/windows-data-types
Nothing should break now that bool is 1-byte, as no protocol code appears to be relying on the size of the data type.
PACK, for example, explicitly stores boolean values as 4-byte integers.
This commit can be seen as a follow-up to 61ccaed4f6.
WgkAdd command - Add a WireGuard key
Help for command "WgkAdd"
Purpose:
Add a WireGuard key
Description:
This command can be used to add a WireGuard key to the allowed key list.
To execute this command, you must have VPN Server administrator privileges.
Usage:
WgkAdd [key] [/HUB:hub] [/USER:user]
Parameters:
key - WireGuard key. Make sure it is the public one!
/HUB - Hub the key will be associated to.
/USER - User the key will be associated to, in the specified hub.
================================================================================
WgkDelete command - Delete a WireGuard key
Help for command "WgkDelete"
Purpose:
Delete a WireGuard key
Description:
This command can be used to delete a WireGuard key from the allowed key list.
To execute this command, you must have VPN Server administrator privileges.
Usage:
WgkDelete [key]
Parameters:
key - WireGuard key.
================================================================================
WgkEnum command - List the WireGuard keys
Help for command "WgkEnum"
Purpose:
List the WireGuard keys
Description:
This command retrieves the WireGuard keys that are allowed to connect to the server, along with the associated Virtual Hub and user.
You can add a key with the WgkAdd command.
You can delete a key with the WgkDelete command.
To execute this command, you must have VPN Server administrator privileges.
Usage:
WgkEnum
Please note that the implementation is not 100% conformant to the protocol whitepaper (https://www.wireguard.com/papers/wireguard.pdf).
More specifically: all peers are expected to send a handshake initiation once the current keypair is about to expire or is expired.
I decided not to do that because our implementation is meant to act as a server only. A true WireGuard peer acts, instead, as both a client and a server.
Once the keypair is expired, we immediately delete the session.
The cookie mechanism can be implemented in future.
As for authentication: unfortunately using the already existing methods is not possible due to the protocol not providing a way to send strings to a peer.
That's because WireGuard doesn't have a concept of "users": it identifies a peer through the public key, which is determined using the source address.
As a solution, this commit adds a special authentication method: once we receive the handshake initiation message and decrypt the peer's public key, we check whether it's in the allowed key list.
If it is, we retrieve the associated Virtual Hub and user; if the hub exists and the user is in it, the authentication is successful.
The allowed key list is stored in the configuration file like this:
declare WireGuardKeyList
{
declare 96oA7iMvjn7oXiG3ghBDPaSUytT75uXceLV+Fx3XMlM=
{
string Hub DEFAULT
string User user
}
}
WireGuard does not provide any configuration messages, meaning that we cannot push the IP address we receive from the DHCP server to the client.
In order to overcome the limitation we don't perform any DHCP operations and instead just extract the source IP address from the first IPv4 packet we receive in the tunnel.
The gateway address and the subnet mask can be set using the new "SetStaticNetwork" command. The values can be retrieved using "OptionsGet".
In future we will add a "allowed source IP addresses" function, similar to what the original WireGuard implementation provides.
================================================================================
SetStaticNetwork command - Set Virtual Hub static IPv4 network parameters
Help for command "SetStaticNetwork"
Purpose:
Set Virtual Hub static IPv4 network parameters
Description:
Set the static IPv4 network parameters for the Virtual Hub. They are used when DHCP is not available (e.g. WireGuard sessions).
You can get the current settings by using the OptionsGet command.
Usage:
SetStaticNetwork [/GATEWAY:gateway] [/SUBNET:subnet]
Parameters:
/GATEWAY - Specify the IP address of the gateway that will be used for internet communication.
/SUBNET - Specify the subnet mask, required to determine the size of the local VPN network.
The WireGuard implementation will have two options that should not have a fixed default value, because they represent two keys (one is preshared, the other is private).
Instead of handling these two options differently in ProtoNewContainer(), this commit adds a new function to PROTO_IMPL: ProtoOptionString().
ProtoOptionString() takes the option's name as argument and returns a heap-allocated string that will be used as value. The function returns NULL when the option doesn't need a randomized value.
2575 // Address
at_least: At condition size < 1U, the value of size must be at least 1.
cannot_single: At condition size < 1U, the value of size cannot be equal to 0.
dead_error_condition: The condition size < 1U cannot be true.
2576 if (size < 1)
2577 {
CID 287533 (#1 of 1): Logically dead code (DEADCODE)dead_error_line: Execution cannot reach this statement: goto LABEL_ERROR;.
2578 goto LABEL_ERROR;
2579 }
CID 355460 (#1 of 1): Dereference before null check (REVERSE_INULL)check_after_deref: Null-checking p suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
737 if (p == NULL)
738 {
739 return false;
740 }
CID 287561 (#1 of 1): Array compared against 0 (NO_EFFECT)array_null: Comparing an array to null is not useful: src == NULL, since the test will always evaluate as true.
Was src formerly declared as a pointer?
3748 if (cedar == NULL || src == NULL || dst == NULL)
3749 {
3750 return false;
3751 }
Since 35200a29ea we build complete installers using CMake, meaning that there's no need for BuildUtil anymore.
MSBuild projects that are not migrated to CMake yet are kept for reference.
This commit also updates BUILD_WINDOWS.md so that it mentions Visual Studio 2019 instead of 2017.
To solve the problem that the escape condition of the loop that tries name resolution in UDP mode was reversed in the keep-alive function of the Internet connection, so the name resolution retry is set to 250 msec interval instead of the normal 60 second interval.
This works for all VPN protocols.
In SessionMain(): for DHCPDISCOVER and DHCPREQUEST frames, write the static IP address (which is retrieved from the user notes) in the SIADDR field of DHCPHEADER.
In VirtualDhcpServer(): for DHCPDISCOVER and DHCPREQUEST frames, read the static IP address from the SIADDR field of DHCPHEADER and assign it to the client.
error: cannot initialize a variable of type 'wchar_t *' with an lvalue of type 'const wchar_t [4]'
wchar_t *protocol_str = (udp ? L"UDP" : L"TCP");
^ ~~~~~~~~~~~~~~~~~~~~~~~
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.
ProtoHandleDatagrams() takes care of deleting a session if marked as halted.
However, the check is performed when a packet for that session is received; that never happens if the remote host doesn't send at least a packet.
This commit fixes the issue by moving the check into the loop that iterates through all sessions.
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!
PROTO_OPTION is a structure that describes an option (who would've guessed?).
It's designed in a way that allows it to occupy as low memory as possible, while providing great flexibility.
The idea is similar to the one implemented in LIST for trivial types, with the difference that PROTO_OPTION doesn't require casting due to the use of union.
The reason why we don't build these two targets is that they're not used.
More specifically: they require proper configuration to work correctly, which is currently missing.
While vpninstall may be worth salvaging, vpnweb is definitely a relict of the past because it relies on ActiveX.
BuildUtil compiles the project as 32 bit and 64 bit, before building the installer package.
64 bit binaries have the "_x64" suffix and are added to the package alongside the 32 bit ones (that have no suffix).
The CMake project compiles the binaries for a single architecture and they have no suffix.
We decided that providing two separate installers is the best solution.
As for the binaries with the "_ia64" suffix: they never existed during the this repository's lifespan.
The MSBuild project built the binary into "src/bin/hamcore", causing it to be added to "hamcore.se2".
As hinted by the name of the file ("vpnsetup_nosign.exe"), it is not signed by BuildUtil, possibly to save time (the setup package is signed).
The CMake project builds the binary in the same directory as the other ones, allowing the setup to install them without the need to build a package.
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).
The SSTP implementation doesn't provide packet identification, because it's not required: the protocol is identified by the HTTP header it sends to the server.
"ClientOption", as the name implies, is only used in a client context.
The issue was introduced in 235bd07e67. Before that, an unrelated check prevented UnixVLanSetState() from being called in a server context.
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.
Originally, StrToPortList() returned NULL when it encountered a number equal to 0 or higher than 65535.
This commit adds a new parameter to the function called "limit_range":
- When its value is true, the function retains the original behavior.
- When its value is false, the function doesn't check whether the number is in the network port number range (1-65535).
The change is required because the command to set the UDP ports will allow to remove all ports by specifying "0" as the port number.
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).
*** CID 358434: Null pointer dereferences (REVERSE_INULL)
/src/Cedar/Proto.c: 451 in ProtoHandleDatagrams()
445 void ProtoHandleDatagrams(UDPLISTENER *listener, LIST *datagrams)
446 {
447 UINT i;
448 HASH_LIST *sessions;
449 PROTO *proto = listener->Param;
450
>>> CID 358434: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "listener" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
451 if (proto == NULL || listener == NULL || datagrams == NULL)
452 {
453 return;
454 }
455
456 sessions = proto->Sessions;
As a side effect, the DH parameter is now applied to the TCP server as well.
Previously, the default value was always used, ignoring the one from the configuration.
When a datagram is received, the matching session is looked up in a hash list; if it's not found, a new session is created.
This method allows to use a single UDP port for multiple protocols, as we do with TCP.
Also, each session has its own dedicated thread, used to process the received datagrams and generate the ones that are then sent through the UDP listener.
In addition to guaranteeing constant performance, separate threads also prevent a single one from blocking all sessions.
- An additional parameter is added to IsPacketForMe(), used to specify the protocol type (currently either TCP or UDP).
- SupportedModes() is dropped because it's now redundant.
- IsOk() and EstablishedSessions() are dropped because error checking should be handled by the implementation.
- ProtoImplDetect() now takes a buffer and its size rather than a SOCK, so that it can be used to detect UDP protocols.
- The OpenVPN toggle check is moved to ProtoImplDetect(), so that we don't have to duplicate it once UDP support is implemented.
