WireGuard: allowed IPs - Unofficial WireGuard Documentation

mozerd · Thu Mar 10, 2022 12:08 am

AllowedIPs

This defines the IP ranges for which a peer will route traffic. On simple clients, this is usually a single address (the VPN address of the simple client itself). For bounce servers this will be a range of the IPs or subnets that the relay server is capable of routing traffic for. Multiple IPs and subnets may be specified using comma-separated IPv4 or IPv6 CIDR notation (from a single /32 or /128 address, all the way up to 0.0.0.0/0 and ::/0 to indicate a default route to send all internet and VPN traffic through that peer). This option may be specified multiple times.

When deciding how to route a packet, the system chooses the most specific route first, and falls back to broader routes. So for a packet destined to 192.0.2.3, the system would first look for a peer advertising 192.0.2.3/32 specifically, and would fall back to a peer advertising 192.0.2.1/24 or a larger range like 0.0.0.0/0 as a last resort.

Examples

peer is a simple client that only accepts traffic to/from itself
AllowedIPs = 192.0.2.3/32

peer is a relay server that can bounce VPN traffic to all other peers
AllowedIPs = 192.0.2.1/24

peer is a relay server that bounces all internet & VPN traffic (like a proxy), including IPv6
AllowedIPs = 0.0.0.0/0,::/0

peer is a relay server that routes to itself and only one other peer
AllowedIPs = 192.0.2.3/32,192.0.2.4/32

peer is a relay server that routes to itself and all nodes on its local LAN
AllowedIPs = 192.0.2.3/32,192.168.1.1/24

404Network · Thu Mar 10, 2022 12:56 am

.....................

mkx · Thu Mar 10, 2022 10:28 am

I will state that the linux and android applications that automatically generate local device IP routes, based on the Allowed IPs within the peer, is a SMART / EFFICIENT and clearly necessary step. It is not so automated in the MT devices. Should it be? Maybe?? However, the limitation is that it may not work well for internet bound traffic when some not all users on a local device are to use the tunnel for internet traffic

I guess it all boils down to choice between being smart/automatic and flexibility. Since ROS is well known for its flexibility (which indeed overwhelms many less savvy admins) in most of configuration segments, I would expect wireguard configuration to follow the flexibility. But it absolutely has to be accompanied with good documentation.

And copying parts of documentation from generic linux documentation into several forum topics without regard to differences between implementations is not the right step IMO. As much as the effort by @mozerd is well intended, it doesn't really bring any benefit which posting link to original docs would do ... however, the additions by @404Network are valuable for those who might be familiar with the generic documentation and wonder why things behave in slightly different way than described.

Znevna · Thu Mar 10, 2022 11:13 pm

@mozerd do you even wireguard on mikrotik?

404Network · Fri Mar 11, 2022 1:34 pm

....................

mozerd · Fri Mar 11, 2022 2:33 pm

@mozerd do you even wireguard on mikrotik?
Clearly he has used wireguard for MT devices, but seemingly only in a very narrow, what I would call restrictive way. Just want to ensure that he realizes he wont go to Mikrotik jail ( I mean who wants to end up in Latvia with a bunch of bearded Latvian coders) if he opens his mind to other possibilities.

@404 ... correct in that my philosophy for networking specifically regardless of type is to be as restrictive as possible and only build to end user requirements ... it's my experience that many people in the IT field neglect networking disciplines where a minimalistic approach is the appropriate way -- they only get caught when the auditor brings them to task based on issues exposed.

Latvia is very fortunate to have joined NATO but I an completely disgusted in how NATO has handled the Ukrainian/Russia issue .... NATO has abandoned any sense of humanity in not coming aggressively to the aid of Ukraine allowing the Russian Bully to inflict so much pain and suffering without any justification of whatsoever nature. How can moral humans just watch the carnage and just respond with verbal diarrheas' .

Fri Mar 11, 2022 2:53 pm

For what purpose ?
To provide a reason to some fool to push the red button ? Because that's what WILL happen if he gets cornered too much.
And then what ? Bye bye Earth ? To the very least it will be bye bye to most of Europe.
I am not saying what happens now has to happen and we simply need to watch but we need to be very careful about the consequences.

This non-sense needs to stop ASAP. 500% agree.
But more aggression is not always the answer to aggression, certainly not when the bully has some nasty shit in his hands capable of destroying all we know and humanity with it.
Isolation, denial of goods and services, ... will also bring him to the knees but it takes longer.
And then his own people will judge (hopefully) but be aware, they have been informed in such a unilateral way for so long already, they mostly don't know what's happening nor why. For all they know it's the West turning completely against them. From that point of view I can even understand normal people are angry towards the West. They don't know otherwise.

Can we stay at least in broad terms on topic please ?

mozerd · Fri Mar 11, 2022 3:22 pm

.......
To provide a reason to some fool to push the red button ? Because that's what WILL happen if he gets cornered too much.
.......
This non-sense needs to stop ASAP. 500% agree.

Which are you more afraid more off .... Nuclear, Chemical and/or Biological Weapons'? I am terrified by all of them but that is the reality we face today and its not going away.
Economic Sanctions will not work especially against Russia and China co-operation ... they will support each other. Putin/Assad were responsible for 1 Million Syrians dying from chemical weapons' ... perhaps you and many other do not remember that fact. The only way to tackle a Bully like Putin is with extreme force. Putin will not stop after Ukraine he will reconstitute the USSR unless he is stopped COLD.

404Network · Fri Mar 11, 2022 3:26 pm

..........................

mozerd · Sat Mar 12, 2022 2:18 pm

I have contacted MikroTik and requested information as to how the Following WireGuard fundamental Principle is supported in RoS ....
When I receive a response I will post it here assuming that they will permit me doing that.

Extracted from the WireGuard Whitepaper

The fundamental principle of a secure VPN is an association between peers and the IP addresses each is allowed
to use as source IPs.

In WireGuard, peers are identified strictly by their public key, a 32-byte Curve25519 point.
This means that there is a simple association mapping between public keys and a set of allowed IP addresses.

Examine the following cryptokey routing table:

wgConfiguration 1a.GIF

The interface itself has a private key and a UDP port on which it listens (more on that later), followed by a
list of peers. Each peer is identified by its public key. Each then has a list of allowed source IPs.

When an outgoing packet is being transmitted on a WireGuard interface, wg0, this table is consulted to
determine which public key to use for encryption.

For example, a packet with a destination IP of 10.192.122.4
will be encrypted using the secure session derived from the public key TrMv...WXX0. Conversely, when wg0
receives an encrypted packet, after decrypting and authenticating it, it will only accept it if its source IP resolves
in the table to the public key used in the secure session for decrypting it.

For example, if a packet is decrypted from xTIB...qp8D, it will only be allowed if the decrypted packet has a source IP of 10.192.122.3 or in the range
of 10.192.124.0 to 10.192.124.255; otherwise it is dropped.

With this very simple principle, administrators can rely on simple firewall rules.

For example, an incoming packet on interface wg0 with a source IP of 10.10.10.230 may be considered as authentically from the peer with
a public key of gN65...Bz6E. More generally, any packets arriving on a WireGuard interface will have a reliably
authentic source IP (in addition, of course, to guaranteed perfect forward secrecy of the transport).

Do note that this is only possible because WireGuard is strictly layer 3 based. Unlike some common VPN protocols, like
L2TP/IPsec, using authenticated identification of peers at a layer 3 level enforces a much cleaner network design.

In the case of a WireGuard peer who wishes to route all traffic through another WireGuard peer, the
cryptokey routing table could be configured more simply as:

wgConfiguration 2a.GIF

Here, the peer authorizes HIgo...f8yk to put packets onto wg0 with any source IP, and all packets that are
outgoing on wg0 will be encrypted using the secure session associated with that public key and sent to that
peer’s endpoint.

Larsa · Sat Mar 12, 2022 4:35 pm

@mozerd, something happened to the linked pic:

"... In the case of a WireGuard peer who wishes to route all traffic through another WireGuard peer, the
cryptokey routing table could be configured more simply as:
The attachment wgConfiguration 2a.GIF is no longer available

mozerd · Sat Mar 12, 2022 5:30 pm

@mozerd, something happened to the linked pic:

@Larsa .... thank you ... your message forced me to use my brain with a guessed fix noted below. ....

Yes I saw that ... the pic is there but its not placed properly by the forum phpBB software -- must be a bug

... I tried fixing it but my fix does not work ..... there is only 2 pics ... and both are shown ...1a and 2a.

OK I figured out the error and fixed it by changing the numbering scheme of pics ...

Sob · Sat Mar 12, 2022 5:47 pm

@mozerd: And what exactly is your question? Peers are identified by they public keys, it's what the whole WG is built on, it's same in RouterOS as everywhere else.

anav · Sat Mar 12, 2022 5:51 pm

..................

mozerd · Sat Mar 12, 2022 6:12 pm

@ Sob
My question to MikroTik

how does RouterOS provide support for “cryptokey routing” and how to display the cryptokey routing table in RoS?

The only display of keys and associated source IPs etc I see in Winbox and CLI is that shown is under interface ... no Routing Table for WG .... however I do understand that the Interface/wireguard display can be considered as a Table of sorts but not in the conventional way like .... /ip/routing/wireguard

In all my wg implementations under Tik [less than 12} I have not had to manually set routes .... allowed IPs did the work very nicely .... I see that you plus others ... in general terms .., insist on manually setting routes and Yes that under certain circumstance that may be necessary however I have not had those circumstances yet. I have quite a few EdgeMax WG implementations and all work flawlessly without routes manually set. My implementations are mostly end-user driven accessing subnets etc based on site to site and star topologies ....

Special Note: All my Wirguard Interfaces have IP addresses assigned and like my simple proof of concept no routers had to be added PERIOD @404

Sob · Sat Mar 12, 2022 6:22 pm

@anav: Yes, roaming works.

@mozerd: No, it wasn't allowed IPs that added correct routing for you. Allowed IPs only say what the interface supports for each peer, but not what's actually used. Routing uses regular IP->Routes. If you didn't add any route manually, it's because you added IP address with mask covering the subnet you needed to access, and that created dynamic route. Manual routes are needed for other subnets.

mozerd · Sat Mar 12, 2022 6:30 pm

@Sob
What does WireGuard AllowedIPs actually do?
Well I disagree with you because The keyword allowed-ips is a list of addresses that will get routed to the peer. That is the WireGuard way

Sob · Sat Mar 12, 2022 6:39 pm

Don't confuse WG as low level protocol with wg-quick and other high level tools for configuring WG. What you say is only true for the latter.

And about routes, for example:

1) If you have RouterOS as WG server (hate it as much as you want, but you know what I mean), it has 192.168.99.1/24 on its WG interface and clients each get one 192.168.99.X, you don't need to add any route, because IP address creates dynamic route to this whole subnet.

2) RouterOS as client can have e.g. 192.168.99.20/24 and it will also create route to this whole VPN subnet (so to server and all other clients, and it's up to server to allow communication between them or not). But if this client needs to access also server's LAN 192.168.88.0/24, it will need route to that.

That's what sane people do. Insane ones will:

1) (basic) Not assign 192.168.99.1/24 to WG interface, and instead add route to 192.168.99.0/24 pointing to WG interface. Zero improvement, but feels cool. (*)

2) (advanced) Assign random 192.168.88.X/24 to client's WG interface. Completely wrong, but definitely original. You can't beat that feeling. (*)

(*) Resulting feelings may not be accurate and are not guaranteed. Certain unknown level of insanity may be required. Keep away from children.

mozerd · Sat Mar 12, 2022 6:45 pm

And about routes, for example:

That's what sane people do. Insane ones will:

1) (basic) Not assign 192.168.99.1/24 to WG interface, and instead add route to 192.168.99.0/24 pointing to WG interface. Zero improvement, but feels cool. (*)

