WireGuard: Interface - Unofficial WireGuard Documentation

[holvoetn]

Tss tss tss, proving again your inability to analyze ?

50% loss is not nothing.
Normal volumes, I can still understand conversations via right.
Whisper is just… background noise. Nothing comprehensible.

[mozerd]

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.

Wow, a challenge from mkx … OK I will take you up on this challenge …

I created a small test between my CCR1009 and my iphone accessing my NAS ,

In my Test I removed the IP Address assigned to my WG Interface on my CCR1009 running RoS v 7.2rc4 and then from my iPhone using my Cellular Network [wifi shut off] I tried to access my NAS … my iPhone FAILED to reach my NAS … next I added back the IP Address to my WG Interface and now my iPhone succeeded in reaching my NAS.

Iphone WG config

[Interface]
PrivateKey = my private key=
Address = 172.168.50.51/32

[Peer]
PublicKey = my public key
AllowedIPs = 192.168.100.15/32, 192.168.100.1/32
Endpoint = xzxzxz.myddns.zzzzz:43231

---

CCR1009 WG Config

/interface wireguard add listen-port=43231 mtu=1420 name=wireguard_ccr
/interface wireguard peers add allowed-address=172.168.50.51/32 comment=iPhone interface=wireguard_ccr public-key="my public key"

/ip address add address=172.168.50.1/24 interface=wireguard_ccr network=172.168.50.0
Note: Address removed for 1st run then added back in on second run

/ip firewall address-list add address=192.168.100.15 list=wireguard_ad
/ip firewall address-list add address=192.168.100.1 list=wireguard_ad

/ip firewall filter add action=accept chain=input comment="INPUT WireGuard" dst-port=43231 log=yes log-prefix=mywg protocol=udp
/ip firewall filter add action=accept chain=forward comment="FORWARD WireGuard_CCR" dst-address-list=wireguard_ad log-prefix=mywgvpn src-address-list=wg_client

---

Routing Table 1st run

Flags: D - DYNAMIC; I, A - ACTIVE; c, d, y - COPY; H - HW-OFFLOADED
Columns: DST-ADDRESS, GATEWAY, DISTANCE
     DST-ADDRESS         GATEWAY          DISTANCE
DAd  0.0.0.0/0           xxx.xxx.110.1           1
DAc  172.168.100.100/32  ether1                  0
DAc  xxx.xxx.110.0/23    ether2                  0
DAc  192.168.10.0/24     vlan10                  0
DAc  192.168.20.0/24     vlan20                  0
DAc  192.168.30.0/24     vlan30                  0
DAc  192.168.40.0/24     vlan40                  0
DAc  192.168.50.0/24     vlan50                  0
DIcH 192.168.88.0/24     combo1                  0
DAc  192.168.100.0/24    vlan100                 0

---

Routing Table 2nd run

Flags: D - DYNAMIC; I, A - ACTIVE; c, d, y - COPY; H - HW-OFFLOADED
Columns: DST-ADDRESS, GATEWAY, DISTANCE
     DST-ADDRESS         GATEWAY          DISTANCE
DAd  0.0.0.0/0           xxx.xxx.110.1           1
DAc  172.168.50.0/24     wireguard_ccr           0
DAc  172.168.100.100/32  ether1                  0
DAc  xxx.xxx.110.0/23    ether2                  0
DAc  192.168.10.0/24     vlan10                  0
DAc  192.168.20.0/24     vlan20                  0
DAc  192.168.30.0/24     vlan30                  0
DAc  192.168.40.0/24     vlan40                  0
DAc  192.168.50.0/24     vlan50                  0
DIcH 192.168.88.0/24     combo1                  0
DAc  192.168.100.0/24    vlan100                 0

---

So a EPIC Failure when the WG Interface has no IP Address … Very easy to reproduce

[EDIT] removed erroneous entry in Allowed IPs in CCR1009 config … much thanks to the keen eye of @404Networks … please note that the error had in no way impacted the result of the proof of concept …

[404Network]

…

[holvoetn]

I can choose when to say I didn’t hear her.
A true luxury, I do know that.

[mkx]

@mozerd … when preparing CCR for first run and you remove IP address from wireguard_ccr interface, do add route:

/interface route
add address=172.168.50.51/32 gateway=wireguard_ccr

And I propose run #3: change peer config line to

/interface wireguard peers add allowed-address=172.168.50.51/32 comment=iPhone interface=wireguard_ccr public-key="my public key"

allowed-address property is only about IP addresses on the remote side of WG tunnel … packets ingressing WG interface with dst-address corresponding this setting get pushed into tunnel and packets exiting tunnel with src-address corresponding this setting pass through interface into router. The rest of filtering (regarding local side of tunnel) should be done by firewall.

[404Network]

…

[Sob]

C. Use the IP addresses as a mechanism to create Dynamic Routes from the Local Node for:
(this is most common as it MIMICS existing linux/android apps that AUTOMATICALLY CREATE ROUTES from allowed IPs.)

i. Local originating traffic entering the tunnel heading outbound
ii Remote returning traffic (coming from local servers or the local WANIP for example) entering the tunnel outbound.

As you may have surmized, the traffic identified in i and ii, contain BOTH the destination IPs of the local users and the source IPs of the remote users.
Hence the IP addresses are used to cover the ALLOWED IPs on the local node. and this is exactly what many wireguard apps do!!

I told you it’s completely wrong. Several times. I explained why. Several times. I asked you nicely to stop with this nonsense. I even used “please”. So help me here. What should I threaten you with? Or what else will do the trick?

You’re mimicking nothing. You don’t know what you’re doing. At least try it. If you have e.g. this config:

