I’m struggling with a lab config between two CHRs running RouterOS 7.9
The topology is like this:
LAN A -------------> Router A -----> Internet ------> Provider (carrier NAT) --------> Router B ------------> LAN B
192.168.77.0/24 192.168.88.0/24
Router A has a public IP on its outside interface, router B doesn’t due to the carrier NAT in the provider network. The tunnel will obviously only be able to be initiated by router B but this is OK.
[admin@A] /ip/firewall/nat> /interface wireguard print
Flags: X - disabled; R - running
0 R name="vpn-to-b" mtu=1420 listen-port=25070 private-key="gM+uCt/2WJajqM55VwpohdZBu2VtQ/l+LIRRYHYNkE0=" public-key="zW5HwHVFpqDwxRt1fKb/Yv+uSNKZhLXYnLm9TwwHsUA="
Router B
[admin@B] /ip/firewall/nat> /interface wireguard/print
Flags: X - disabled; R - running
0 R name="vpn-to-a" mtu=1420 listen-port=25070 private-key="cKD9fR/8bKGhunHpcsnivQFJr3ZD7DOEMgGFzqLgq2U=" public-key="2UZ1OE9TFaS0V/shFmTPKqLLgOeJjwovZZSbdsk/PhU="
From everything I have read, this config looks OK, except I cannot ping from B to A, and I see no packets between them. As mentioned this is running in a lab (EVE-NG) so I can easily Wireshark the traffic between the nodes of the network.
I would be grateful for any help as I can’t see what’s wrong here.
I should also add that the routers are both able to ping each other, and that devices behind each can ping other things across the network. So it doesn’t appear to be a network issue as such.
As mentioned, I don’t see any Wireguard packets attempting to communicate between the two, so it looks either like a bug, or I have something missing from my config.
Yes it should, I would guess all your other peers are incorrect.
The way to ensure traffic does not pass is the use of firewall rules at the receiving router end…
(aka assumes peer 5 is a router)
Ex at Peer 5
add action=accept chain=forward in-interface=wireguard dst-address=subnet src-address-list=( LIST OF SPECIFIC entities allowed to LAN via wireguard )
Ex at Peer 5
add action=accept chain=input in-interface=wireguard src-address-list= (List of wireguard IPs ALLOWED to configure router remotely )
The Other Case if if the peer is a Singulard Device. like a PC. There is no concern as the allowed IPs is probably set to 0.0.0/0 ( which most single devices use which means EVERY IP and this never causes issues at the device itself security wise, and if actually set to
172.31.1.0./24,subnet-on-router…
Think about it, there is no router config or LAN subnet for any remote users to connect to on the PC.
those peers are other mikrotiks… the same config works flawlessly on other… even that 10.0.0.0/24 tunnel is working…
SITE A: 192.168.10.0/24
SITE B: 10.0.0.0/24 (0.0.0.0/0 allowed IP’s on wg peer)
from site A mikrotik i can ping e.g 10.0.0.8…
but from 192.168.10.5 i cannot ping 10.0.0.8…
firewall rules are OK.. traceroute stops at 192.168.10.1, which is site A mikrotik
In general only the router (server for handshake) identifies peer by /32 addresss ( peer to peer quality)
All other routers (acting as cliengs for handshake) not using 0.0.0.0/0 for allowed IPs (covers all addresses) should utilize for allowed IPS.
wireguardsubnet, remotesubnet(s)
where remote subnets details one or both possibilities
remote subnets and their users that are coming into the local router and exiting the tunnel
remote subnets that LOCAL users have as destination addresses on their traffic heading into the tunnel.
There is no cause for concern by putting wireguard subnet into allowed IPs. If you thought there was, it would be bogus as you already do so for any 0.0.0.0/0 entries.
In fact, if at the main router (server for handshake) you do not allow traffic to be relayed between peers, no cross traffic will occur anyway. add chain=forward action=accept in-interface=wireguard out-interface=wireguard
Thus setup the proper format for wireguard routing, and ensure remote subnets are accounted for on each router needing to reach them or reply to them /ip route
add dst-address=remotesubnet gateway=wireguard routing-table=main.
The rest is dealt with on firewall rules input chain to reach config, forward to reach subnets or to enter tunnel.
I’ve come back to this after not working on it for some time. I implemented the steps mentioned in an earlier reply and I now see Wireguard initiation packets being sent from B to A, but A never responds or initiates a tunnel.
VPN is a router service.
Where have you allowed the handshake in the firewall rules??
On router B the allowed IP should be /interface wireguard peers add allowed-address=192.168.77.0/24,10.255.255**.0/30**
the same config works flawlessly on other… even that 10.0.0.0/24 tunnel is working…