2) (advanced) Assign random 192.168.88.X/24 to client's WG interface. Completely wrong, but definitely original. You can't beat that feeling. (*)

(*) Resulting feelings may not be accurate and are not guaranteed. Certain unknown level of insanity may be required. Keep away from children.

OK @Sob with the above I CAN Agree

Larsa · Sat Mar 12, 2022 6:48 pm

I have contacted MikroTik and requested information as to how the Following WireGuard fundamental Principle is supported in RoS. When I receive a response I will post it here assuming that they will permit me doing that.

I'm pretty sure the devs are using the standard linux kernel wg-driver as there are no practical reasons why they should tamper with the core implementation, ie ros contains the full wg stack. Apart from that, the main objective is most likely focusing on the parameter settings (ioctl's) and the tool interface need by Ros.

So anyone interested how the linux implementation of wg is working can have a peek at the source code using the following links:

https://www.wireguard.com/repositories/
https://github.com/torvalds/linux/tree/ ... /wireguard
https://github.com/WireGuard/wireguard-linux

mozerd · Sat Mar 12, 2022 6:51 pm

@Larsa ... I ABSOLUTLY agree with you 100%

anav · Sat Mar 12, 2022 7:08 pm

.....................

anav · Sat Mar 12, 2022 7:12 pm

........................

Larsa · Sat Mar 12, 2022 7:16 pm

Forgot to mention that there are plenty of real world scenarios that can be found in stackexchange, serverfault etc, where wg is used in combination with netfilter/nftables which might give some guidance on how Ros is organising things behind the scenes.

Try google for example "linux wireguard lan-to-lan routing using nat" or "linux wireguard lan-to-lan multiple networks" ...

mozerd · Sat Mar 12, 2022 7:20 pm

I hope you can see now where your thinking went off the rails..................

Goodness Gracious Great Balls of Fire .... @anav -- The configuration Guru is back and kicking ....

Sob · Sat Mar 12, 2022 8:32 pm

Where using IP addresses COULD be used to MIMIC that same outcome, but since it makes Sob vomit, not recommended, if you are in his close proximity

Just to make sure that you understand, I'm not against doing things differently, pushing limits, even some abuse. It can be fun, and if it's for good cause and has some clear benefits, why not, I'm all for it. I will be the first one to commend you, if you come up with such thing. The more twisted (but useful!), the better. Something like @sindy's magic loop, it's horrible and makes me sick every time I see it, but at the same time it's beautiful. Problem with this invention of yours is that it's nothing like that. It doesn't do anything not otherwise possible, doesn't make anything easier to do or understand (quite the opposite), nothing. I feel bad for every beginner who will try to use it, because it will bring only confusion with no benefits.

Znevna · Sat Mar 12, 2022 8:49 pm

So @mozerd here makes some copy-pasta from that github link which mostly covers stuff used by wg-quick which does not exist in RouterOS, and some config files which again do not exist in RouterOS, facts thay only confuses people expecting RouterOS stuff even more (this is the MikroTik forum, still), gives no credit to the guy he stole this from and has nothing personal to say about it
And has some serious issues understanding basic networking.
What am I missing? What is the value in these topics opened recently?

anav · Sat Mar 12, 2022 9:57 pm

................................

mozerd · Sat Mar 12, 2022 11:20 pm

@anav
Very sorry but I can no longer recommend your link because I absolutely disagree with your wg approach …..

anav · Sat Mar 12, 2022 11:49 pm

...............................

Sob · Sat Mar 12, 2022 11:59 pm

Main error is that you got caught in that retarded idea (your "(2) IP ADDRESS FOR IP ROUTES") and refuse to understand this simple fact. It's broken beyond repair (and by design). You can't save it. But you keep piling on this nonsense and making it even worse (surprisingly, it's still possible). At least your initial version worked. Current one won't even do that.

anav · Sun Mar 13, 2022 12:13 am

............................

Sob · Sun Mar 13, 2022 12:41 am

You're cheating, now you made it half-right. The part that wouldn't work at all was:

/ip address
add address=10.10.5.45/32 interface=wg-local network=10.10.5.0
add address=10.10.5.48/32 interface=wg-local network=10.10.5.0

And what you posted now:

Q1) As it is, 50% between yes and no. Assuming that 40/50 was typo and it should be 50 everywhere, the answer would be yes. But 50% would be still wrong.

Q2/Q3) Yes, you will get routes, but that's not the point.

Once more (and possibly for the last time):

192.168.45.1/24 is correct, because it's local subnet on WG interface. Clients (192.168.45.2/32, 192.168.45.230/32) are in this local subnet. That's how it's done.

192.168.50.1/24 is wrong, because 192.168.50.0/24 is remote subnet, it belongs somewhere else, no 192.168.50.x address should be on your router, they all should be in remote LAN, because that's where this subnet is. You want route to this subnet, so just add route. What you do doesn't make any sense. If you want one thing, why would you add another thing that gets you the thing you want, intead of adding directly what you want? Plus it breaks things. What if you want to connect to remote 192.168.50.1? You can't, you will connect to your router, because your router thinks it owns this address.

anav · Sun Mar 13, 2022 12:42 am

.............................

Sob · Sun Mar 13, 2022 1:09 am

And for a moment I dared to think that you finally understood...

Two things:

1) Why? If you want route and it's simple and easy to add route, why do you add address (remember, you hate addresses) in order to get route? It's like if you want egg for breakfast. You can either reach in fridge and simply take an egg that's sitting there, or you can go out, fetch a hen, let it lay egg, then let hen run around and shit everywhere. If you remember that you just wanted egg (and you had it available), isn't it better to leave out hen?

2) It doesn't work. Let's say I'm peer 3 and this 192.168.50.0/24 is mine. Aside from you stealing my address, I need to be able to access your network from all 192.168.50.x addresses (x = 1-254). You can't put any of them on your router, because it will break access from mine.

Sob · Sun Mar 13, 2022 1:13 am

However, if the mistake is MT allowing this to occur, they have had several RCs to fix it and have not.

It's not MT's mistake, it's your mistake. It's like if you make your whole firewall:

/ip firewall filter
add chain=input action=drop

and you lock yourself out. MT allowed this to happen, but it's your fault.

anav · Sun Mar 13, 2022 1:31 am

................................

Sob · Sun Mar 13, 2022 1:37 am

You missed one post.

anav · Sun Mar 13, 2022 3:56 am

.............................

anav · Sun Mar 13, 2022 4:16 am

I will leave all wg assistance to others then.

Sob · Sun Mar 13, 2022 2:03 pm

Seriously?! Please tell me it's part of the joke. So now I'll be the bad guy who pushed you do delete everything, even though in reality I just explained to you (over and over) the one thing that was very wrong, and that you shouldn't do that if your intention is really to help beginners. Talk about overreaction...

404Network · Sun Mar 13, 2022 4:09 pm

Seriously?! Please tell me it's part of the joke. So now I'll be the bad guy who pushed you do delete everything, even though in reality I just explained to you (over and over) the one thing that was very wrong, and that you shouldn't do that if your intention is really to help beginners. Talk about overreaction...

Im done with wireguard, clearly I missed the boat somewhere and until I understand it, wont bother clouding the forums with crap.
Dont want to waste anyone else or my time any further. Its not an over reaction, its a sanity check, not good for my health.

Sob · Sun Mar 13, 2022 4:57 pm

<placeholder for strong enough words that would express my frustration>

