(1) In allowed IPs, the server needs to have the wireguard IP address in the format for each peer of /32.
Thee clients should have the wireguard IP address in the format of the subent .0/24
(3) Having duplicate subnets/ peers to go to is going to be confusing… and will not work!~
_/interface wireguard peers
add allowed-address=192.168.251.2/32,172.17.2.0/24,224.0.0.0/24,**192.168.250.0/24 comment=“VPN002 Zuerich Gruenau Tiefgarage” interface=“PEWO VPN”
persistent-keepalive=15s public-key="*********************="
add allowed-address=192.168.251.1/32,172.17.1.0/24,224.0.0.0/24,192.168.250.0/24 comment=“VPN001 TestRouter” interface=“PEWO VPN” persistent-keepalive=15s public-key=_
In this case, any user on your Server, or remote user coming into the server, looking to reach another spoke, requesting to go the second peer will always be directed to the first peer. ( second rule never visited)
(4) By the way a good rule to have on the Server Router is… thus making it clear any spoke to spoke traffic via the hub is permitted. add action=accept chain=forward in-inteface=wg-interface-name out-interface=wg-interface-name
(5) The Hub Router is missing many routes for the subnets where either the router needs to know where to send the return traffic (back through the tunnel) or where to send local requests for those subnets (to enter the tunnel).
(6) Its becoming clear you dont know squat about wireguard and yet seem to happily and merrily go very complex with OPSF and wireguard.
For example. WTF is this… /interface wireguard peers
add allowed-address=192.168.251.254/32,10.10.0.0/16,224.0.0.0/24,192.168.250.0/24
endpoint-address=SERVER-IP endpoint-port=PORT interface=“PEWO VPN001”
persistent-keepalive=15s public-key="***************="
/ip address
add address=172.17.1.1/24 comment=defconf interface=bridge network=172.17.1.0
add address=192.168.250.1 interface=loopback network=192.168.250.1
Allowed IPs has nothing to do with any addresses locally!! Its only considering external subnets (what to visit, or what may visit you).
The format appears to be wrong in the address missing .1/24 ??
For explenations: it’s a RouterOS-VM in a Hosting-Center.
(1) done
(2)
add disabled=no distance=1 dst-address=10.10.0.0/24 gateway=10.10.0.1 pref-src=“” routing-table=main scope=30 suppress-hw-offload=no target-scope=10
Without this rule, i can’t access the next VM on the Cloud-Hosting-System, because the DHCP-Address (10.10.0.4/16) does not bring the Virtual Gateway (10.10.0.1), wich is needed to contact the other virtual machines…
add disabled=no distance=20 dst-address=0.0.0.0/0 gateway=172.31.1.1%Internet pref-src=“” routing-table=main scope=30 suppress-hw-offload=no target-scope=10
This is my Internet-Connection
(3)
I’ve read, that 224.0.0.0/24 is needed for OSPF-Broadcast. Doesn’t i need this?
I have replaced the address 192.168.250.0/24 with 192.168.250.XXX/32
(4)
Thanks, it’s implemented.
(5)
In the working OSPF-Client, the Routes come up (out of OSPF) for both directions.
(6)
Yes, i have not understand, which addresses have to be filled in by “Allowed Address”.
The Rule: add address=192.168.250.1 interface=loopback network=192.168.250.1 is the Loopback-Bridge-Address what i have made for the Router-ID
was in a toutorial from Mikrotik)…
The IP address 250.1 seems hokey to me and would avoid.
Know nothing about OSPF so cant help you there, but allowed IP rules are allowed IP rules and should be followed… no duplicates!!!
As far as the first two comments, I didnt mean get rid of the rules I mean get rid of the empty fields pref-src=“”
Looks like you have OSPF set to type=ptp. From OSPF’s perspective, the Wireguard interface is a single interface even if more than one remote peer can send packets to it. In P2P mode it’s going to assume that there is only one peer on the interface and use the usual multicast/broadcast mechanism. Whatever router connects first is likely to be the one that forms the neighbor adjacency and everything else is out of luck.
It looks like you are fine with a static enumeration of the peers since you’ve configured /routing ospf static-neighbor but I’m pretty sure that doesn’t take effect for interfaces in P2P mode. In type=nbma mode, the neighbors will be formed using unicast hellos so that should make sure each configured peer on the wireguard link gets one.