[Interface]
PrivateKey = <key>
Address = 192.168.44.30/24

[Peer]
PublicKey = <key>
AllowedIPs = 192.168.44.0/24,192.168.45.0/24,192.168.46.0/24
Endpoint = my.server.tls:12345

Then Linux client does this:

# wg-quick up wgtest
[#] ip link add wgtest type wireguard
[#] wg setconf wgtest /dev/fd/63
[#] ip -4 address add 192.168.44.30/24 dev wgtest
[#] ip link set mtu 1420 up dev wgtest
[#] ip -4 route add 192.168.46.0/24 dev wgtest
[#] ip -4 route add 192.168.45.0/24 dev wgtest

Do you see it assigning random 192.168.45.x/24 and 192.168.46.x/24 addresses anywhere? You don’t. Why might that be, you ask? Because it would be nonsense. So once more, get a grip and just do what wise Linux (and other) people do.

[404Network]

…

[mozerd]

@mozerd … when preparing CCR for first run and you remove IP address from wireguard_ccr interface, do add route:

/interface route
add address=172.168.50.51/32 gateway=wireguard_ccr

@mkx …. You missed the whole point of my proof of concept . And that was that by omitting the wg interface IP address my peer the IPhone failed to reach my NAS …. when the wg interface is assigned the IP Address my peer the iPhone succeeded in reaching the NAS AND no routes has to be added manually. …..

Yes, by adding the route manually the iPhone can reach the NAS when no IP address is assigned to the wg interface but WHY do that when it’s NOT necessary …. Plus I disagree with your assertion that interfaces do not necessarily require an address assignment … in my experience they do.

IMO MikroTik have to better explain how exactly WireGuard was integrated into RoS because WireGuard does in many instances automatically add routes but they cannot be seen in the Tik Routing Table … so where are they? How did my iPhone find the NAS when the wg interfaces was assigned the IP. WireGuard under Linux does automatically generate routes based on the allowed IPs … in my proof of concept that is exactly what happened on my Tiks.

[mkx]

WireGuard under Linux does automatically generate routes based on the allowed IPs … in my proof of concept that is exactly what happened on my Tiks.

No it’s not what happened on 'tik. If your WG tunnel connected more than single device to some LAN, then adding IP address to WG interface on LAN side would not be enough. Adding some static routes would.

And besides, WG is obviously flexible enough to be implemented in slightly different ways but can still interoperate just nicely. And MT way is not the same as linux way. No amount of you posting generic documentation will make MT re-implement it the way you think it should be done. Face it and get over it. And don’t spread misleading information because your posts are not about how WG should be configured on MT.

[404Network]

…

[mozerd]

Your proof of concept was bogus to begin with.

Thank you @404 … your expertise ….. I will leave that to your imagination ….. however, I will live with my way of doing things because they work and work well … extremely well …. Remarkably well ….

[Sob]

I am not necessarily recommending using IP address for the purpose of dynamic routes, but IT CAN BE DONE!!!

And you can also use firewall to lock yourself out. IT CAN BE DONE!!! But is it good example of how flexible RouterOS is? In a way, maybe. But it’s also something you should avoid. As should be your crazy abuse of addresses to get routes to remote subnets.

IMO MikroTik have to better explain how exactly WireGuard was integrated into RoS because WireGuard does in many instances automatically add routes but they cannot be seen in the Tik Routing Table … so where are they?

No, WG in RouterOS doesn’t add any hidden routes.

And MT way is not the same as linux way.

It pretty much is. Not as the high level wg-quick, but simple manual config with interfaces, addresses and routes, there’s no difference bettween Linux and RouterOS WG.

[404Network]

…

[404Network]

I am not necessarily recommending using IP address for the purpose of dynamic routes, but IT CAN BE DONE!!!

And you can also use firewall to lock yourself out. IT CAN BE DONE!!! But is it good example of how flexible RouterOS is? In a way, maybe. But it’s also something you should avoid. As should be your crazy abuse of addresses to get routes to remote subnets.

IMO MikroTik have to better explain how exactly WireGuard was integrated into RoS because WireGuard does in many instances automatically add routes but they cannot be seen in the Tik Routing Table … so where are they?

No, WG in RouterOS doesn’t add any hidden routes.

And MT way is not the same as linux way.

It pretty much is. Not as the high level wg-quick, but simple manual config with interfaces, addresses and routes, there’s no difference bettween Linux and RouterOS WG.

…

Sob, your like an itch I like to scratch LOL, or in other words not concerned with how you do it linux ( your sex life is none of my business!).
We are in a heated agreement, yes the basic linux way looks like the way MT does it… where one defines shit properly IF required.

[Znevna]

@mozerd:

[…]
Examples
[…]
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
[…]

Please provide a screenshot of RouterOS using wg-quick or where this

Table

parameter can be set.
Thank you!

[404Network]

…

[Znevna]

I’m just curios how @mozerd uses it in RouterOS, he wrote about it in the first post.

[mkx]

And MT way is not the same as linux way.

It pretty much is.

We can agree that it’s pretty similar. But it’s not the same.
This thread (along with a few others) became all about nitpicking … hence MT and linux are not the same.

[Znevna]

Short version of this topic:
RouterOS doesn’t use wg-quick and @mozerd never configured a wg tunnel on a linux machine without wg-quick (in order to do everything manually, just like you have to do it in RouterOS; PS: way easier to do it in RouterOS thanks to WinBox/WebFig).
Also @mozerd seems to not understand how adding an IP to an interface affects routing, in any operating system.
But let’s not pick on @mozerd, he has a business to run, and the more he posts, the more he spreads his links around.

Experience has no substitute
Inexperience carries significant cost and risk.