Hello everyone,

I know this topic has been covered many times but I still couldn't get it to work properly even reading many guides about it on the forum.

My problem is the migration from OpenVPN (fully functional) to Wireguard

I have configured a CHR with public ip and here I should connect all the clients which for the most part are ltAP LTE6.

All clients are able to ping the server but cannot connect to each other, furthermore the server cannot ping the various clients

is it a limitation of wireguard or do you need to perform a particular configuration?

I need to be able to trace the LANs of each client.

Thank you.

What you want to do is perfectly possible.

You may start with providing current config of CHR and one of the LTE devices.
/export hide-sensitive file=anynameyouwish
Review for public IP, serial number, passwords, ... and post contents separate per device between [code] quotes (easier to read for everyone).

A small drawing with the complete picture (esp. all used subnets) may also be needed (paper drawing can suffice if everything is clearly readable).
Also make clear how you want the connections to go. I assume server should be able to connect all LTEs but LTEs should not be able to connect other LTEs ?

What you want to do is perfectly possible.

You may start with providing current config of CHR and one of the LTE devices.
/export hide-sensitive file=anynameyouwish
Review for public IP, serial number, passwords, ... and post contents separate per device between [code] quotes (easier to read for everyone).

A small drawing with the complete picture (esp. all used subnets) may also be needed (paper drawing can suffice if everything is clearly readable).
Also make clear how you want the connections to go. I assume server should be able to connect all LTEs but LTEs should not be able to connect other LTEs ?

I'll have a look

IMPORTANT: REPOST EXPORTS WITHOUT PUBLIC KEYS !!

PS and please don't quote a complete post if nobody has answered in between. It's completely unnecessary.

On CHR:

Change this
/interface wireguard peers
add allowed-address=192.168.80.2/32 disabled=yes interface=wireguard1

To this:
/interface wireguard peers
add allowed-address=192.168.80.2/24, 192.168.10.1/24 disabled=no interface=wireguard1

Allowed addresses is what you want to .. allow to pass the tunnel.
As you had it now, you only allowed the internal IP address for the other end of the tunnel. Not the subnet connected to that device.
Changing that first part to /24, you will allow communication to all LTE device's Wireguard address (assuming they are all in that same subnet).
Adding the second subnet, will allow for communication towards the LAN devices on that LTE.
But, that's only going from CHR to LTE. If you want the other way as well, you need to do the same on LTE side (change allowed address to include subnet of CHR, or other LTE)

Next on CHR you will also need to add a route for 192.168.10.0/24 towards wireguard interface.

The problem is in firewall.

You have in firewall:
add action=drop chain=input in-interface-list=!LAN

Your wireguard interface is not added in interface list as LAN.

I deleted everything and recreated everything from the beginning by doing this:

CHR:

/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1

/interface wireguard peers
add allowed-address=192.168.10.1/24,192.168.80.2/24 interface=wireguard1 \
persistent-keepalive=35s public-key=\
"Public key of client"

/ip address
add address=192.168.80.1/24 interface=wireguard1 network=192.168.80.0

/ip route
add disabled=no dst-address=192.168.10.1/24 gateway=wireguard1

/ip firewall filter
add action=accept chain=input comment="Allow WireGuard" dst-port=13231 \
in-interface=ether1 log=yes log-prefix="[WIREGUARD] " protocol=udp
add action=accept chain=forward comment="Forward WireGuard" connection-state=\
established,related in-interface=wireguard1 log=yes log-prefix=\
"[WIREGUARD] "

/ip firewall nat
add action=masquerade chain=srcnat out-interface=wireguard1

ltAP LTE:

/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1

/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address=<chr public ip> endpoint-port=\
13231 interface=wireguard1 persistent-keepalive=35s public-key=\
"Public key of server"

/ip address
add address=192.168.80.2/24 interface=wireguard1 network=192.168.80.0

/ip firewall filter
add action=accept chain=input dst-port=13231 in-interface=lte1 protocol=udp
add action=accept chain=input dst-port=13231 in-interface=lte2 protocol=udp
add action=accept chain=forward in-interface=wireguard1

/ip firewall nat
add action=masquerade chain=srcnat out-interface=wireguard1

