At a minimum you need
dst-address=192.168.99.0/24 gwy=wireguard1 table=main

/ip address
add address=192.168.99.1/24 interface=wireguard1 network=192.168.99.0

You can't have same allowed-address=192.168.99.0/24 for multiple peers on same interface, it should be allowed-address=192.168.99.X/32 (where X is what that peer has).

The other issue could be routes.......
WHERE ARE THEY??
At a minimum you need
dst-address=192.168.99.0/24 gwy=wireguard1 table=main

[admin@home_CRS305] > /ip/route/print 
Flags: D - DYNAMIC; A - ACTIVE; c, d, y - COPY
Columns: DST-ADDRESS, GATEWAY, DISTANCE
    DST-ADDRESS      GATEWAY       DISTANCE
DAd 0.0.0.0/0        1.2.3.4         1
DAc 10.10.10.0/24    bridge-infra         0
DAc 79.175.228.0/22  ether1-wan           0
DAc 172.16.10.0/24   bridge-guest         0
DAc 172.31.100.0/24  bridge-iot           0
DAc 192.168.88.0/24  bridge-home          0
DAc 192.168.99.0/24  wireguard1           0

This also looks suspect:
add action=masquerade chain=srcnat comment="WireGuard -> Internet" \
out-interface=ether1-wan src-address=192.168.99.0/24

There is no need to masquerade traffic coming from your iphone out to the internet??
I suppose it cannot hurt but not sure what you accomplish with it???
UNLESS your MT is behind another Router like an ISP router where you cannot create a static route??
Assuming if true, then at least you can forward ports otherwise the MT couldnt be an MT wg server.

note1; This is not best security practices, not recommended to use plain text services
/ip service
set telnet address=192.168.88.0/24
set ftp address=192.168.88.0/24
set www port=81

note2: this does not look like a legitimate rule as if it was for the establishment of an encrypted connection (VPN) it would be input chain
if it was for port forwarding to a server it would be in the dst nat chain.
add action=accept chain=forward dst-port=443 in-interface=ether1-wan \
log-prefix="fw-log -> " protocol=tcp

Neglecting the ip address everyone is using, even himself on iPhone, I guess ?

Neglecting the ip address everyone is using, even himself on iPhone, I guess ?

How come?

So many topics/issues tagged with WireGuard that have nothing to do with WireGuard.

How come?

Running joke/discussion around here between anav and Sob.
anav seems to be amongst the very few (if not the only one) insisting on NOT using internal IP addresses on WG-endpoints (which BTW DOES work without on Mikrotik to Mikrotik connections, no discussion there. But it's mighty confusing for most people).
But for the connection from his iPhone he has to or it will not work.

... using networks seems to be more flexible configuration for many clients when i do not care about specific IP

... which BTW DOES work without on Mikrotik to Mikrotik connections ...

... which BTW DOES work without on Mikrotik to Mikrotik connections ...

You can do the same with Linux, but why would anyone do it?

The catch is that when you have multiple peers connected to same interface, router must use something to determine what should it send to which client.

The catch is that when you have multiple peers connected to same interface, router must use something to determine what should it send to which client.

Well, each peer have unique set of keys which are not shared across other peers so why it can't be used?
They are used in logs for identifying peers

But i guess that's MT implementation, so I'll roll with it.

https://www.procustodibus.com/blog/2021/01/same-key-multiple-peers

WireGuard, in fact, uses a peer’s public key as the lookup key in its internal table of connected peers; when sending encrypted traffic to a peer, WireGuard consults this table to determine the public IP address and port (aka endpoint) to which it should send the encrypted traffic.

I wonder if thats talking about the initial handshake. That sounds like wAy to much overhead for every traffic packet.

I wonder if thats talking about the initial handshake. That sounds like wAy to much overhead for every traffic packet.

The way I see it:
Every packet is being encrypted, send over the interface and decrypted on the other side.
Otherwise it's not a secured tunnel anymore.
So it's not that much overhead at all since those keys need to be used already, an intelligent lookup can be blazing fast.
Heck, that's a trick from the old computer days to store some tables simply in ROM to use as lookup (one cycle) instead of calculating the result (multitude of cycles).

The way I see it:
Every packet is being encrypted, send over the interface and decrypted on the other side.
Otherwise it's not a secured tunnel anymore.
So it's not that much overhead at all since those keys need to be used already, an intelligent lookup can be blazing fast.
Heck, that's a trick from the old computer days to store some tables simply in ROM to use as lookup (one cycle) instead of calculating the result (multitude of cycles).

The virtual tunnel interface is based on a proposed fundamental principle of secure tunnels: an association between a peer public key and a tunnel source IP address. It uses a single round trip key exchange, based on NoiseIK, and handles all session creation transparently to the user using a novel timer state machine mechanism. Short pre-shared static keys—Curve25519 points—are used for mutual authentication in the style of OpenSSH.

The protocol provides strong perfect forward secrecy in addition to a high degree of identity hiding. Transport speed is accomplished using ChaCha20Poly1305 authenticated-encryption for encapsulation of packets in UDP.

The overall design allows for allocating no resources in response to received packets, and from a systems perspective, there are multiple interesting Linux implementation techniques for queues and parallelism.

If i understand it correctly WireGuard already uses unique keys for distinguish individual clients instead of IPs itself