GenX25519 command - Create new X25519 keypair
Help for command "GenX25519"
Purpose:
Create new X25519 keypair
Description:
Use this to create a new X25519 keypair, which can be used for WireGuard.
Both the private and public key will be shown.
The public key can be shared and is used to identify a peer.
Also, it can always be retrieved from the private key using the GetPublicX25519 command.
The private key should be kept in a secure place and never be shared.
It cannot be recovered once lost.
Usage:
GenX25519
==========================================================================================
GetPublicX25519 command - Retrieve public X25519 key from a private one
Help for command "GetPublicX25519"
Purpose:
Retrieve public X25519 key from a private one
Description:
Use this if you have a private X25519 key and want to get its corresponding public key.
Usage:
GetPublicX25519 [private]
Parameters:
private - The private X25519 key you want to get the corresponding public key of.
Turns out %S refers to ANSI/UTF-8 and %s to UTF-16.
This commit fixes a buffer overflow reported by AddressSanitizer and removes an unnecessary conversion to UTF-16.
The open-source project began with version 1.00, build 9022.
With the exception of an informative message fallback for builds older than 9428 (2014), all checks were for closed-source builds.
Also, the default timeout value is set to 30000 (milliseconds) instead of 10000.
The change is made because it was reported that some routers failed to connect in time.
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.
"2050 LA_DEL_CRL" - this entry appear in logfile when you delete cert from Certificate Revocation List. Thats why need to change it.
"2051 LA_SET_CRL" - this entry must appear in logfile when you edit cert in Certificate Revocation List, but it doesn't happen (perhaps it's a bug)
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.