As far as understanding WG goes, you were already there. Yes, your insistence on avoiding addresses as much as possible (even when it didn't help anything) wasn't something I liked, and I think there's good reason why beginner-oriented tutorials don't do that. But ok, it wasn't wrong, just less common. Other than that, I really thought that you understood things. Until you got stubbornly stuck with that one stupid thing, for no good reason, and it wasn't even directly related to WG, it would be equally wrong with ethernet or any other interface type.

So think it over and if you're not sure about anything, just ask. I explained so many things to you, some even several times, I can do few more tries.

mozerd · Mon Mar 14, 2022 7:44 pm

I have contacted MikroTik and requested information as to how the Following WireGuard fundamental Principle is supported in RoS ....
When I receive a response I will post it here assuming that they will permit me doing that.

Today I received a response from MikroTik …. Cryptokey routing is fully supported under RoS 7.x .. everything is combined under /interface/WireGuard …. Which displays the relevant data.

Larsa · Mon Mar 14, 2022 9:08 pm

Ok, but the very heart of WireGuard is Cryptokey Routing so what do they mean by that? Indeed Cryptic...

Mon Mar 14, 2022 9:51 pm

Proper routing is done using public/ private key lookup.
Addresses are linked to those keys.
That's how it knows how to route what where.

mozerd · Mon Mar 14, 2022 9:59 pm

@larsa
I agree that it’s cryptic … I also believe that RoS fully supports WireGuard but a lot of the stuff like the Tools the Donenfeld provides with WireGuard is encapsulated within RoS otherwise allowed IPs would not work the way that is expressed in the WireGuard docs.

A very simple test for example:
On the TikYou set up WG having interface 172.16.50.1
and have your peer a iPhone access 2 subnets residing in your Tik LAN
Lest say subnet 1: 192.168.99.0 and subnet 2: 10.10.50.0
In subnet 1 you have NAS IP 192.168.99.155 … allowed IP
In subnet 2 you have a Windows PC IP 10.10.50.99 … allowed IP
When WG is activated on the iPhone you should be able to ping 192.168.99.155 and also 10.10.50.99 without having to manually enter either route and only rely on the Tik DAc route 172.168.50.0/24 …. Yes both addresses are reachable …. How can both of these addresses be reachable without a static route entry?

If however you manually enter a static route for 10.10.50.99 ….. can you ping both addresses ? Tell me what happens ….

anav · Mon Mar 14, 2022 10:05 pm

Good to know.
I have to think in concepts because its clear I know shit when it comes to networking.

(also not relevant for me unless i consider MT in the context)

For LOCAL OUTBOUND TRAFFIC.
In my twisted way, I think of it this way.
USER (payload) ---> Destination address ----> MT device -----> IP routes
IP Routes ---- > gwy=wireguard interface ---> STOPPEN ---> Wireguard Protocol

Wireguard Protocol ( Wireguard Mini Router = Wireguard Customs office. )
Customs officer attempts to find a match of destination address with Allowed IP in the list Peers starting at Peer1 on the list.
Match found ----> Peer Selection ----> encrypt payload (right public key) ----> add destination address and destination port for that peer --->create transport packet
Transport packet ----> MT Device
IP Routes ----> gwy= ISP gateway IP table=main ---> WWW.

++++++++++++++++++++++++++++++++++++++++++

On the INCOMING SIDE,
MT Device ------> Incoming Transport packet ------> Incoming destination address exists on device ------> IP routing
IP Routing ----> Due to destination port on transport packet ------>STOPPEN ----> Wireguard Protocol/Customs Office
WG Protocol -----> decrypt transport into payload from associated peer and then reveal Source IP address
Customs officer confirms that the source IP exists on the peer used to decrypt the payload.
Source IP exists -----> send payload to MT device
MT Device ---> Route to correct interface via destination address and firewall rules

So in my twisted way, I dont think of wireguard protocol doing traditional routing but it is doing some steering and marshaling and thus is like a customs booth at an airport.
Thus on the outgoing side, I think of the MT device routing the traffic to wireguard, wireguard 'customs processing' is executed, the resulting traffic is returned to the router for onward IP routing.
On the Incoming side, I think of the mT device routing the traffic to wireguard, wireguard 'customs processing is executed', the resulting traffic is returned to the for onward IP routing.

Notice, I completely avoided any use of IP address for wireguard interface.

anav · Mon Mar 14, 2022 10:07 pm

Proper routing is done using public/ private key lookup.
Addresses are linked to those keys.
That's how it knows how to route what where.

More accurately destination addresses for outbound, source addresses for inbound
AND NOT anything to do with
IP addresses for interfaces.

Larsa · Mon Mar 14, 2022 10:11 pm

Proper routing is done using public/ private key lookup. Addresses are linked to those keys. That's how it knows how to route what where.

Well yes (sort of), but I'm afraid you missed the point where they "admit" that the complete wg driver actually is included in ros. fun! Besides, wg peers and the mt routing engine based on the underlying netfilter/nftables are two separate entities.

anav · Mon Mar 14, 2022 10:50 pm

Proper routing is done using public/ private key lookup. Addresses are linked to those keys. That's how it knows how to route what where.

Well yes (sort of), but I'm afraid you missed the point where they "admit" that the complete wg driver actually is included in ros. fun! Besides, wg peers and the mt routing engine based on the underlying netfilter/nftables are two separate entities.

Concur and that is why I try to understand the implementation as two processes working together.

mozerd · Mon Mar 14, 2022 11:26 pm

One other very interesting observation

In Winbox Tools and using the Ping tool if no static route is added for 10.10.50.99 in my test scenario 10.10.50.99 is pingable but as soon as a static route is added 10.10.50.99 becomes host unreachable ….. why?

Yes in the configuration all subnets are isolated from each other.

anav · Mon Mar 14, 2022 11:41 pm

One other very interesting observation

In Winbox Tools and using the Ping tool if no static route is added for 10.10.50.99 in my test scenario 10.10.50.99 is pingable but as soon as a static route is added 10.10.50.99 becomes host unreachable ….. why?

Yes in the configuration all subnets are isolated from each other.

You have missing information
IPHONE
- faux IP address = ________________________???
-allowed IPs =192.168.99.155 (NAS), 10.10.50.99 (PC)

TIK Wireguard
- allowed IP = _______________?

TIK Router
IP address=172.168.50.1/24 interface=wg-tik network=192.168.50.0

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

By the way, If I wanted to test ping like you are doing here is my solution.....

IPHONE
- faux IP address = 172.168.50.5/32
-allowed IPs =192.168.99.155 (NAS), 10.10.50.99 (PC)

TIK Wireguard
- allowed IP = 172.168.50.5/32

TIK Router
IP address=nil entry

IP Route
dst-address=172.168.50.5/32 gwy=wg-tik table=main

Firewall Rules
add chain=forward action=accept in-interface=wg-tik dst-address=192.168.99.155/32 src-address=172.168.50.5/32

Since the firewall rule already allows full access, you should be able to also ping the device.

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Tue Mar 15, 2022 12:03 am

Read the paper.
It's explained routing is done using lookup of the keys.

And yes, it is in the kernel hence it is in ROS.

Sob · Tue Mar 15, 2022 12:24 am

Let me try this. Start with few routers and networks connected using regular ethernet like this:

wgnet1.png

All blue addresses are reachable, because they are in same subnet. And all green ones need gateways like this:

On Router A:

/ip route 
add dst-address=10.0.2.0/24 gateway=172.16.0.2
add dst-address=10.0.3.0/24 gateway=172.16.0.3

On Router B:

/ip route
add dst-address=10.0.1.0/24 gateway=172.16.0.1
add dst-address=10.0.3.0/24 gateway=172.16.0.3

On Router C:

/ip route
add dst-address=10.0.1.0/24 gateway=172.16.0.1
add dst-address=10.0.2.0/24 gateway=172.16.0.2

Simple and clear, right? And guess what, you can use exactly the same config with Wireguard and it will work, because it's still basic networking with same principles. It's great, isn't it? It means that WG isn't some new and completely different thing, it's very similar to what you (probably) already know.

One difference is that Wireguard has additional config, allowed addresses, and it's used by this "crypto routing". It doesn't affect regular routing, you still need that, this is an extra thing. You can imagine it as additional something (black circles in image) sitting on the "wire" and filtering/routing packets:

wgnet2.png

On Router A:

- 172.16.0.2/32, 10.0.2.0/24 allowed for Router B
- 172.16.0.3/32, 10.0.3.0/24 allowed for Router C

On Router B :

- 172.16.0.0/24, 10.0.1.0/24, 10.0.3.0/24 allowed for Router A

On Router C:

- 172.16.0.0/24, 10.0.1.0/24, 10.0.2.0/24 allowed for Router A

(Router B and Router C don't have direct link between them, traffic goes via Router A)

"x.x.x.x/x allowed for Router X" means two things:

- x.x.x.x/x will be sent to X (if regular routing sends it to WG interface)
- x.x.x.x/x will be accepted when coming from X (if X sends something else not listed as allowed, it will be dropped)

Regular routing and crypto routing are two distinct complementary things (don't get confused by wg-quick and other high level clients, they automatically add routes for all allowed addresses; RouterOS doesn't do that). Usually you'll have them in sync, but you don't have to (which makes more or less sense depending on exact config). For example:

a) Allowed address 0.0.0.0/0 (= any address) and route to only 10.0.1.0/24 => only 10.0.1.x will be sent to peer.
b) Allowed address 10.0.1.0/24 and route to 0.0.0.0/0 => only 10.0.1.x will be sent to peer.

Difference between the two is that for a) the router won't even try to send anything else (e.g. 8.8.8.8) via WG interface, because no route points to there. For b) it will try to send it, but it will be blocked by WG. Part of this crypto routing is that peers on same WG interface must have distinct allowed addresses. If you'd add same 10.0.0.0/24 for more than one peer, WG wouldn't know to which one it should send such packets.

If you want to keep things simple, you can stop here and live happily ever after.

--

If you want to think about it a little more, then knowing all the above, you may ask whether you really need gateway=<IP address>. Regular routing needs some gateway, but what it really needs is just to find that it's somewhere on WG interface. It's actually WG's crypto routing which decides where (to which peer) to send packets. So you can use a shortcut, gateway=<WG interface> and it will work too.

Now that you got rid of IP address as gateway, you may go further and ask whether you need that IP address at all. And the answer is, not necessarily. If you're doing e.g. site to site tunnel, you only really care about local and remote LAN subnets, and maybe you don't want another extra subnet. After all, if you have site to site IPSec tunnel, there isn't another subnet there either, so why should it be here. And you're right, you can do without it. But it doesn't mean that the connecting subnet was completely useless!

If you're connecting e.g. from 10.0.1.100 (LAN A) to 10.0.2.100 (LAN B) and 10.0.2.100 is down, Router B would like to send icmp "host unreachable" to 10.0.1.100, to let it know that 10.0.2.100 is dead. If you have connecting subnet (172.16.0.0/24), it will use 172.16.0.2 as source. But if you got rid of it without knowing what you're doing, there's no address to use and there won't be any icmp message. So you just lost useful functionality. Was it worth it? But fortunately it can be fixed by adding pref-src to route and router will use that address, e.g. on Router B:

/ip route
add dst-address=10.0.1.0/24 gateway=<wireguard> pref-src=10.0.2.1
add dst-address=10.0.3.0/24 gateway=<wireguard> pref-src=10.0.2.1

Once again, having addresses is safe default config, don't get rid of them for no good reason. For example, if you have just peers with single addresses and no subnets behind them (phones, etc), safe default is to use standard ethernet-like config where server has IP address on WG interface (172.16.0.1/24) and it tells that all 172.16.0.x clients are to be found on that interface. You can get rid of this address and add route instead (dst-address=172.16.0.0/24 gateway=<wireguard>), but then you'll have same problem as in previous example, which can be fixed the same way, but it has no advantage whatsoever. Keep it simple, keep the address.

Sob · Tue Mar 15, 2022 4:39 am

Concur and that is why I try to understand the implementation as two processes working together.

Congratulations, you understand correctly! Just don't try to "improve" it with some crazy ideas.

In Winbox Tools and using the Ping tool if no static route is added for 10.10.50.99 in my test scenario 10.10.50.99 is pingable but as soon as a static route is added 10.10.50.99 becomes host unreachable ….. why?

Because you're trying to take torch from @anav and continue his previous adventure.

Don't. If 10.10.50.99 is PC in LAN behind router, then router already has route to it (a dynamic one created by 10.10.50.x/24 address on that interface). If you add another one to 10.10.50.99, you can only break things. iPhone's WG client automatically creates routes for allowed addresses, so you don't need to do anything there either. If it wasn't iPhone but RouterOS device, it wouldn't happen, and you'd have to add route (dst-address=10.10.50.0/24 gateway=wireguard) on this device.

Tue Mar 15, 2022 7:39 am

Excellent explanation, Sob !
This should be in the help page !

Znevna · Tue Mar 15, 2022 10:25 am

@mozerd maybe you should hire a consultant to teach you a thing or two about networking.
Or take a class or something. Before you copy-pasta any more info from github, mm?

anav · Tue Mar 15, 2022 1:11 pm

I see Mozerd's mother has entered the thread again. ;-PP (Let it rest Znevna.......)

anav · Tue Mar 15, 2022 2:08 pm

Excellent explanation, Sob !

Yup! Said, by you and the crickets.

This should be in the help page !

Yes, after reading that any beginner is 100% ready.

mozerd · Tue Mar 15, 2022 2:25 pm

In Winbox Tools and using the Ping tool if no static route is added for 10.10.50.99 in my test scenario 10.10.50.99 is pingable but as soon as a static route is added 10.10.50.99 becomes host unreachable ….. why?
Because you're trying to take torch from @anav and continue his previous adventure. Don't. If 10.10.50.99 is PC in LAN behind router, then router already has route to it (a dynamic one created by 10.10.50.x/24 address on that interface). If you add another one to 10.10.50.99, you can only break things. iPhone's WG client automatically creates routes for allowed addresses, so you don't need to do anything there either. If it wasn't iPhone but RouterOS device, it wouldn't happen, and you'd have to add route (dst-address=10.10.50.0/24 gateway=wireguard) on this device.

@Sob ... you do understand that @anav is one very smart dude

an ACERBIC Lama 4 sure (sharply or bitingly critical, sarcastic, or ironic in temper, mood, or tone)

Thank YOU I will buy into your explanation now ---- and --- very much liked your SUPERB "article" preceding

.....

mkx · Tue Mar 15, 2022 3:21 pm

Let me try this. Start with few routers and networks connected using regular ethernet like this:

Thank you, @sob ... I hope now people will stop spreading inaccurate information.

My short interpretation: the first diagram applies to WG mesh as well, the peers logic being hidden in the "switch" black box. Ethernet switch uses ARP table to select destination port, WG interface uses crypto-routing for the same. Ethernet switch learns MAC addresses automatically, WG interface is configured statically. Both magics only apply after packet enters the black box, usual L3 routing has to push packet into it (unlike black holes which suck data all by them selves

)

Larsa · Tue Mar 15, 2022 4:55 pm

Good sum up! @Sob, may I suggest you put a copy of your post in "Useful user articles"?

Sob · Tue Mar 15, 2022 5:29 pm

@anav: What will it take for you to like it? Should I add "dedicated to @anav" to it? Or "to @anav with love"?

@mkx: That's my idea, to show that it's not that much different. Slight problem with full mesh is that with NATs everywhere, you won't usually have it, because WG doesn't have any built-in support to get through those. As a result, the WG-specific config (allowed addresses) will be slightly different and won't match exactly the regular IP config (addresses/routes). But if there was full mesh, it would.

@Larsa: I'll probably do it later, after I polish it a bit, think about if there's some additional stuff it could have, etc.

anav · Tue Mar 15, 2022 6:31 pm

Larsa, there is no point in etching it in stone with all the errors I have found, he is waiting to be corrected before publishing! jajajajajajaja

I do have many questions/observations (not related to crypto key routing, that part is rock solid). I keep writing and rewriting a very long post,,,,,,,,,,,sigh.......

Sob · Tue Mar 15, 2022 6:59 pm

Oh yeah, and feedback from fans. I'll clear my schedule.

anav · Tue Mar 15, 2022 7:01 pm

