Working with l2tp server, each remote site building a tunnel creates an l2tp interface I can route relative remote subnet through.
Using wireguard as "vpn server", there is a single WG interface (with its own ip address) to route all subnets to.
There are multiple peers (the remote sites) that, instead, are not interfaces and have no adresses neither.
I suppose the only way to decide where to route packets to correct subnet is using "Allowes Addresses" inside each peer.
Is it right ?
I also noted that the remote wireguard interface ip address (not the remote subnet) has to be declared into Allowed Addresses to avoid the mess of lost routing in connecting the remote RouterBoard.
Not quite, read up on it here.........
https://www.wireguard.com/
Every peer client for handshake does get an address, allowed address serves two functions and it always details either:
a. remote addresses that are being reached
OR
b. remote addresses coming into your router.
Allowed addresses is key to wireguard routing, which should be considered separate from the IP routes which still needs to be addressed in some cases ( typically when indicating to the router, where to send traffic for non-local subnets ).
You could get away without giving wireguard an address, but its much more complex to so.......and thus not advised.
AllowedIPs is simply a setting allowing routing the subnets enabled to the Peer.
AllowedIPs is only used for egress traffic. Of course, if you want to route back the traffic coming, you’ll have to add the IP of your Peer in order to route through this peer.
RouterOS does not log the error when trying to route trafic through a tunnel with a subnet not enabled in AllowedIPs, but for example in Linux you’ll have the error “Invalid Key” or something similar.
In client implementation, like Windows or macOS, AllowedIPs is also used to create routes dynamically on the host,
@EmanK, why do you post clearly inaccurate statements?? Perhaps you should read or reread the reference above!
Allowed address handles both egress of packets and ingress of packets.
Crypto Wireguard Routing consists of two routing processes
a. incoming traffic ( originated at the remote end ), where the wireguard protocol does a filtering process on the incoming traffic to ensure its on the list of allowed addresses from that peer. Local firewall rules determine where that traffic is allowed to go.
b. outgoing traffic (originated at the local end), where the wireguard protocol does a filtering and matching which consists of determining if the destination address on the traffic matches any of the allowed addresses on the peers, starting from the top peer of that particular wireguard interface, and then matching that to the right peer for egress. Local firewall rules determine if the traffic can enter the tunnel and if routes are required, they are made so the router knows where to send the non-local traffic aka (via the wireguard interface, table=main).
PS, I still dont enough about wireguard to earn my wireguard avatar........... must have bought yours 