now it works so I think it was a problem of the "allowed-addresses" that I had not entered correctly

the average ping is 80ms practically identical to OpenVPN, shouldn't it be much lower?

The problem is in firewall.

You have in firewall:
add action=drop chain=input in-interface-list=!LAN

Your wireguard interface is not added in interface list as LAN.

yes i added wireguard to the LAN

the average ping is 80ms practically identical to OpenVPN, shouldn't it be much lower?

Depends on the underlying network as well and for LTE could be normal (I'm seeing ping times going to 200ms and more).
How is throughput ? That should be quite a bit higher then OVPN.
Don't test from device to device since you will distort the results of those devices doing the encryption/decryption AND running bandwidth tests.
Use a device (PC) before and after the chain you want to test.

yes I did the test from PC to PC

with OpenVPN the average is 110ms
with Wireguard the average is 80ms

average ping from LTE to Google DNS 60ms

I just have to do the network speed test and try to add all clients to evaluate the stability

after adding the second client everything timed out

I am attaching the configuration for checking

OK, my mistake.

On CHR

/interface wireguard peers
add allowed-address=192.168.10.1/24,192.168.80.2/24

That last one needs to be /32, for each of the peers. Otherwise it doesn't know where to go to when multiple peers are present.

CHR
(1) Allowed IPs from all other clients in regard to their wireguard addresses should be in form /32
/interface wireguard peers
add allowed-address=192.168.10.1/24,192.168.80.2/24 interface=wireguard1 \
public-key="client 1"
add allowed-address=192.168.178.1/24,192.168.80.3/24 interface=wireguard1 \
public-key="client 2"

(2) You need to indicate the subnet NOT the address for peers coming in or allowing local to reach remote subnets........
/interface wireguard peers SHOULD BE 192.168.10.0/24 and 192.168.178.0/24
add allowed-address=192.168.10.1/24,192.168.80.2/24 interface=wireguard1 \
public-key="client 1"
add allowed-address=192.168.178.1/24,192.168.80.3/24 interface=wireguard1 \
public-key="client 2"
/ip address

(3) Should simply have allow ICMP and forget all the noise is not only my thought but many others as well of these two, this one is more important.
Drop all the rest of the garbage rules is my recommendation as well, spent too much time on youtube...... A bloated mess.

(4) I note this route..... Again, it should be to the subnet NOT to the address aka 192.168.10.0/24
/ip route
add disabled=no dst-address=192.168.10.1/24 gateway=wireguard1 routing-table=\
main suppress-hw-offload=no

For discussion purposes, this is a good route for either of the two cases.
a. local traffic heading to this private IP address gets routed to the tunnel (local subnet to client subnet)
b. remote traffic from remote subnet which hit your local subnets or used local internet and needs a path back to the wireguard tunnel.
c. remote traffic from one client that when exits the tunnel at the CHR and is sitting on the router (parallel to the LAN subnets in a way) needs to go to the other wireguard client. ( lets say 192.168.178 traffic comes into CHR and needs a path to 192.168.10 subnet through the wireguard)

I am assuming b. but what about the other peer subnet 192.168.178.0/24? Do you have chr traffic heading that way through the tunnel or coming into the CHR from that private subnet.
If so, you have a missing route??

I have to go but will look at rest later.

(2) You need to indicate the subnet NOT the address for peers coming in or allowing local to reach remote subnets........
/interface wireguard peers SHOULD BE 192.168.10.0/24 and 192.168.178.0/24
add allowed-address=192.168.10.1/24,192.168.80.2/24 interface=wireguard1 \
public-key="client 1"
add allowed-address=192.168.178.1/24,192.168.80.3/24 interface=wireguard1 \
public-key="client 2"
/ip address

I made this change but I didn't notice any differences

(4) I note this route..... Again, it should be to the subnet NOT to the address aka 192.168.10.0/24
/ip route
add disabled=no dst-address=192.168.10.1/24 gateway=wireguard1 routing-table=\
main suppress-hw-offload=no

it is correct to ping all the addresses of that network; surely there was an error since adding it manually from winbox it is automatically converted from "10.1/24" to "10.0/24"

For discussion purposes, this is a good route for either of the two cases.
a. local traffic heading to this private IP address gets routed to the tunnel (local subnet to client subnet)
b. remote traffic from remote subnet which hit your local subnets or used local internet and needs a path back to the wireguard tunnel.
c. remote traffic from one client that when exits the tunnel at the CHR and is sitting on the router (parallel to the LAN subnets in a way) needs to go to the other wireguard client. ( lets say 192.168.178 traffic comes into CHR and needs a path to 192.168.10 subnet through the wireguard)

I am assuming b. but what about the other peer subnet 192.168.178.0/24? Do you have chr traffic heading that way through the tunnel or coming into the CHR from that private subnet.
If so, you have a missing route??

yes, I still haven't defined all the routes as I am doing some tests



let's say it is very similar to OpenVPN even if I hope the performance is better and there is no need to update the certificates.

the problem remains on the routes,
but what I hope to solve with wireguard is the possibility of connecting multiple different lan networks to the same wireguard interface and making them communicate with each other; also some networks use the same addresses but will be connected on different wireguard interfaces

your latter statement is very doable, just have to be clear in your requirements on what you wish to accomplish
a. subnet to subnet
b. subnet to internet or device(s) to internet
c. device to subnet, or subnet to device

Etc...........
The overall concept is that all the client routers or even road warriors on laptops or even you on your iphone connect to the CHR.
All clients will end up on the CHR and parallel to the CHR LAN and have to have
a. firewall rules to be allowed to go to the next step (chr subnets, chr internet, another wg client and thus the ability to enter back into a wg tunnel).
b. routes for the same above
c. consider sourcenat when applicable.
d. the key is understanding how to use allowed IPs/addresses and that there can be no overlap on different peers For the SAME interface on the CHR. If there is you will need to create another wg interface for example and this is very doable and the same concepts about firewall rules and routes apply.

LTE1
(1) Allowed IPs is set at 0.0.0.0/0 for wireguard.
Q. Is this because you want to go out the internet on the CHR ??
Think carefully of this entry it says ANY IP address local LAN users want to reach would be allowed into the tunnel (need fw rules and routing to match of course).
It says accept any IP coming out of the tunnel and onto my LTE.


(2) The IP address is good, /24 here as it should be for a MT device.

(3) What is the purpose of these rules
add action=accept chain=input dst-port=13231 in-interface=lte1 protocol=udp
add action=accept chain=input dst-port=13231 in-interface=lte2 protocol=udp

The LTE1 is a client and has NO need for input chain rules from the internet.
The traffic or connection is established on the outbound to the CHR. The CHR needs the input chain rule.

Where you may want an input chain rule is for the admin to lets say configure the LTE1 remotely, lets say from a coffee shop using your iphone.
You wireguard into the CHR, traverse the tunnel and then config the LTE1.
So on the LTE1 you would need an input chain rule something like.
add chain=input action=accept in-interface=wg1 src-address=Wireguard assigned IP { to your iphone }

(4) What is the purpose of this rule................. open ended rules are generally weak to implement.
add action=accept chain=forward connection-state=established,related \
in-interface=wireguard1 TO WHAT is allowed specifically ??

(5) Why do you need to masquerade the traffic going into the tunnel??
add action=masquerade chain=srcnat out-interface=wireguard1

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

LTE2

(6) Same issue with allowed IPs as LTE1, could be okay, but you need to clarify the intentions......
/interface wireguard peers
add allowed-address=0.0.0.0/0 endpoint-address="chr ip" endpoint-port=\
13231 interface=wireguard1 public-key=\

(7) Not sure why you are using same port for two different VPNs probably not a good idea......
add action=accept chain=input comment="Allow WinBox over VPN" dst-port=8291 \
in-interface=ovpn-ftth protocol=tcp
add action=accept chain=input comment="Allow WinBox over VPN" dst-port=8291 \
in-interface=wireguard1 protocol=tcp

In general I never post an actual VPN port where its not fixed and known, so recommend actually changing it on this device, but use 8291 as a fake entry.
As per the LTE1, also since many people are using the tunnel suggest be more restrictive in your input chain rule.
add action=accept chain=input comment="Allow WinBox over VPN" dst-port=8291 \
in-interface=wireguard1 protocol=tcp[/i] src-address-list=Authorized

where firewall address list is something like
add address=iphonewireguard IP address list=authorized
add address=LTE1 admin IP address list=authorized
etc........

(8) What is the purpose of this rule on the LTE2, it is not clear to me that users are coming to the LTE2 to go out its internet for example.????
add action=masquerade chain=srcnat comment="defconf: masquerade" \
ipsec-policy=out,none out-interface=wireguard1

NEXT POST WILL LOOK AT LTE1,2 routing

LTE1 - No routing existing for wireguard traffic ???
LTE2 - No routing I see at all for LTE let alone for wireguard traffic ??

LTE1
(2) The IP address is good, /24 here as it should be for a MT device.

Why is this? Surely if I wanted a different subnet, it would work if defined properly? Could I configure a /27, for example?

LTE1
(2) The IP address is good, /24 here as it should be for a MT device.

Why is this? Surely if I wanted a different subnet, it would work if defined properly? Could I configure a /27, for example?

Yes you can get fancy if you like, but from experience /24 works in all cases and is easily able to accommodate a wide range of possible client IPs in a subnet.
My aim is to get the OP a working config, if they want to tweak it after further, that is their call.

your latter statement is very doable, just have to be clear in your requirements on what you wish to accomplish
a. subnet to subnet
b. subnet to internet or device(s) to internet
c. device to subnet, or subnet to device

I understand that it is not easy to explain or understand, however I try to explain it better, at the moment I had the connection problem with LTE that I solved, everything else would concern another post

the need as for the current OpenVPN is very simple, no internet access, only gateway to route traffic between the various LANs


ltAP and wAP - they are all connected using wireguard's internal ip and all communicate on a single server, to give you an example:

ltAP (wireguard ip 192.168.7.5) -> CHR -> Server (wireguard ip 192.168.7.2) - there is no need to manage the various subnets of the devices

For the other devices, instead, you need to access the various subnets, for example:

"wireguard5" interface, internal subnet (172.16.45.0) manages and routes 3 subnets, (192.168.88.0 - 192.168.1.0 - 192.168.10.0) in practice the three class c networks communicate with each other on the "wireguard5" interface ,
but I could have example on another interface example "wireguard8" a subnet identical to "wireguard5" always for example "192.168.10.0" and I hope that these can be managed without causing a conflict, with openvpn it was difficult to handle these cases

LTE1
....
LTE2
....
NEXT POST WILL LOOK AT LTE1,2 routing

do not consider them is a device used exclusively for LTE module tests, all the configuration made there above 80% is no longer necessary but is still active

Your explanations are not helping.
1. Please provide a network diagram detailing the equipment involved and how they are connected and the subnets involved.
2. Provide requirements as use cases.

a. identify users/device, groups of users/device
b. identify what they should be able to do and not able to do, (including the admin user)
c. dont mention the config in the above a., b. responses.
I want some/all/one ??? users from LTE1 to use the internet of CHR
I want some/all/one ??? users from LTE1 to reach one server on LTE2
I want some/all/one ??? users from LTE2 to reach a subnet on LTE1
I want to be able to, as admin, config CHR LTE1, LTE2 from my iphone while in a coffee shop.

The clearer picture you paint, of what all the needs are, the quicker we can resolve the config.

Your explanations are not helping.
1. Please provide a network diagram detailing the equipment involved and how they are connected and the subnets involved.
2. Provide requirements as use cases.

a. identify users/device, groups of users/device
b. identify what they should be able to do and not able to do, (including the admin user)
c. dont mention the config in the above a., b. responses.
I want some/all/one ??? users from LTE1 to use the internet of CHR
I want some/all/one ??? users from LTE1 to reach one server on LTE2
I want some/all/one ??? users from LTE2 to reach a subnet on LTE1
I want to be able to, as admin, config CHR LTE1, LTE2 from my iphone while in a coffee shop.

The clearer picture you paint, of what all the needs are, the quicker we can resolve the config.

I saw that you did not understand, unfortunately making a diagram is now very complicated on an infrastructure that has been active for 6 years now, if wireguard will allow me to do everything without problems, I could also consider making a diagram but it is all a waste of time.

hoping that the scheme and operation is understandable is this:

wAP LTE and LtAP LTE currently are 768 devices on the network and they use the 172.16.20.0/22 subnet, where 1 is the CHR and 2 is the data processing server. All wAPs and LtAPs have the same subnet 192.168.88.0/24 and I am not interested in reaching the clients and they go out on the internet only through the LTE and not through the CHR.

All other devices are mostly RB4011, hAP AC3, RB951G, hAP AC and some other older devices like the RB750s.
There are about 60 different networks (to understand what I mean by networks, there are 60 different small companies that do not share the same network), which use subnets /30, /29 and /28 on the CHR and which must be connected to other side, each client accesses the clients of the other side using a Static DNS, the only limitations are that each network cannot access others but only those to which they have been assigned (in practice to the subnets of the same company). They do not have access to the internet through the CHR (consider it as if it has no internet), only I can access all networks, including subnets, from my dedicated connection but only for debug and anyway I don't use the internet via the CHR.

all the published material including the various configurations is all to be considered for testing, because then in production it will be totally different; therefore you may find configuration errors and / or unnecessary configurations

I hope it will be more understandable for you to get an idea of how it will be accomplished by migrating to wireguard.

Regardless the numbers the principals remain the same.
The best place to start is the CHR, starting with an IP address schema that you will use for all connected devices to the same wireguard interface.
Determine how many wireguard interfaces you need on the CHR.
You can segment wireguard interfaces into groups of users that are more likely to interact with each other more frequently for example.
What needs to be avoided is peer overlap at the CHR.

Regardless if you have one interface or many wireguard interfaces on the CHR, just ensure the firewall rules exist for any peer traffic exiting a wireguard tunnel or needing to enter a wireguard tunnel.
Think of the CHR as the hub of activity where all tunnels spill into the router parallel to the LAN but not on the LAN. So layer3 rules are needed to allow traffic to intended destinations.
Ensure routes exist to allow intended traffic or to drive traffic to where it needs to go. Often, no internet required, the IP address structure handles a significant route load through <dac routes>. For remote subnets just ensure their traffic has a path back to the tunnel from the CHR.

Reread this several times......... and if anything is not clear, ask....
viewtopic.php?t=182340

Given the description of your use case, you are clearly not the target audience for @anav's "one-size-suits-all" recipes So let me throw in a couple of hints.

Wireguard, similarly to non-Mikrotik OpenVPN, acts as an autonomous virtual router hosted on the main one, in terms that it has a "WAN" interface interconnecting it with the main router and a bunch of tunnels to peers. To know through which peer to reach a particular destination subnet, it uses the allowed-address parameter, which is a list of prefixes reachable through the peer. The list of peers hooked to the same instance of the virtual router (represented in the configuration by the /interface wireguard row) is searched top to bottom until first match, like firewall rules or IPsec policies. It means that if there is the same subnet behind multiple Wireguard peers and you need to be able to use some kind of policy routing or VRF to reach each of them, you have to connect each such peer to another instance of the Wireguard router, and then you can use policy routing or VRF to choose the right instance (represented by the interface) at the main router. The WG virtual routers themselves ignore any routing mark or connection mark values.

The allowed-address list is used also to filter incoming traffic - if, by mistake, a payload packet arrives from a peer, with a source address that doesn't match any prefix on the allowed-address list of that peer, the packet is dropped.

So to make sure that a packet can get from LTE peer A to LTE peer B via the Wireguard tunnels to CHR, the target subnet at B must be on the allowed-address list of the CHR peer on LTE A as well as on the allowed-address list of the LTE B peer on CHR. As it is not bare IPsec that hijacks any packet it likes, you can set allowed-address at all the LTE peers to 0.0.0.0/0 provided that they have no other peer than the CHR. On the CHR end, you may do the same if you keep one peer per interface, but I have no idea how many WG interfaces the system can handle. The "virtual router" is probably just a mind model and the actual implementation is simpler, but still.

Then there's the question of assigning IP addresses to WG interfaces - this is just a convenience, you can use their names as gateway parameters of routes.

That is one way of saying it! Mind you, all well covered in the linked article, just not as ethereal.

It is rather cookie cutter for the basics and then one has to use "The Force" of mt config magic for scenarios that are more complex, the domain of wizards, such as Sindy