Oh yeah, and feedback from fans. I'll clear my schedule.

It can wait until after you go to Poland to help refugees, now that is important work!!!

mkx · Tue Mar 15, 2022 7:42 pm

@sob, yeah I know that WG can do quite a bit more magic than simple ethernet switch. But if you think about it, ethernet switch doesn't have to be just plain ... there are ACLs, etc. And besides, ethernet is a LAN L2 protocol without much of security needed while WG aims to provide secure communication in a very hostile environment so it better provide some good magic ... but as we agree, L3 requirements are just the same regardless of underlying technology (ethernet, ATM, infiniband, wireguard, IPsec, SLIP, IPoAC, ...), routes are still needed.

anav · Tue Mar 15, 2022 10:25 pm

Observations
1. Very good diagram example of a generic network, and I liked the separation using the black WG bubbles. It would have been preferential to have more LANs per router and perhaps a bit more detail for allowed IPs between them but still nice and clean.

2. You selected a coordinated IP address subnet for your peer wireguard interfaces, which reinforces your notion that an IP address for the wireguard interface is expected and a good thing.

3. The explanation, or more accurately the purpose of the paragraph starting with "Regular routing and crypto routing are two distinct complementary things... and ending with "....happily ever after." was vague and weak. At first I thought you were trying to describe crypto routing and then realized you were just attempting to highlight the different effects on traffic between IP routing and Crypto Routing. This needed a bit more detail and clarity.

4. Personally I prefer to look at Crypto Processes as its own mini router (or Customs Booth if you will), and thus VERY conceptually (for the new beginner), gets user traffic from IP routing (payload), converts that to encrypted user traffic with RIGHT peer destination information (encrypted transport packet) and then back to IP routing for onward TX, and then the reverse happens at the other end. They work hand in hand to ensure the traffic gets to where it needs to be and thus both Route in their own way, and I view Crypto Routing as Crypto Steering or Marshaling because I get easily confused

when using the word Routing for different processes. But thats just me, it is crypto routing and I have no issues with how it works and what it does.

5. What the new person, beginner, should focus on is that Crypto Routing runs in the background and has to do mainly with two processes. However, for crypto routing to occur, it is the responsibility of the admin, to first accurately state the Allowed IPs for each peer (key word being peer=remote site). More specifically the admin should, at any local device, consider the Allowed IPs as they relate to the remote end for two distinct populations of addresses, a. the destination addresses at the remote end, for local users heading outbound and entering the tunnel, and b. the source addresses for users at the remote end, heading inbound and will be exiting the tunnel. Now that the Allowed IPs are correctly established by the admin, Crypto Routing can carry out its two integrated processes, and the really core bit uses the admin Allowed IPs to ensure the right peers and right keys are matched to the local traffic entering the tunnel so that the right destination information is added and subsequently at the other again compare peers and allowed IPs to ensure authorized traffic is allowed to exit the tunnel. The other process which occurs is the encryption and decryption (not as exciting). That is enough detail for the new beginner at the start of their journey. I added a bit more detail a few post before which adds the order of events involved (encryption, matching, selection, filtering etc.).

6. I liked the fact that you included the IP addresses of the other sites wireguard interfaces as part of the Allowed IPs. Did you do this to facilitate PING?
Or does this automatically ensure then that fragmentation issues are reported??? This question becomes clearer later!

7. I was disappointed you skipped an important step in your evolutionary process, namely this configuration, that you didnt put and was waiting to see. I am truly hoping I got the gateway IPs correct.
/ip route (at LANB)
add dst-address=10.0.1.0/24 gateway=172.16.0.1 table=main
add dst-address=10.0.3.0/24 gateway=172.16.0.3 table=main

8. Now you can tie in question 6, with the observation at 7. and my follow-on questions.
Q1 - If I have stated the IP routes as such, would I still need to include the IP addresses of the interfaces in the Allowed IPs, to PASSIVELY detect and report fragmentation issues???
Q2 - Are they linked? or is the Allowed IPs inclusion simply to facilitate the more ACTIVE ping test/troubleshooting.

9. I forget to mention in 6, that I liked how you used the subnet to describe the Allowed IPs for the IP wireguard addresses, such that in all cases only one entry need be made to cover all peers and thus every possible ping direction!

10. Then we get to the use of IP address for Wireguard, for the simple case, one mobile peer or perhaps 3 or 4, where they all have a faux address where we conveniently ensure their nomenclatures line up such that they can easily be described or captured within a subnet and then we provide an IP address for the Server WG interface that includes them. This shows some flexibility in your thinking on the use of IP address and that you do realize the practical effect that this causes DAC routes for those to be created on the Server device.

11. What is not clear to me yet, is how you can justify that usage but then not be consistent when the same could potentially be used for a subnet on a different peer, not an iphone - not a faux IP, but an MT device peer subnet. Somehow to you, the IP address on the phone is sufficiently different from a subnet on another MT Device such that you dont want to use an additional IP address line to also include this subnet - and yes one has to ensure there is no overlap or conflict with any other peers. I am still fuzzy on the distinction??

12. Now we get to - okay we can get away with using wg-interface, but if we do, then we lose something in the translation for Passive communications fragmentation reports etc... Here is where you propose Pref Source. I understand pref source, in that it will change the source IP of the payload to that suggested in this case you picked the LAN gateway 10.0.2.1. However this could be misleading. What if router A had 3 subnets...............?? What then?
In other words, the missing part of the equation here is that whatever pref-source you select IT HAS TO BE on the allowed IP list at the remote site. This wasnt explicitly stated and needs to be. With that wording, the reader can then go back to your example information and confirm YES, I see now that that pref- source is included in the allowed IPs at the other end, and thus will be allowed to exit the tunnel at the other end.

13. But then I get confused because it appears to me in your example the preferred source is the same as the source initiating the packets so what has been gained ?? Assuming preferred source changes the source of the payload from whatever it is to the preferred source IP. There is some nuance I am missing?? The source is A, and the preferred source is A? what is gained??
I think I am missing an important point here.

14. Another point of confusion with pref source, is this only for originating devices, traffic from local subnet heading outbound? What happens for the associated Return Traffic at the Server Side and the IP routes created there??

15. Lastly we get to the discussion of using wg-interface only with manual IP routes. It works but as you state is missing the Passive communications component and may not suffice for ACTIVE troubleshooting/pinging.

16. For ACTIVE pinging one can choose any existing Allowed IP for this purpose and if necessary identify an existing subnet at the other end and include this in local Allowed IPs, so that is easily accomplished without too much fuss.

17. For Passive communications, it seems you are saying the two ways to ensure this is done right but the over riding requirement is that:
AN IP address for the wireguard interface has to be present, as per your example, and needs to be a coordinated subnet between the peers.
Then one has two options:
a. use the correct gwy IP ADDRESS in the IP route OR
b. use wg-interface name WITH pref source!

18. In other words any time you deviate from some form of 17 (aka like 15) , the full breadth of possible communications between WG interfaces is not established.

Summary: The above represents what I got out of your post. Sorry I do not have the level of understanding of the others and thus cannot blindly accept stuff if not understanding how and why it functions.

Outstanding issues.
1. For me to understand Passive Communication (fragmentation or any other magic that happens automatically (passively) with the proper structure).
2. For you to explain why I cannot use multiple IP addresses for all my local Allowed IPs.

)))) but I can for single IP devices like Iphones.
3. To explain pref source explaining the purpose, as it looks like the source and source pref are no different in the example AND ALSO in terms of return traffic vice originating traffic, as it appears you only describe originating outbound ??

For example let me propose and addendum to your example. The PLUS lines are added to show what I would normally have done, and
based on your information would do in the future.

IP addresses associated with Wireguard on the devices.
Peer1 - iphone - 192.168.35.2/32
peer2 - laptop - 192.168.35.200/32
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
peer3 - MT device client - 172.168.77.2/24 ( Subnet 10.10.10.0/24 needs to access server on Local Router subnet D)
peer4 - MT device client 172.168.77.3/24 (Subnent 10.20.10.10.0/24 needs to access server on Local Router subnet E)
Server- Local Router - 172.168.77.4/24

Allowed IPs Local Router
192.168.35.0/24 (handles both incoming peer 1 and peer 2 - using local Router internet and for peer 2, To be able to config the local router - so fw rules have to lineup)
10.10.10.0/24 (handles incoming subnet from peer3)
10.20.10.0/24 (handles incoming subnet from peer4)
+++++++++++++++++++++++++++++++++++++++++++
172.168.77.0/24 (ensures any device can ping any IP wireguard interface )

IP Routes Local Router
dst-address=192.168.35.0/24 gwy=192.168.35.1 table=main
dst-address=10.10.10.0/24 gwy=172.168.77.2 table=main
dst-address=10.20.10.0/24 gwy=172.168.77.3 table=main

IP Routes other peers
[peer3] dst-address=subnetD/24 gwy=172.168.77.4 table=main
[peer4] dst=address=subnetE/24 gwy=172.168.77.4 table=main

OR
Let say I add a second, IP address to the local router wireguard interface........
and this time lets use wg-interface for the gateway,
Server- Local Router - IP1 - 172.168.77.4/24 / IP2 - 192.168.35.1/24

IP Routes
(DAC) dst-address=192.168.35.0/24 gwy=wg-local table=main
dst-address=10.10.10.0/24 gwy=wg-local table=main pref source=??
dst-address=10.20.10.0/24 gwy=wg-local table=main pref-source=??

IP Routes other peers
[peer3] dst-address=subnetD/24 gwy=wg-peer3 table=main pref-source=10.10.10.1 ??
[peer4] dst=address=subnetE/24 gwy=wg-peer4 table=main pref-source=10.20.1.1 ??

What i find strange is that pref source is already the source IP, the source packets from peer 3 are from subnet 10.10.10.0/24, the source packets from peer 4 are already from 10.20.10.0/24 ??

Sob · Wed Mar 16, 2022 2:55 am

I meant cleaning my schedule as a joke, but ... well ... :)

1) One LAN or ten LANs, the only difference is that you'll have one or ten routes and subnets in allowed-address. And it's simple example focused on routing and WG, everything is allowed to communicate with everything else. If you'd like to limit something, it would be job for firewall, which is yet another independent layer.

2) Because it is. It's safe default, it's same as ethernet, which makes it easy to understand.

3) I was trying to explain relation between the two. How it's possible to allow more in one and less in the other (or the other way around), but how it's actually intersection between the two that matters in the end. And yes, it can probably be improved.

4) Fine by me. And as you can see, I have it as those separate black circles, which was supposed to suggest that it's sort of separate.

5) I think it's there, right after second image. For each peer you have to define what it can send and receive. And it mustn't conflict between different peers (this part should probably be mentioned a bit earlier).

6) It's simply because they are there, and if they should be able to pass through tunnel, they need to be listed as allowed.

7) It's in the first part, the ethernet config (which is also shared when it's WG).

8) See 6). The peer has them, you want them to be able to pass through tunnel (doesn't matter if you actively try to communicate with them, or the communication is initiated by peer), they must be allowed.

9) If you mean 172.16.0.0/24 on B and C, instead of using only existing addresses (e.g. 172.16.0.1 and 172.16.0.3 on B), you can see it either as lazy shortcut or future proof config. Currently there are only .1, .2 and .3, but if I decide to add .4 for another client that won't have subnet of its own (e.g. a phone), I won't have to touch Router B or C and everything will work. Only changes needed will be on Router A and on this new client.

10) One thing, all addresses are real. If in 9) I mentioned another phone client, it will get 172.16.0.4/24 and it will be real address, the client will really have and use it. And again, it's the basic networking, that's how you'd do it with ethernet.

11) I'm not completely sure if I understand. But I guess it could be related to the past misunderstanding about what's local and remote. Addresses 172.16.0.x/24 are in local subnet in relation to WG interface. Addresses 10.0.x.x/24 are remote subnets, because they are behind other routers.

