WireGuard: Interface - Unofficial WireGuard Documentation

RouterOS Beginner Basics
1

Following is EXCELLENT guidance that MikroTik users should follow. These guidelines apply to ALL platforms that want to exploit WireGuard effectively. IMO, Unfortunately MikroTik have not implemented these guidelines strictly … perhaps over time they will,

I am only providing a small subset of this guidance
Note Specifically the following:
Table
Optionally defines which routing table to use for the WireGuard routes, not necessary to configure for most setups.
There are two special values: ‘off’ disables the creation of routes altogether, and ‘auto’ (the default) adds routes to the default table and enables special handling of default routes.

[Interface]
Defines the VPN settings for the local node.

Examples
Node is a client that only routes traffic for itself and only exposes one IP

[Interface]

Name = phone.example-vpn.dev

Address = 192.0.2.5/32
PrivateKey =

Node is a public bounce server that can relay traffic to other peers and exposes route for entire VPN subnet

[Interface]

Name = public-server1.example-vpn.tld

Address = 192.0.2.1/24
ListenPort = 51820
PrivateKey =
DNS = 1.1.1.1

Name

This is just a standard comment in INI syntax used to help keep track of which config section belongs to which node, it’s completely ignored by WireGuard and has no effect on VPN behavior.

Address
Defines what address range the local node should route traffic for. Depending on whether the node is a simple client joining the VPN subnet, or a bounce server that’s relaying traffic between multiple clients, this can be set to a single IP of the node itself (specified with CIDR notation), e.g. 192.0.2.3/32), or a range of IPv4/IPv6 subnets that the node can route traffic for.

Examples

Node is a client that only routes traffic for itself
Address = 192.0.2.3/32

Node is a public bounce server that can relay traffic to other peers
When the node is acting as the public bounce server, it should set this to be the entire subnet that it can route traffic, not just a single IP for itself.

Address = 192.0.2.1/24

You can also specify multiple subnets or IPv6 subnets like so:
Address = 192.0.2.1/24,2001:DB8::/64
ListenPort
When the node is acting as a public bounce server, it should hardcode a port to listen for incoming VPN connections from the public internet. Clients not acting as relays should not set this value.

Examples

Using default WireGuard port
ListenPort = 51820
Using custom WireGuard port
ListenPort = 7000
PrivateKey
This is the private key for the local node, never shared with other servers. All nodes must have a private key set, regardless of whether they are public bounce servers relaying traffic, or simple clients joining the VPN.

This key can be generated with wg genkey > example.key

Examples

PrivateKey = somePrivateKeyAbcdAbcdAbcdAbcd=

DNS
The DNS server(s) to announce to VPN clients via DHCP, most clients will use this server for DNS requests over the VPN, but clients can also override this value locally on their nodes

Examples

The value can be left unconfigured to use system default DNS servers
A single DNS server can be provided
DNS = 1.1.1.1
or multiple DNS servers can be provided
DNS = 1.1.1.1,8.8.8.8
Table
Optionally defines which routing table to use for the WireGuard routes, not necessary to configure for most setups.

There are two special values: ‘off’ disables the creation of routes altogether, and ‘auto’ (the default) adds routes to the default table and enables special handling of default routes.

https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8

Examples

Table = 1234
MTU
Optionally defines the maximum transmission unit (MTU, aka packet/frame size) to use when connecting to the peer, not necessary to configure for most setups.

The MTU is automatically determined from the endpoint addresses or the system default route, which is usually a sane choice.

https://git.zx2c4.com/WireGuard/about/src/tools/man/wg-quick.8

Examples

MTU = 1500

2

…

3

Actually Yes there is @404 … Name =wg0 or whatever name one wants to give THE INTERFACE using the GUI or CLI,

But very unfortunately you are missing the boat completely … and its my opinion that MikroTik are not paying attention to your misdirection. Correcting Your misconceptions would take far too much of my time.

4

…

5

The way it’s done in MikroTik is the exact same way it’s done in Linux.

First create the WG interface then name it followed by assigning a IP address to that interface. You just refuse to accept that because you found a stupid bug that Tik has yet to fix.

6

…

7

@404
Today I set up a WireGuard Tunnel for a Client … A MikroTik hEX as the Router running RoS v7,1.3 … The Client wanted to remotely access his office Windows 11 Desktop and the Office NAS plus the ability to print to his Canon Network Printer using his Windows 10 Laptop and His iPhone13 … in all my client needed access to 2 subnets to achieve his objectives …

