OPNsense Forum
English Forums => Virtual private networks => Topic started by: nzkiwi68 on September 07, 2023, 11:30:06 pm
-
Am I missing something?
VPN > WireGuard > Settings > Endpoint
You can specify a "Shared Secret"
On the remote site, where this Endpoint connects to:
VPN > WireGuard > Settings > Local/b]
I cannot see any way to add the "Shared Secret"
Or am I missing something?
-
As far as I can see it was never added for local (server) side.
Cheers,
Franco
-
Shared secret is configured for the respective endpoint entries in both sides. There is no local shared secret, since it is shared between two peers.
-
But the "other" peer is the local side or is it not? WireGuard seems to misuse the word "peer" to mean "the other end" only, which means if you say between peers one is the peer and one is the local/server/interface or whatever you want to call it.
Cheers,
Franco
-
In general terms a peer is a partner in some communication.
In WireGuard the [Peer] section(s) define one or more remote endpoints. OPNsense names these "Endpoints" in the UI for ... reasons? I would prefer "Peers" to stick with WG terminology.
A shared secret parameter is defined in the peer/endpoint entry for site B at site A, and in the entry for site A at site B. There is no shared secret parameter in the [Interface] section - what OPNsense names "Local".
-
In general terms a peer is a partner in some communication.
I would be more meticulously and show the definition of "peer":
person of the same rank or standing
Apart from devices not being persons that means that a peer-to-peer can be a client-to-client connection or a server-to-server connection but not a server-to-client connection.
But usually with peer you mean a client-to-client connection (as e.g. in peer-to-peer file sharing).
-
In WireGuard there are no dedicated client and server roles. That's why the author settled with peer, probably.
-
Okay, so the preshared key is peer-level (endpoint) only. Nothing missing here then as it can be configured on both sides.
We will try to get a bit more consistency in the naming for 24.1
Cheers,
Franco
-
Okay, so the preshared key is peer-level (endpoint) only. Nothing missing here then as it can be configured on both sides.
Correctamundo! :) Can and - if used at all - must be configured on both sides.
-
The optional PSK is directly used for an additional layer of symmetric encryption, that's why you only need to specify it for the endpoint. The same key is used for en- and decryption.
Cheers
Maurice
-
ok!
Thanks very much Patrick M. Hausen for the explanation.
So... peer side at each end is where you use a PSK, like this:
peer / endpoint for Site A > B
and
peer / endpoint for Site B > A
But not the local "server" settings, because that's not really a server at all, it's actually just a wg interface.
Naming consistency
"Local" should be renamed to "Interface"
"Endpoints" should be renamed to "Peer"
This is in keeping with Wireguard terminology.
Reference: https://www.wireguard.com/#simple-network-interface (https://www.wireguard.com/#simple-network-interface)
-
It always depends. If you already have wireguard running, interface and peer matches best. If you are new and migrate from openvpn, local and endpoint fits better.
-
"Local" should be renamed to "Interface"
"Endpoints" should be renamed to "Peer"
Agreed.
-
Naming consistency
"Local" should be renamed to "Interface"
"Endpoints" should be renamed to "Peer"
Yes.
-
We will not be calling it "interfaces". The candidates were "instances" and "devices" and "instances" is closer to "interfaces" so it's likely going to be that.
I know this seems like a no brainer, but too often "interface" is used for something not "interface" in the GUI so we try to fix that by making sure the terminology in the GUI stays consistent.
Cheers,
Franco
-
Instances is good. Peers for the ... well ... peers?
-
Peers will be peers, yep. I've made a note in the migration ticket: https://github.com/opnsense/core/issues/6827
Cheers,
Franco
-
Thanks, sounds good!
And, I've learnt a little more too.