It's true that if you look at it from Router A, then address 172.16.0.2 (owned by Router B) is remote, because it's on different router. But it's still in local subnet. Here comes ethernet again. If you have all routers connected using switch, then even though address 172.16.0.2 is on remote router, it's clearly in local subnet. Same way your PC 192.168.88.10/24 is in same local subnet with your router 192.168.88.1/24. That's clear, right?

And the only difference with WG is that you don't have any cables, only virtual links. Physically different, but logically the same thing.

12) Important thing, this has nothing to do with just WG, it will happen with other interface types too.

Simple version, when router itself wants to send packet somewhere, it needs to select source address to use. Most common case is that it simply takes whatever address is on the interface where it sends the packet. So if you have your typical home router with 192.168.88.1/24 on LAN and 1.2.3.4 on WAN, then when destination is some 192.168.88.x in LAN, it will use 192.168.88.1 as source, and when it's something else (e.g. when it checks for updates), it will choose 1.2.3.4, because packet is going to internet. It's logical, right? But if outgoing interface doesn't have any address, it doesn't know what to choose and it fails. So there's another option (which actually has precedence) and it's pref-src address on route. When router decides to where it should send this packet, it first checks routes (it's "routing decision" in some diagrams). It finds the best route, and if this route has pref-src, it will use it as source. And that's it.

It just has to be some address owned by router, so if you have several LAN subnets, pick one address from any of them. Or completely different one, it would work too (but if it should be completely proper config, all other routers should be aware that this address is on this router, so they ideally should have routes to it; so it's probably better to stick with something they already have route to). Or you can just keep the connecting subnet (172.16.0.x/24 in example) and not worry about pref-src.

Whether WG must allow this address, of course, it's still the same thing as in 6) and 8), otherwise it couldn't pass through tunnel.

13) See 12), I think it's all explained there.

14) Pref-src is when router itself sends something. It doesn't influence forwarded packets from other devices.

15) As described, don't do it when it doesn't give you any advantage. If you're doing site to site tunnel and you don't need another subnet at all, then it can make sense to skip addresses on WG interfaces. But if you do need some subnet, e.g. because you have several phones and each gets 172.16.0.x, then replacing address (172.16.0.1/24) on server's WG interface with route (172.16.0.0/24) doesn't help with anything, it's not better in any way, it's worse, don't do it.

16) Yes.

17) No. It's two different things, gateway and source address. You can have different combinations:

a1) WG interface with address 172.16.0.x/24, route with gateway=172.16.0.y => 172.16.0.x will be used as source
a2) WG interface with address 172.16.0.x/24, route with gateway=<WG interface> => 172.16.0.x will be used as source
b1) WG interface without address, route with gateway=172.16.0.y => won't work at all (there won't be any communication with remote subnet), because regular routing doesn't know where 172.16.0.y is
b2) WG interface without address, route with gateway=<WG interface> => will need pref-src to fix source address

Difference between gateways is that:

a) gateway=<WG interface> clearly relies on WG's crypto routing based on allowed addresses
b) gateway=172.16.0.y seems to use the specified gateway address, but it doesn't really do that, it only finds out that 172.16.0.y should be reachable on <WG interface> (a1 above)

So while b) is correct, if you want to keep ethernet-like config, it in fact can be confusing, because you can't really choose gateway (remote router) this way. For example, "/ip route add dst-address=10.0.1.0/24 gateway=172.16.0.3" on Router B wouldn't work as it suggests at the first sight. It says that the subnet (10.0.1.0/24) is behing Router C (172.16.0.3), but if WG's allowed-address says that it should be sent to Router A, it will win.

---

As for your outstanding issues, bring them back if you still have some after reading this. And if #2 is that thing, don't even start with that. If you really (*really*) don't understand why it's completely wrong, I can try once more, but I don't think I should have to do that, it's such basic thing that it should be obvious (and again, it doesn't have to do anything with WG).

---

And your examples:

- Allowed addresses are per-peer, you can't have 192.168.35.0/24 to cover both peer 1 and 2. Each must have only their 192.168.35.x/32
- Same for 172.168.77.0/24, each peer on main router must have only own 192.168.77.x/32.
- Peers themselves (remote devices) can have allowed-address=172.168.77.0/24 for peer representing server, it will allow them to reach other peers via main server.
- Route dst-address=192.168.35.0/24 gwy=192.168.35.1 is nonsense, in first example you don't have any 192.168.35.1. You could have your address-less dst-address=192.168.35.0/24 gwy=<WG interface>, but it's better to not do that, as explained above.
- Other routes are correct (they would also work with gwy=<WG interface>, see 17).
- Address 192.168.35.1/24 in second example is correct.
- If peers have 172.168.77.x/24 on their WG interfaces, you don't need pref-src for routes (see 17).
- Otherwise it would be pref-src=<some address assigned to router and allowed on remote peers>

anav · Wed Mar 16, 2022 3:47 pm

Read and answered in order so there may be duplication!

6) It's simply because they are there, and if they should be able to pass through tunnel, they need to be listed as allowed.
You didnt answer the questions here! Its simply because they are there....... is a frivolous answer without any meaning. Yes BUT should they be allowed to pass through the tunnel?
What uses will be made of them? Does it have to with permitting PING, or to auto report ping fragmentation??

The peer has them, you want them to be able to pass through tunnel .......... they must be allowed.
But why? What functionality are you protecting? Since you seem unable to answer this question thus far let me phrase it differently............ what will not be possible if you do not include them in allowed IPs.

11) I'm not completely sure if I understand. But I guess it could be related to the past misunderstanding about what's local and remote. Addresses 172.16.0.x/24 are in local subnet in relation to WG interface. Addresses 10.0.x.x/24 are remote subnets, because they are behind other routers.

Well I appreciate how you view the coordinated subnet created between WG interfaces as a local subnet (to all wg devices). I also understand that yes from any local device, subnets on other routers are remote subnets. However my question was not that, it was why are you content to include an IPHONE within a local WG interface IP address and despite the iphone being a remote device, but not a subnet on another remote device, an MT device. What is the difference I am missing?? As you state this has nothing to do with WG but something else I am missing!!

Is it not true that as soon as I identify something with an IP address at the local router, that something (be it an IPHONE or a subnet) is now considered local on that router.
Hence IP address= 192.168.50.1/24 interface=wg-local network=192.168.50.0 WHERE 192.168.50.0/24 describes a subnet on a peer, means now for all intensive purposes that the subnet is recognized as a local entity, in terms of routing at least?
Hence - (dac) dst-address=192.168.50.0/24 gwy=wg-local table=main IS CREATED AND PROPERLY UTILIZED BY THE ROUTER???

More work to be done here.....

12) Important thing, this has nothing to do with just WG, it will happen with other interface types too.
AHHH, this is really good stuff!! We may spend several weeks here. :-0
However I need to drill down WHERE this pref source is applied. Is it applied in the payload, or is it applied on the transport??
Perhaps that is where i was getting confused, as the payload is from the user, and it seemed to me you were picking the the same source for pref-source.
However if we are talking transport then yes, instead of the outgoing interface router IP, pref-source changes this to the local user subnet IP.

So basically the transport layer has to have some address assigned to it as source and if we use the actual WG gateway IP on the IP route, that is the obvious choice and is readily available.
If we use the gwy=wg-interface-name, then we are forcing the router to decide.
Would it not simply go get the wg interface IP address line to get that info, if one is assigned??
If so, then what we are saying is that if you have no IP address for the WG interface, pref-source is a viable alternative.

15) As described, don't do it when it doesn't give you any advantage. If you're doing site to site tunnel and you don't need another subnet at all, then it can make sense to skip addresses on WG interfaces. But if you do need some subnet, e.g. because you have several phones and each gets 172.16.0.x, then replacing address (172.16.0.1/24) on server's WG interface with route (172.16.0.0/24) doesn't help with anything, it's not better in any way, it's worse, don't do it.

Even if I do this ???
allowed IPs=172.16.0.2/32, 172.16.0.4/32
dst-address=172.16.0.2/32 gwy=wg-local pref-source=(local subnet)
dst-address=172.16.0.4/32 gwy=wg-local pref-source=(local subnet)

Better??
IP address WG 172.168.0.1/24 interface=wg-local network=172.168.0.0
(dac) dst-address=172.16.0.0./24 gwy=wg-local table=main

17) No. It's two different things, gateway and source address. You can have different combinations:

a1) WG interface with address 172.16.0.x/24, route with gateway=172.16.0.y => 172.16.0.x will be used as source
a2) WG interface with address 172.16.0.x/24, route with gateway=<WG interface> => 172.16.0.x will be used as source
b1) WG interface without address, route with gateway=172.16.0.y => won't work at all (there won't be any communication with remote subnet), because regular routing doesn't know where 172.16.0.y is
b2) WG interface without address, route with gateway=<WG interface> => will need pref-src to fix source address

Super, confirms what I did on 15. both will work. VERY CLEAR NOW. ( and yes a gateway IP without a corresponding IP address for WG interface is a no go)

All good................. so far

6. has some niggly points.
11. is where there is still some friction ( non wg friction

)

Sob · Wed Mar 16, 2022 7:57 pm

6,8) It's not much different explanation, but it's really that simple, if those addresses (172.16.0.x) should ever be able to pass through tunnel for any reason, they need to be allowed. If they exist, you may want to ping them, that's one good reason. If you don't fiddle with pref-src (which should be seen as advanced config, so not necessary), they will be used as source for router's communication to remote subnet (e.g. icmp messages), that's another good reason. It's enough for me. If you want to break these basic things (I'm not sure why would you want to), then don't allow them.

11) I'm still not sure (so keep trying if that's not it), but it isn't about the evil thing again, is it? In my example, 172.16.0.0/24 is local subnet for WG. Router B has 172.16.0.2, Router C has 172.16.0.3, they both have other subnets behind them, but that's irrelevant here. A phone client would get 172.16.0.4, another may get 172.16.0.5, etc. And they would all be in same local subnet (local in logical sense, with virtual links connecting their WG interfaces).

If your 192.168.50.0/24 is equivalent of my 10.0.2.0/24, i.e. it's behind another router, then no, you can't put address 192.168.50.1/24 on WG interface. It would tell router that this subnet is on its WG interface, but it isn't there, it's somewhere else. That's the reason why it's wrong. And the fact that with WG it would sort of work doesn't save it (if it was ethernet, it wouldn't work at all).

12) In this case, payload (packets inside tunnel). Nowhere so far we care about transport (outer encrypted WG packets), it's another layer that we know it's there, but it "just works" and that's all we need to know about it right now.

But yes, the same happens there too, these transport packets also need to choose source address. With simple router it will be whatever is on WAN interface (when peer is somewhere in internet), with dual-WAN router it will be whatever is on the WAN interface that gets used, and if there would be different route to peer (its public address) with pref-src, then that would be used as source.

15) I think you can see yourself that the second config is better. Imagine that you have not two but hundered peers. One address would still be enough to cover all of them. Your first example would need hundered routes. But it's not just about number of addresses, routes or whatever, we've been there before. You can avoid address and use one route for whole /24, and it will be one address vs one route. But you gain nothing by doing that. Main point is that the address (for local subnet) is safe basic config. If you want to use something else, you should be able to explain why it's better (not just different). If you can't, stick with default.

anav · Thu Mar 17, 2022 1:09 am

Almost there.
Where we differ is that very space.

By adding the IP address of a subnet from another router (due to basing it on allowed IPs) then I am not sure I have done something evil? What I have done is actually added that subnet to my router, since it now exists on an interface on the Router.

To be consistent how is the iphone any different. Its a remote device with an address, just like the remote MT with a subnet. So I co-opt that address by ensuring its within the existing IP address of my current WG interfaces and I dont see much difference in doing something similar with the subnet address due to my ignorance more than anything else.