(a) I did not assign a IP address to his WG Interface … the WG Tunnel did activate successfully …BUT he could not access any of his objectives ..
(b) I then proceeded to add a IP address to his WG Interface … the WG Tunnel did activate successfully . … now he had access to all of his his objectives.

This is the 1st time that I have tried the no IP for the WG Interface in a Client situation … (a) did not work … (b) worked as expected …

The IP I used for the hEX WG Interface Name=wg_tenfour is 172.XXX.xxx.1/32
The Windows 11 Desktop is situated in VLAN100 having a IP address of 192.168.100.100/32
The Cannon network Printer is located on VLAN200 having a IP address of 192.168.200.44/32
The NAS is located on VLAN200 having an IP address of 192.168.200.10/32

So I am mystified as to WHY that under (a) the WG Tunnel did activate and establish successfully but no access to Client objectives … perhaps because I did not build any routes
Under (b) everything worked as I had expected it to work relying strictly on allowed IPs and DAC. …

8

I think it was mkx who once said “it’s usually routing where the problem is to be found”.

9

@holvoetn
Perhaps but with (b) I did not have any issues — assigning a IP address to the WG Interface and like MAGIC everything worked like it should. :slight_smile:

10

Because a default route towards the WG-interface gets created one you create the IP addresses for the endpoints ?

11

@holvoetn
My principle issue is with (a) … since NO IP address was assigned to the WG Interface the WG Tunnel should not have be activated but it was and IMO this is wrong.
So I will contact Jason Donenfeld and ask why is this behavior allowed or is this a WG Bug or something else.

12

It has already been explained by mkx that the usage of an IP address on the endpoints is NOT needed per se.
It can work perfectly without (besides, our burning Llama also has proven that already multiple times)
But you do need to take care of all required routes yourself then.

To keep things consistent with all other interfaces and to keep things uniform it is however advised to use them all the time.
I also use them. I need addresses on each endpoint of each interface. I am wired that way :laughing:

13

@mozerd: care to show exact WG configuration you did for case (b)? Both /interface wireguard and /ip (if any)?

As already mentioned: setting addresses property in peer section doesn’t automatically add anything to address or routing on MT. If you configure address on (any) interface and use network mask equal or shorter than 30, then MT will add route to connected network automatically. If the WG peer performs proxy ARP (or some other trick), then it’s possible to access full subnet through WG. Without setting IP address to WG interface one has to set static routes manually, using interface name as gateway.

@holvoetn: I don’t use IP addresses on every damn interface. It’s just like naming each of your ears differently … instead of using your unique name. Ears don’t need having names in order to hear when you’re called, do they? :laughing:

14

But I still consider myself a beginner learning every day :smiley:

PS true story: I do label my ears differently. I have a loss of 50% at the right. After 26 years my wife still makes the occassional mistake to whisper on my right side and each time I need to say “the other ear please” :laughing:

15

Why souldn’t WG tunnel be activated if it’s outer end (interface in OS) doesn’t have any IP address configured? Ethernet interfaces are just fine and can pass ethernet frames even if they don’t have IP address configured. Iguess one could use such ethernet interface for winbox MAC connection (if MT device doesn’t have IP address, why should computer have one?).

Plus: I’ve never seen any reference to the fact one can have multiple peers configured on single WG interface. And yet WG interface can have less IP addresses than peers (e.g. one IP address and two peers). So why sould “none IP addresses and one peer” be any different.

16

I do not reveal client configs unless I get permission to do so … He is currently in Paris in a Hotel , his hEX is in Denver Colorado and I am in Ottawa … I have no desire to bother him.

17

“left” and “right” are not names, they are attributes. Names would be like “Wilma” and “Louise” … you don’t do that, right?

You’re right that one has to be precise … say your wife knows that your left ear is the better one … but you still can’t tell to her “dear, use the right one please” because the right one is not the right one :lol

18

That’s fine (and the right thing when it comes to customers).

And I’ll assume you didn’t do the job properly. Because I know it can be done differently. If you care to pursue the thing further, you can always do a lab setup and then you will be able to disclose config for peer review. If you don’t care to do it, then nobody else will either.

19

…

20

…