WireGuard works by adding a network interface (or multiple), like eth0 or wlan0, called wg0 (or wg1, wg2, wg3, etc). This network interface can then be configured normally using ifconfig(8) or ip-address(8), with routes for it added and removed using route(8) or ip-route(8), and so on with all the ordinary networking utilities. The specific WireGuard aspects of the interface are configured using the wg(8) tool. This interface acts as a tunnel interface.
WireGuard associates tunnel IP addresses with public keys and remote endpoints. When the interface sends a packet to a peer, it does the following:
This packet is meant for 192.168.30.8. Which peer is that? Let me look… Okay, it’s for peer ABCDEFGH. (Or if it’s not for any configured peer, drop the packet.)
Encrypt entire IP packet using peer ABCDEFGH’s public key.
What is the remote endpoint of peer ABCDEFGH? Let me look… Okay, the endpoint is UDP port 53133 on host 216.58.211.110.
Send encrypted bytes from step 2 over the Internet to 216.58.211.110:53133 using UDP.
When the interface receives a packet, this happens:
I just got a packet from UDP port 7361 on host 98.139.183.24. Let’s decrypt it!
It decrypted and authenticated properly for peer LMNOPQRS. Okay, let’s remember that peer LMNOPQRS’s most recent Internet endpoint is 98.139.183.24:7361 using UDP.
Once decrypted, the plain-text packet is from 192.168.43.89. Is peer LMNOPQRS allowed to be sending us packets as 192.168.43.89?
If so, accept the packet on the interface. If not, drop it.
.
Yup sounds reasonable. They have described the two purposes/functionalities of “Allowed (ips) Addresses” in both outgoing and incoming traffic and that traffic gets addressed by wireguard parameters once it has reached the wireguard interface (and thus MT firewall rules and routing are important for traffic prior to entering the tunnel and after exiting the tunnel). Not to fussed about the encryption but tis interesting.
When getting started with WireGuard, it can be hard to understand the interaction between the network layers below WireGuard (> the “real” network> , often a physical Ethernet or WiFi network) and the WireGuard VPN (Virtual Private Network). This article will cover which configuration settings are used for which > (“real” network or virtual network> ), and will > trace > how an individual packet flows between the two.
The rest of the story is revealed by reading the contents of the link above.
Wrong! How does "normally, → doesnt apply to MT devices LOL.
No need to assign an IP address to the Wireguard config!
PROOF ---->
Ip address assigned to the Wireguard inteface is
a. NOT a required wireguard parameter
b. Not transferred between devices on the two ends of a tunnel.
Conclusion, the wireguard writers have egos, slightly over enlarged, who think the world revolves around their preconceived notions of wireguard use or more likely,
my dear friend misinterprets the broad language in the text with the intended usage.
In fact, the MT RoS does NOT EVEN HAVE ADDRESS as an option under the wireguard interface settings!!!
+++++++++++++++++++++++++++++++++++++++
Now if one is using a NON MT device, without the power of RoS, like my iphone, yes the iphone is given an IP address ( a faux wireguard IP address ) but nothing more.
This equates to, hate to point it out to mozerd, but merely a subnet address or device IP address with the Mikrotik network AND NOT an IP address for the interface.
No can do LOL.
I am not of the ilk to believe.
I need evidentiary proof and logic why it has to be so.
Besides when is MT documentation every perfect or complete, they often offer samples and its up to the reader to tell his/her own story.
Show me a config between two MT devices that won’t work due to not using an IP address. ( crickets )
There is a difference between normal and what can or can not be done.
Majority defines what’s normal, if you like it or not, if you agree or not.
Using IP addresses for network interfaces is normal.
I asked for some facts, you didnt provide anything substantial to this conversation.
Show me a wireguard setup between two MT devices that cannot be accomplished without an IP address for the WG interface.
Its simply extra and not needed.
Keep making life mOre complicated for new users of MT is your choice not mine.
Rather a benign bug which has no detrimental affect on any config and is no more efficient then without a config.
I am hard pressed to see how they would implement this and why it would be any better. Guess gonna have to wait till the ‘fix’ arrives.
Personally speaking I have never designed a network or addressed a use case that says the customer wants to be able to ping the wireguard interface.
One would get paid ZERO $$ to do that and nobody in my family get their rocks off my pinging addresses of any ilk.
However for an admin (cause it aint for the users) in terms of checking whether part of the config or the config is working there is some merit to the idea of pinging something.
Why you insist its the wireguard interface is your particular FREE choice, but please do not force it on me because I already to that functionality by pinging other available IPs that are available and that are actually current parameters on the wireguard settings. What you are actually saying is that in order to ping the IP address of the wg interface, that IP address has to be included in the Allowed IPs, even though it may have nothing to do with subnets at either end, it could just be an arbitrary IP address!!
If you state no no, it will encompass some existing subnet, BINGO! thats what I use, existing subnets (or IPs).
So in summary, I already can and do use pinging without the wireguard interface IP.
In fact, also used in scripts to ensure the tunnel is up in the case of mynetname coming up after the tunnel upon certain conditions as detailed at para 2 - https://forum.mikrotik.com/viewtopic.php?t=182340
[ (2)MYNETNAME - SPECIAL CONSIDERATION FOR ENDPOINT ]
In response, to your pleas and begging, I will endevour to ensure that my article is balanced and includes a paragraph detailing the differences so that folks can use IP addresses if they so wish to.
I will explain in it in far better terms for new users then the crap write-ups at wireguard or MT, which dont reflect MT RoS or are not sufficient for the new user, respectively. Experienced user dont need to read the article for example. Yes, consider it a capitulation of sorts, but I do recognize I have my own biases and limitations but mainly because I dont want Sob to suffer from PTSD!
On a moving forward note, will ensure I support the setup desired by the user which could include (cough retch, puke) use of IP address.
If you elect, not mandatory, to use an IP address for the local wireguard interface, ensure you encompass ALL the IP addresses and subnets, based on Allowed IPs (inbound flow). In other words, every incoming user needs to be covered by both Peers settings of ‘Allowed IPs’, and local ‘IP address(es)’. What needs to be clearly understood is that one may require MULTIPLE IP Addresses assigned to the Wireguard Interface.
example 1 - Three smart phone users, and they have 192.168.5.10/32, 192.168.5.25/32 and 192.168.5.105/32, its probably best to have allowed IPs set to 192.168.5.0/24
IP address of wg interface=192.168.5.1/24
example 2 - One smart phone user and one remote subnet 192.168.5.10/32 and incoming remote subnet 172.44.4.0/2, allowed IPs 192.168.5.10, 172.44.4./24 and ..
Ip address 192.168.5.1/24 interface=wireguard
Ip address 172.44.4.0/24 interface=wireguard
Additionally one should understand the impact of including IP addresses vice not including them. The router with an existing IP address for the Wireguard interface will automatically create IP routes for traffic back to the tunnel. Thus the users that are coming into the local router and going OUT to the internet or ACROSS to subnets on the local router will have an IP route generated to ensure return traffic goes back through the Wireguard tunnel to the remote site. Therefore the manually inserted IP route, dst-address=[ IP of smartphone OR IP of Subnet ] gwy=Wireguard Interface table=main, will NOT be required.
You are a kind and generous person anav … and I 4 1 applaud your herculin efforts in assisting newbies with MikroTik configurations.
When testing the Performance of any WireGuard tunnel one of the best tools to use is iPerf … to use iPerf and to test the actual WGT the client and server [The Hub and Spoke] must have their Interfaces addressed properly … Networking Disciplines do not make configuration far more complex — in fact those disciplines once learned properly make it far easier … what in fact happens is that PEOPLE automatically introduce complexities by over-thinking because of poor learning disciplines.
WireGuard is extremely easy to configure … it is in fact ridiculously easy to configure … The novice needs to understand the difference between the HUB and the Spoke [server/client – interactions] and once that is understood the rest cannot be more clear. Novices love the GUI … most novices get VERY confused using the CLI and THAT perpetuates the confusion.
FYI, all networks TOOLS have a dependency on proper IP Addressing … WG is no different. MikroTik RouterOS is not currently engineered for the novice and I do not believe that it ever will be … in fact it is specifically created for the specialist’s … yes some of the hardware can be used by novices but if those novices want to exploit the power of RouterOS then proper network disciplines must be learned. Networking is the foundation of RouterOS and all Tik devices.
@mozerd: You can’t win, I already tried. Problem is that @anav is not completely wrong, WG itself doesn’t really care about addresses on its interfaces. It’s not anything special in ROS, you can do the same in Linux and probably in every system that doesn’t force you to use some simplified interface. But there’s no doubt he’s going against the flow, so if he really wants to help people and not confuse them, he should accept this as fact and not try to start a revolution.
What? an anarchist say it isnt so. LOL.
Already done Sob, as you can see I would prefer comments on my draft inclusion to the current article vice stating that I am not a conformist in nature, I follow the science and facts!
So yes I am having an open mind on the subject and want to get it right.
If you stop removing perfectly fine addresses from users’ configs, it will be small victory. And this looks confusing:
I’d understand “remote subnet 172.44.4.0/24” as some remote LAN, and you don’t want local address for that. And don’t overcomplicate it, usually you don’t need more than one address on WG interface. Common use, even combined one with multi-purpose WG interface used for both site to site and road warriors, will usually have only one subnet for the whole interface.
Well good, now we can continue to disagree, well except for the first point, but not a carte blanche okay, but with the caveat that as long as it falls into MY definition of proper usage of IP address )
Now lets get back to disagreeing!!
Fact: There is nothing wrong with multiple IP addresses for the single wireguard interfaces.
Fact: What you are basically proposing is well, golly gee willickers, might as well assign 0.0.0.0/0 to the wireguard interface to capture all possible incoming traffic. A ridonculous proposal!
So either you be consistent and propose a Wireguard interface that is completely separate from any IP or subnet coming into the local device (exiting the tunnel), or follow my suggestion above.
It is not clear what you are stating and you look like you are straddling a fence, and if not careful might perforate your rectum.
@anav, my suggestion to help users with WireGuard configurations is to start by discussing common Topologies like
Point to Point
Hub and Spoke
Point to Site
Site to Site
Then provide samples of each and that would give the user community a wealth of effective methods.
Pro Custodibus does a superb job of doing just that … they do it for the Linux community … If you can take that as an example and bread-down each Topology in MikroTik Speak PEOPLE here would love you to death. MikroTik should be taking this approach but sadly they are not === so if you take on that Challenge that would be ABSOLUTLY GREAT
I will endevour to ensure that my article is balanced and includes a paragraph detailing the differences so that folks can use IP addresses if they so wish to.