Lets discuss the following example .........Where I try to apply newfound wisdom!!!
There is a subnet on my local router that peer 3 users (on an MT device) will need to access which has address of 172.168.20.1/24 interface=whatever network=172.168.20.0
The peer 3 users themselves,are on subnet with address of 10.10.10.1/24 interface=whatever network=10.10.10.0

IP addresses for wg, where I try to apply all the good stuff!
peer1 192.168.50.3/32 iphone
peer2 192.168.50.200/32 laptop
peer3 192.168.50.2/24 interface=wg-peer3 network=192.168.50.0 Allowed IPs = 192.168.50.0/24, 172.168.20.0/24
Local 192.168.50.5/24 interface=wg-local network=192.168.50.0 Allowed IPs = 192.168.50.2/32, 192.168.50.200/32, 192.168.50.3/32, 10.10.10.0/24

Peer 3 Routes
dst-address=0.0.0.0/0 gwy=wanIPgateway table=main
dst-address=172.168.20.0/24 gwy=wg-peer3 table=main
dst-address=192.168.50.0/24 gwy=wg-peer3 table=main

Local Routes
dst-address=0.0.0.0/0 gwy=wanIPgateway table=main
dst-address=192.168.50.3/32 gwy=wg-local table=main
dst-address=192.168.50.200/32 gwy=wg-local table=main
dst-address=192.168.50.2/32 gwy=wg-local table=main
dst-address=10.10.10.0/24 gwy=wg-local table=main

Correct ???
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

So now lets 'sweeten the pot' and add some juice!
The subnet on peer 3 device (DHCP server) assigns leases from 10.10.10.20-254

I elect to add an IP address to the local Router and smartly choose
add address=10.10.10.10/24 interface=wg-local network=10.10.10.0

In this regard there is no potential conflict with a user at the other end for that subnet.
Result:
(dac) dst-address=10.10.10.0/24 gwy=wg-local replaces the similar manual remove above.

Will this work? If not what breaks? Are you having a nervous breakdown?

mducharme · Thu Mar 17, 2022 1:46 am

But if you got rid of it without knowing what you're doing, there's no address to use and there won't be any icmp message. So you just lost useful functionality. Was it worth it? But fortunately it can be fixed by adding pref-src to route and router will use that address, e.g. on Router B:

Are you sure this is the case that there won't be any ICMP message without setting pref-src? I have to admit I have not tested this myself. But I am thinking of the very similar situation with IPv6 where you can do a traceroute and you don't necessarily have a global point to point subnet connecting two routers together, just an fe80:: link local subnet. In this case, the router uses another global address that it has to respond to the traceroute, for instance a loopback address.

If MikroTik IPv4 behaves similarly to this process, I would expect it would still send ICMP messages without pref-src set in this situation, but instead that they would come from some randomly selected IP that was the "winner" of some selection process (a dynamic pref-src rather than a static one). But I admit, I have not tested this, and so you could very well be correct. The rest of what you said is quite accurate and I agree with it. I'm just wondering about that one bit.

Sob · Thu Mar 17, 2022 2:37 am

@anav: Problems with your config:

- Allowed IPs all together are misleading, but I'm pretty sure you know that it's 192.168.50.3/32 for peer1, 192.168.50.200/32 for peer2, 192.168.50.2/32 and 10.10.10.0/24 for peer3.
- Peer3 doesn't need manual route for 192.168.50.0/24, it will have dynamic one created by its 192.168.50.2/24 address.
- Same for Local, when it has 192.168.50.5/24 address on its WG interface, it creates dynamic route for 192.168.50.0/24, so manual ones for 192.168.50.x/32 are useless.

Otherwise it's ok. The first part, I mean. But the following one... why? What is your thought process? What gave you an idea that this could be something good?

wg-evilconfig.png

Subnet 10.10.10.0/24 is behind Peer3, the whole thing, all addresses from .0 to .255, even if you currently don't use all of them, they simply don't belong anywhere else.

Correct config is route on Local router (dst-address=10.10.10.0/24 gateway=192.168.50.2/<WG interface>), it's simple and everything works correctly.

You replaced this route by IP address 10.10.10.10/24 on Local router. How is it better? Yes, if it's WG (not ethernet), it will work if some device from Local LAN communicates with some device in Peer3's LAN (e.g. Server 10.10.10.100). But if Local router itself also wants to communicate with Server, it won't work, because it will choose 10.10.10.10 as source (because it thinks that Server is connected directly to its WG interface) and Server won't be able to respond, because this address is supposed to be in Peer3's LAN (both Server's and Peer3's routes say it is there).

So you changed perfectly good working config, by which you gained nothing, but you broke something. Why do you think it's good idea? Because it clearly isn't.

@mducharme: I'm going to say yes, but just between us, don't tell @anav, I wouldn't bet my life on it. I didn't do much with it before, I did lot of testing now, and assuming that I didn't make some horrible mistake, it's as described. If it's IPv6 and there's no non-link-local address on WG interface, it chooses another one. IPv4 doesn't, even logging ICMP in output doesn't show anything.

mducharme · Thu Mar 17, 2022 3:01 am

If it's IPv6 and there's no non-link-local address on WG interface, it chooses another one. IPv4 doesn't, even logging ICMP in output doesn't show anything.

Interesting - thanks. It is good to know the behaviour anyway. I wonder if this is something MikroTik specific, or if this same thing occurs on regular Linux with a similar configuration?

anav · Thu Mar 17, 2022 3:39 am

I see your point Sob, I hadnt thought of the consequences of the traffic flow in the opposite direction. The traffic may reach the server but the response will never make it back.
Not to worry wont actually config like that just wanted to see why not.......... what broke etc......

Sob · Thu Mar 17, 2022 4:05 am

@mducharme: Quick test with Linux and WG has different result, IPv4 works the same as IPv6, if there's no address on interface, it chooses another one from elsewhere. I expect it's probably configurable somewhere, but so far I didn't find any info about it. Edit: there's a difference between ROS v6 and v7, the former also selects another address (tested with IPIP, because it doesn't have WG), but v7 doesn't.

@anav: It may take a while before I believe you.

anav · Thu Mar 17, 2022 4:13 am

Depends if I really want to look at your latest diagram or not.............

mducharme · Thu Mar 17, 2022 4:47 am

@mducharme: Quick test with Linux and WG has different result, IPv4 works the same as IPv6, if there's no address on interface, it chooses another one from elsewhere. I expect it's probably configurable somewhere, but so far I didn't find any info about it. Edit: there's a difference between ROS v6 and v7, the former also selects another address (tested with IPIP, because it doesn't have WG), but v7 doesn't.

Interesting - this behaviour then can probably be described as a bug in the network stack of RouterOS v7. It is probably worth reporting.

mozerd · Thu Mar 17, 2022 7:10 pm

What a shame that MikroTik did not integrate WireGuard completely—- by taking advantage of every aspect provided by its creator. Every Linux disto that includes WireGuard takes complete advantage of the Donenfeld creation except RoS. Yes, the Donenfeld wg tools that for example effectively generate routes automatically ….

Sob · Thu Mar 17, 2022 7:26 pm

I don't think you exactly know what you're talking about. RouterOS has everything except high level tool that processes WG config file. Same way RouterOS doesn't take standard OpenVPN config files. But you don't need that, the config is just entered differently, there's nothing missing (for WG, OpenVPN in RouterOS is missing some features).

Edit: They could perhaps add an option to automatically create routes from peers' allowed-address, it wouldn't be universal thing, but it could help someone. I personally think it's not too important, but maybe...

anav · Thu Mar 17, 2022 9:15 pm

I don't think you exactly know what you're talking about. RouterOS has everything except high level tool that processes WG config file. Same way RouterOS doesn't take standard OpenVPN config files. But you don't need that, the config is just entered differently, there's nothing missing (for WG, OpenVPN in RouterOS is missing some features).

Edit: They could perhaps add an option to automatically create routes from peers' allowed-address, it wouldn't be universal thing, but it could help someone. I personally think it's not too important, but maybe...

Im putting this on a poster"

SOB SAYS "They could add an option to automatically create routes from peers' allowed-address" to MIMIC the Donenfield Creation.

)))))

Let me counter Mozerd, by stating, that wanton MASS ip route creation from Allowed IPs, is not as bad as MASS MURDER, but it is a minefield of problems in the hands of the beginner. It may work on a very simple configuration (like a single smart device) but I am thinking it may get less and less useful as the number of peers and multiple addresses within a peer start adding up.

In any case, my concerns may be groundless, especially seeing its wide use in many other linux based programs, but AS LONG AS I dont have to create an IP address for the Wireguard Interface to create such Routes, both SOB and I will be like two pigs playing in the mud!!

Thu Mar 17, 2022 9:26 pm

... both SOB and I will be like two pigs playing in the mud!!

...which is the part you also need to add things WILL get dirty.

Sob · Thu Mar 17, 2022 9:37 pm

@anav: Don't get overexcited, the word is routes, not your "original invention" with addresses.

And on one hand, why not, if you have just some simple config where allowed addresses are the same as you want to route, it could be useful shortcut (something like /interface/wireguard/peers/add <other options> allowed-address=10.0.0.0/8 add-routes=yes, and it would create dynamic route to 10.0.0.0/8).

Other clients like wg-quick have it as default behaviour, but even there it's not hardcoded, you can optionally turn it off, or choose other than main routing table. RouterOS has slightly different and more flexible approach, it lets you add required routes manually, with whatever properties you need, different routing tables, distances (you could have e.g. two WG tunnels as failover), anything you like.

I understand how at first sight WG in RouterOS may seem complicated when you're used to something else. Other clients just take one config file, where everything is together, keys, peers, addresses, routes, and then you just run one magic command and it configures everything. In RouterOS you have to enter these things in several different places. But you can't compare this with running the magic command, the thing you should compare it to is writing the config file. And there's not much difference there.

anav · Mon Mar 21, 2022 2:36 pm

A different thread has my interest
in terms of having multiple peers on the same interface and with a coordinated Wireguard Interface subnet.

Chap has an MT device behind CGNAT, behind the MT he has an IP camera he wants to access. He has a VPS server (unbuntu) that can run wireguard and he plans on connecting the MT to the VPS. He currently accesses the vps server via laptop or smart phone.

[ Discussion but not what I want to explore in any depth - The part I didnt get was his part about port forwarding traffic from the VPS to the MT over wireguard. I missed the fact that his plan was NOT to wireguard into the VPS from mobile devices (laptop or smartphone). Does this mean that most people access their VPS server without VPN ?? ]

Where I want to go, is a full wireguard end to end connection from mobile device to IP camera.
Is there only option A, or will option B also work and if so how?

A. (two wg interfaces at VPS) --> have the remote mobile devices come in to vps on one tunnel and then use a second tunnel between the VPS and MT
B. (one wg interface at VPS) --> have all devices on the same wireguard interface................... this seems the most efficient BUT how would this actually work.......... Could a mobile laptop connect directly to the MT or is what mozerd indicates a clue to NO WAY (wg is only peer to peer, not peer to multi-peer) ?

A. is clean to me. I can visualize what goes on with the traffic.........
Traffic from remote mobile device arrives at VPS via wg, exits the tunnel.
Firewall rules allow this traffic to reach second tunnel
IP route directs this traffic to second tunnel
I just have to make sure the return path also exists............. not to hard.

B. NOT A FRIGGEN CLUE.

++++++++++++++++++++++++++

mkx · Mon Mar 21, 2022 3:10 pm

... or is what mozerd indicates a clue to NO WAY (wg is only peer to peer, not peer to multi-peer)

That's not what @mozerd is barking at.

The real difference between client-server and peer-peer is that in client-server there's sever listening for connections and it's always client that initiates the connection. In peer-peer both parties are listening for connections and any of them can initiate the connection.
And this doesn't say anything about peer-multipeer ... one would have to test, but I guess for the peer-peer part, peer-multipeer is exactly the same.

As to the claim that @mozerd is making real loud ... that wireguard is not client-server. Well, it can be. It is possible to configure WG in peers section without endpoint-address ... in this case local end-point "downgrades" into server because it doesn't know how to initiate the connection, it has to wait for remote peer to establish the connection (which makes remote peer a client).

But after the tunnel is up&running (which is kinda moot with UDP being used as "back-end" transport protocol), there's no difference between client-server and peer-peer topology ... the tunnel is open and traffic flows both ways.

This post doesn't answer to question by @anav, however: it seems like peers, configured via same WG interface, can not communicate directly (which is the way I'd want it done, a hub has to have control over what traffic passes any of links), all packets arriving from WG peers have to exit the WG interface and then it's up to L3 mechanisms to deal with packets (and optionally push them back to WG interface where crypto-routing takes over). In this regard, it's similar to using multiple WG interfaces. My explanation is based on this article (similar question, working solution clarifies a lot).

anav · Mon Mar 21, 2022 3:25 pm

Okay mkx, I thought that was indeed the case where one needs two distinct tunnels to RELAY traffic in this way and that having all the peers on the same WG interface IS NOT capable of relay.

Good to know!.

So why is the chap doing port forwarding from VPS to MT device? Is it because most people https into the VPS device ( then user name and password) and that is good enough for security??

Sob · Mon Mar 21, 2022 3:55 pm

One tunnel is enough:

Server:
- IP 192.168.0.1/24
- Camera peer, allowed IPs 192.168.0.10/32
- Dstnat to 192.168.0.10 (for public access without WG)
- Client peer, allowed IPs 192.168.0.20/32

Camera:
- IP 192.168.0.10/24
- Server peer, allowed IPs 0.0.0.0/0 (to cover access from internet)
- Alternative default route via WG (for access from internet)

Client:
- IP 192.168.0.20/24
- Server peer, allowed IPs IP 192.168.0.0/24

mozerd · Mon Mar 21, 2022 3:56 pm

Everyone is a peer

The Author is Vladimír Záhradník .... my type of tech guy

-------------------------------------------------------

In WireGuard, there is no client-server relationship. WireGuard introduces a concept of peers, which are interconnected clients, and by definition, there is no superior or inferior peer.

To establish connectivity, you need to ensure the following:

- On each peer, create a WireGuard interface and assign an IP address to it with the ip tool. It’s an address inside a VPN network bound to the peer forever

- On each peer generate a private key using the wg tool and assign it to the WireGuard interface

- Derive a public key, again with the wg tool, and add it to all other peers you want to communicate. WireGuard doesn’t specify how to exchange the keys. I opened an SSH session on each device and copied them over manually

- Optionally, tell each peer how to reach other peers by specifying a public IP (or domain) and a port. Not all peers need to know how to reach others, as long as others know how to reach them; you’ll see later

-------------------------------------------------------

Sob · Mon Mar 21, 2022 4:04 pm

@mozerd: The part you keep missing is that while WG may be peer-to-peer "at heart", if you have peer behind NAT and it can't accept incoming connections, such peer is clearly limited. If you're going to have all such peers, it won't work at all, because they won't be able to connect to each other (without some additional tricks like e.g. your favourite Tailscale does). And if you're going to have exactly one that can accept incoming connections and all others will be connecting to it, it's clearly client-server behaviour.

mozerd · Mon Mar 21, 2022 4:23 pm

@mozerd: The part you keep missing is that while WG may be peer-to-peer "at heart", ............
it's clearly client-server behaviour.

@Sob ... I believe you are brilliant .... as is mkx .... and anav is very smart

If its Pure WG Lets not call it C/S .... lets call it a communication relay

....
behave like a server Peer relaying to a client Peer ...
certainly looks like C/S but its still WG-PeerA to WG-PeerC to WG-PeerB ...

Yep, Your One Tunnel is enough is right on the money .... very nice 4sure

anav · Mon Mar 21, 2022 5:08 pm

One tunnel is enough:

Okay I will bite, but will try to explain it so that is understandable vice sob cryptic short form!
Also will ignore the public access dstnat bit, as the MT is behind another router and cannot forward ports ;-P
oops I see you mean the Dst NAT at the VPS............. okay I get it....... but will leave that till the end, it confuses my train of thought LOL

VPS server wg port 12122, fixed IP 24.233.45.15

Step1: create wireguard coordinated subnet
VPS linuxspeak=192.168.0.1/24 interface=wg0
MT IP address=192.168.0.10/24 interface=wg-MT { camera resides off this device Ip address local is 10.10.10.50/32 }
Laptop Address=192.168.0.20/32

Requirement: Laptop to reach camera via Wireguard.

Solution (so sob says):

Wireguard at Mobile Laptop
Allowed IPs=192.168.0.0/24 { allows one to ping both VPS server and MT remote client }, 10.10.10.50/32 { camera IP destination address (at MT device) }
[Note: if internet access was involved the only allowed IP required would be 0.0.0.0/0]

Wireguard settings at VPS
Peer MT Allowed IPs - 192.168.0.10/32 { allows pinging from MT },
Peer Laptop Allowed IPs - 192.168.0.20/32 { allows pinging and all incoming traffic from laptop }

Wireguard settings at MT (camera)
Peer Server Allowed IPs - 192.168.0.1/32 { allows pinging from Server }, 192.168.0.20/32 {allows traffic from laptop to exit tunnel at MT }

IP Routes.
MT DEVICE
(dac) dst-address=192.168.0.0/24 gwy=wg-MT table=main ( allows outbound pinging to VPS server and return pings from VPS or laptop)
dst=address=192.168.0.20 gwy=wg-MT table=main NOT REQUIRED (return traffic from camera covered by DAC rule???? ***

VPS SERVER
(dac) 192.168.0.0/24 gwy=wg-MT table=main ( allows outbound pinging to MT and returning pings from MT or laptop )
*** similarly return traffic from MT to laptop moves transparently through VPS due to the DAC rule.????

++++++++++++++++++++++++++++++++++++++++++++++

With only WG to the MT camera and only an external connection from LAPTOP to VPS, then at the VPS we would have to do some dstnat like work.
Since I dont know linux I will couch it in MT forms..
But this is really good for learning too --> HOW TO PORT FORWARD THRU a wg tunnel.

add chain=dstnat action=dst-nat in-interface=?? WAN or dst-address=fixed IP of VPS wan connection??
protocol=whatever dst-port=actual cameraport? to-addresses=actual camera local IP or IP of MT wireguard??

Sob · Mon Mar 21, 2022 6:22 pm

If you want direct access to camera's internal address, then you need 10.10.10.50/32 also here:

Wireguard settings at VPS
Peer MT Allowed IPs - 192.168.0.10/32 { allows pinging from MT },

And server must also have route to 10.10.10.50/32. Then it's better to have whole 192.168.0.0/24 as allowed here:

Wireguard settings at MT (camera)
Peer Server Allowed IPs - 192.168.0.1/32 { allows pinging from Server }, 192.168.0.20/32 {allows traffic from laptop to exit tunnel at MT }

Because if you add another client, you won't need to touch it. And here:

(dac) dst-address=192.168.0.0/24 gwy=wg-MT table=main ( allows outbound pinging to VPS server and return pings from VPS or laptop)
dst=address=192.168.0.20 gwy=wg-MT table=main NOT REQUIRED (return traffic from camera covered by DAC rule???? ***

If you have (dynamic) route to 192.168.0.0/24, you don't need another route to 192.168.0.20, because the first one includes it. Go play a bit with subnet calculator.

add chain=dstnat action=dst-nat in-interface=?? WAN or dst-address=fixed IP of VPS wan connection??
protocol=whatever dst-port=actual cameraport? to-addresses=actual camera local IP or IP of MT wireguard??

It's simple port forwarding like any other, on server you'll have dst-address=<public address of VPS> and to-addresses can be both 10.10.10.50 and 192.168.0.10. If it's the latter, then you'll need additional dstnat on camera's MT.

anav · Mon Mar 21, 2022 6:38 pm

[quote=Sob post_id=920437 time=1647879773 user_id=33312]
If you want direct access to camera's internal address, then you need 10.10.10.50/32 also here
[quote=anav post_id=920417 time=1647875296 user_id=115581]
Wireguard settings at VPS
Peer MT Allowed IPs - 192.168.0.10/32 { allows pinging from MT }, [/quote]

WHY? ---> Because in a relay scenario, within the same interface, one MUST still view the traffic from Laptop. after arriving at VPS WG interface, as requiring a valid destination address, for the next leg, although never exiting the wireguard interface? (aka 10.10.10.50/32 is checked as a valid destination address for selection outbound at VPS just as it was for the laptop itself??).

Note that this is exactly what one would do if it were for a separate tunnel (second wireguard interface).

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

anav · Mon Mar 21, 2022 6:40 pm

Because if you add another client, you won't need to touch it. And here:

(dac) dst-address=192.168.0.0/24 gwy=wg-MT table=main ( allows outbound pinging to VPS server and return pings from VPS or laptop)
dst=address=192.168.0.20 gwy=wg-MT table=main NOT REQUIRED (return traffic from camera covered by DAC rule???? ***
If you have (dynamic) route to 192.168.0.0/24, you don't need another route to 192.168.0.20, because the first one includes it. Go play a bit with subnet calculator.

This I understand, makes sense,,,,,,,,, and hence why I stated not required and future proofing yes!

anav · Mon Mar 21, 2022 6:46 pm

And server must also have route to 10.10.10.50/32. Then it's better to have whole 192.168.0.0/24 as allowed here:

This is the one thing I didnt understand!!

Why does the VPS server need a route to 10.10.10.50/32.
IF all the traffic is remaining within wireguard and not exiting the tunnel at VPS, and we are not using a second tunnel.......................

OR ARE YOU REALLY SAYING, yes the traffic has to EXIT THE TUNNEL and then RENTER the tunnel ???
in which case this would make more sense............
It would act at a way to get traffic to the mT for traffic exiting the tunnel at VPS that came from laptop
dst-address=10.10.10.50/32 gwy=wg0

Not sure if you meant to somehow associate this with 192.168.0.0/24 above??

anav · Mon Mar 21, 2022 6:53 pm

add chain=dstnat action=dst-nat in-interface=?? WAN or dst-address=fixed IP of VPS wan connection??
protocol=whatever dst-port=actual cameraport? to-addresses=actual camera local IP or IP of MT wireguard??
It's simple port forwarding like any other, on server you'll have dst-address=<public address of VPS> and to-addresses can be both 10.10.10.50 and 192.168.0.10. If it's the latter, then you'll need additional dstnat on camera's MT.

Why? I see the port forward from VPS into wireguard, but NOT ON the MT.
This seems right! ( assuming its still the laptop requesting the information from the camera and the op still manages to use the same Ip address .20 - not sure how )
VPS Server
add chain=dstnat action=dst-nat dst-address=publicIP-VPS to-address=192.168.0.10
MT
add chain=forward action=accept in-interface=wg-MT source-address=192.168.0.20/32 dst-address=10.10.10.50/32

Sob · Mon Mar 21, 2022 8:39 pm

You can have either what I posted, with only WG subnet (192.168.0.0/24) and anything else behind any peer (your 10.10.10.50) must be handled using srcnat/dstnat, so WG won't see it. Or if you want to avoid NAT (generally good idea), then it would be:

Server:
- WG IP 192.168.0.1/24
- Camera peer, allowed IPs 192.168.0.10/32, 10.10.10.50/32
- Route to 10.10.10.50
- Dstnat to 10.10.10.50 (for public access without WG)
- Client peer, allowed IPs 192.168.0.20/32

Camera:
- WG IP 192.168.0.10/24
- LAN IP 10.10.10.1/24
- Camera IP 10.10.10.50/24
- Server peer, allowed IPs 0.0.0.0/0 (to cover access from internet; otherwise 192.168.0.0/24 for WG-only access)
- Alternative default route via WG (for access from internet)

Client:
- WG IP 192.168.0.20/24
- Server peer, allowed IPs IP 192.168.0.0/24, 10.10.10.50/32
- Route to 10.10.10.50 (if client is MT, otherwise added automatically by wg-quick and others)

It's simple routing and WG's allowed IPs reflect what can be routed.

OR ARE YOU REALLY SAYING, yes the traffic has to EXIT THE TUNNEL and then RENTER the tunnel ???

I'm saying that traffic from client to camera (or back) will have in-interface=WG out-interface=WG on server.

anav · Mon Mar 21, 2022 9:20 pm

Why do you give the client (mobile device lets say ipad or laptop windows etc) a Wiregurd Address of 192.68.20.20/24 and not 192.168.0.20/32

Its just a single device??
I thought that a full /24 was to be used for Devices that have the capacity for multiple subnets for example.

anav · Mon Mar 21, 2022 9:26 pm

OR ARE YOU REALLY SAYING, yes the traffic has to EXIT THE TUNNEL and then RENTER the tunnel ???
I'm saying that traffic from client to camera (or back) will have in-interface=WG out-interface=WG on server.

More importantly are you saying that at the MT DEVICE (client) and where the server is found, that it has two peers in its Wireguard Settings

peer1 = server
peer2 =mobile client (this would be impossible unless it is okay for the exchange of public keys will make this work!! ??????????? THIS IS THE LINK I HAVE BEEN MSSING!!!
arrgg makes no sense cannot have peer to peer like this both are clients my bad..............
okay my original thoughts were correct you verbalized them differently as usual LOL

anav · Mon Mar 21, 2022 10:24 pm

Another riddle, to help me understand firewall rule required at the VPS Serer, what if the VPS server was an MT device,
Assuming drop rules, would you need any firewall rules for the relay of mobile client traffic from laptop to MT server to MTClient (camera)

If it was two separate wg interfaces it would be clear to me how to apply firewall rules to relay........
add chain=forward action=accept in-interface=wg1 out-interface=wg2 src-address=mobile client IP.

So what you are saying is that at the VPS linux if it was an MT device would need something like this that looks almost SILLY. (as interfaces are the same)

add chain=forward action=accept in-interface=wg0 out-interface=wg0 src-address=mobile client IP ???????????

anav · Mon Mar 21, 2022 10:48 pm

So in the end, to have a relay function is perfectly reasonable by only using ONE WG interface.
This works as long as we realize that each peer to peer connection is separate and that traffic that arrives from one end to an MT RELAY device, is considered now LOCAL and thus why

a. We need a firewall rule as bizarre as it seems at the RELAY device, to ensure traffic then re-enters the tunnel for the next leg.
add chain=forward action=accept in-interface=wg-name out-interface=wg-name src-address=mobile client.

b. We need an IP route for the destination traffic (like the allowed IP on the mobile client which matched and selected traffic outbound from the user at the mobile client) and this traffic is now local to the RELAY device, and thus has to go through the same process/configuration --> to match and select 'local' traffic we have to include the destination address in

i; allowed IPs for the Relay device (allocated to the peer where we are relaying the traffic too)
ii; create an IP route for that traffic (for destination IP to enter WG interface)

Sob · Mon Mar 21, 2022 10:49 pm

IP address 192.168.0.20/24 gives client connected route to whole 192.168.0.0/24 subnet, i.e. all 192.168.0.x addresses. So it knows where to find server (.1), camera's WG client (.10), even some future cameras (.11, .12, ...), etc. It's WG subnet and if it's /24, then all devices should (in most cases) have IP addresses with /24. It's slightly different for allowed IPs, server/VPS should have 192.168.0.x/32 for each peer, because they each have only one IP address from this subnet and have no reason to use others. But clients should have 192.168.0.0/24, because server can relay to them traffic from all other peers, so it needs to be allowed.

And yes, on server/VPS, traffic between peers will match in-interface=wg0 out-interface=wg0, there's nothing wrong with that, that's what happens, both incoming and outgoing interface is WG.

anav · Mon Mar 21, 2022 11:19 pm

IP address 192.168.0.20/24 gives client connected route to whole 192.168.0.0/24 subnet, i.e. all 192.168.0.x addresses. So it knows where to find server (.1), camera's WG client (.10), even some future cameras (.11, .12, ...), etc. It's WG subnet and if it's /24, then all devices should (in most cases) have IP addresses with /24. It's slightly different for allowed IPs, server/VPS should have 192.168.0.x/32 for each peer, because they each have only one IP address from this subnet and have no reason to use others. But clients should have 192.168.0.0/24, because server can relay to them traffic from all other peers, so it needs to be allowed.

And yes, on server/VPS, traffic between peers will match in-interface=wg0 out-interface=wg0, there's nothing wrong with that, that's what happens, both incoming and outgoing interface is WG.

Got it, understood, where required the allowed IPs needs to be specific but the iP address need not be fixed for mobile clients that have ADDRESS assigned within the Wireguard parameters.
As for the other issue SAME interface at the Relay device in the firewall rule makes sense.
It mirrors a solution I had proposed for a similar relay but using TWO wireguard interfaces.
The key is that each connection is peer to peer so at the relay site, the traffic should be considered having exited the tunnel and now needs a route and firewall permission to rententer the next tunnel.
hence why allowed IP at originating mobile client (aka the destination IP) is then added to the end client device in its peer settings at the relay device, and why also at the relay device one needs to create a route for that destination IP with the applicable wg interface gateway.

What is really cool is the sense that the one tunnel solution is more efficient because this rule works for both directions!
in-interface=wg0 out-interface=wg0 src-address=192.168.0.20/32

whereas in my dual tunnel Relay example (iphone to relay device, out different tunnel (aka 3rd party VPN provider) I need two firewall rules at the MT RElay device.
one to allow iphone to 3rd party VPN, one to allow response from 3rd party VPN to iphone
in-interface=wg-local1 out-interface=wg-local2 src-address=IPof IPhone
in-interface=wg-local2 out-interface=wg-local2 src-address=IPof IPhone

Sob · Tue Mar 22, 2022 12:15 am

What is really cool is the sense that the one tunnel solution is more efficient because this rule works for both directions!
in-interface=wg0 out-interface=wg0 src-address=192.168.0.20/32

Until you realize that this rule with all three conditions makes sense for only one direction, then it becomes less cool.

anav · Tue Mar 22, 2022 1:08 am

What is really cool is the sense that the one tunnel solution is more efficient because this rule works for both directions!
in-interface=wg0 out-interface=wg0 src-address=192.168.0.20/32
Until you realize that this rule with all three conditions makes sense for only one direction, then it becomes less cool.

Dont follow you at all......

Traffic all the way along has one source address, that of the mobile client (be it iphone or laptop).
so that part of the rule is fine......... if there was another mobile client involved, then
you would create a source address list at the RELAY Device,,,,,,,,,,,,,,,,,

Return traffic to the mobile client (ipad, laptop) after hitting the camera server at the MT client end,,,,,,,,,,, hits the RELAY device at the same wireguard interface!!

Therefore the rule is valid in both directions........... it will come out the interface, it will have destination traffic for mobile client, the IP route for the mobile client on the SERVER will see that it has to go to the wg interface, the firewall rule will allow it and the return traffic will get peer matched and selected to the mobile client and be on its merry way.

Where is the issue...............

Sob · Tue Mar 22, 2022 2:36 pm

Don't overthink it.

If you say "works for both directions", I'd expect that device A can initiate connections to device B, and also device B can initiate connection to device A. So .20->.10 and .10->20. And it would be true if you had only in/out-interface=wg0. But if there's also src-address=192.168.0.20/32, then it allows connections only from .20.

anav · Tue Mar 22, 2022 2:46 pm

Don't overthink it. If you say "works for both directions", I'd expect that device A can initiate connections to device B, and also device B can initiate connection to device A. So .20->.10 and .10->20. And it would be true if you had only in/out-interface=wg0. But if there's also src-address=192.168.0.20/32, then it allows connections only from .20.

Your nitpickyness is annoying and sometime infuriating ( I swear you are trying to give me an ulcer - then i realized sometimes I am as vague LOL but not out of spite, or lazyness but because I dont know any better ;-PP) I didnt mean to imply it works both ways for ALL traffic, but ONLY for the finite example I was discussing, which was a mobile laptop remote client accessing a camera server hosted on a remote MT client, both with WG to the VPS server (RELAY device). Clearly this traffic retains its source IP as 192.168.0.20/32 during its phucking travels.......
Thus in-interface=wg0 out-interface=wg0 src-address=192.168.0.20/32 is VALID if the traffic pops out of the tunnel at the RELAY device from either the originating mobile client or the return traffic pops out of the tunnel at the RELAY device from the MT client.....

My comment was, simply how convenient compared to the other example where I use two separate wireguard interfaces and then one needs two separate firewall rules at the SERVER.

To make you happy, then simply dont use a source address with that rule and then any traffic coming out of the tunnel can go back in the tunnel in terms of firewall scrutiny and then it would be truly two way for all. I suppose the IP routes and allowed IPs (routing squared) would be enough to direct the traffic correctly but I prefer to use the firewall for its intended purpose (impose admin control and limit traffic to only that which is required).

In any case I have adjusted the main article text based on your input/minor almost trivial concerns and at some point will get to the examples.

mkx · Tue Mar 22, 2022 3:49 pm

My comment was, simply how convenient compared to the other example where I use two separate wireguard interfaces and then one needs two separate firewall rules at the SERVER.

Well, you don't have to have two separate firewall rules if you have two WG interfaces ... just create interface list and use that in FW rule ...

anav · Tue Mar 22, 2022 3:54 pm

My comment was, simply how convenient compared to the other example where I use two separate wireguard interfaces and then one needs two separate firewall rules at the SERVER.

Well, you don't have to have two separate firewall rules if you have two WG interfaces ... just create interface list and use that in FW rule ...

That is another option of course........... Which I believe I had already mentioned in a previous post but a reminder is always nice!
However what you say is valid for the SAME WG interface, not two distinct wg interfaces unless you go ALL in with the following LOL

Unless you mean
add chain=forward in-interface-list=WG-interfaceS out-interface-list=WG-interfaceS source-address-list=MultipleSources ( catches all )

Sob · Tue Mar 22, 2022 9:03 pm

Your nitpickyness is annoying and sometime infuriating ...

Few things about that:

- Sometimes it's fully intentional. You're all about tough love for users, so no exceptions for you. And I admit that sometimes I enjoy it a lot.
- Sometimes it's because I'm not sure if something you wrote incorrectly is honest mistake and you know what's right, or you actually meant that. So I'm just trying to make sure that we understand each other.
- Sometimes it's me misunderstanding something. That's this case, now I see what you meant. My excuse is that English is not my native language, I can't even say with absolute certainty if I can't read or you can't write.

anav · Wed Mar 23, 2022 3:57 pm

Your nitpickyness is annoying and sometime infuriating ...
Few things about that:

- Sometimes it's fully intentional. You're all about tough love for users, so no exceptions for you. And I admit that sometimes I enjoy it a lot.
- Sometimes it's because I'm not sure if something you wrote incorrectly is honest mistake and you know what's right, or you actually meant that. So I'm just trying to make sure that we understand each other.
- Sometimes it's me misunderstanding something. That's this case, now I see what you meant. My excuse is that English is not my native language, I can't even say with absolute certainty if I can't read or you can't write.

You hit the nail on the head, tough love, or better tough instructing. The more accurate and clear I am the quieter you are! Why dont I seem to learn that lesson LOL.

All good info when I get to the examples, I keep tweaking the article so do pop in from time to time to let me know anything else that bugs you...........

Who is online