I have two hAp ac^3 connected with wireguard site-to-site VPN, working perfect. I can access router and computers from site A to site B and reverse. But, now I’ve added roadwarrior VPN connections in site A. This is the network diagram:
Roadwarrior connections have internet access and can access computers in network A, but not in network B. I’ve been searching a lot and found that router B need a route with the roadwarrior network, and after add it, I can access router B … BUT still can’t access computer B.
This is config from router B, because is where the error is (I think):
From roadwarrior connection I can go up to router B, but not more far, This is traceroute to computer B from roadwarrior:
C:\Users\Mobile>tracert 192.168.1.10
Traza a 192.168.1.10 sobre caminos de 30 saltos como máximo.
1 25 ms 1 ms 1 ms 192.168.11.1
2 40 ms 41 ms 34 ms 192.168.50.1
3 49 ms 45 ms 47 ms 172.16.1.2
4 * * * Tiempo de espera agotado para esta solicitud.
5 * * * Tiempo de espera agotado para esta solicitud.
6 * * * Tiempo de espera agotado para esta solicitud.
7 * * * Tiempo de espera agotado para esta solicitud.
8 * * * Tiempo de espera agotado para esta solicitud.
9 * * * Tiempo de espera agotado para esta solicitud.
You should not assume you think you know where the problem is and simply post both configs.
The road warrior should be in the same subnet as the rest of the wireguard so not sure what you are doing, and of course, without the other config, am in the dark.
On Router B.
(1) Modify allowed IPs TO: /interface wireguard peers
add allowed-address=172.16.1**.0/24,**192.168.3.0/24 endpoint-address=xxx.sn.mynetname.net endpoint-port=xxxx
interface=wireguard-sts persistent-keepalive=10s public-key=“xxx”
(2) why do you have this??? add action=accept chain=input comment=“VPN: allow wireguard-sts” dst-port=
xxxx protocol=udp
(2) why do you have this???
add action=accept chain=input comment=“VPN: allow wireguard-sts” dst-port=
xxxx protocol=udp
This is to allow wireguard traffic from the WAN.
That would hold true if this device was the server for handshake but it is not, and thus the rule serves no purpose.
There is no traffic comeing from the server MT device asking to connect to the client peer for the handshake.
I hope thats clear and why the rule is not required.
You failed to make the changes I recommended on Router B, so no comment there.
As for router A.
(1) You are very confused…
/interface list member
add comment=defconf interface=bridge list=LAN
add comment=defconf interface=ether1 list=WAN
add interface=pppoe list=WAN
add interface=wireguard**-rw list=WAN** <---- remove
add interface=wireguard-sts list=LAN
add interface=wireguard**-rw list=LAN**
REMOVE THE WAN membership
(2) Why does router A have client peer type settings, for the other MT router… it should look like. /interface wireguard peers
add allowed-address=172.16.1.2/32,192.168.1.0/24 interface=wireguard-sts
public-key=“=====”
By the way the second wireguard interface is a local subnet on this router, there is absolutely no requirement to state it on the allowed IPs for the Client peer router.
You are correct in that the client peer router (B) needs that subnet on its allowed peer setting for this device, which is now made clear by not hiding information.
However as noted on the top of this post, the allowed IP should be modified to 172.16.1**.0/24** on Router B.
No firewall rules so cannot comment much on that.
IP Routes need works…
TO: /ip route
add dst-address=192.168.**1.**0/24 gateway=wireguard-sts routing-table=main
You dont need a route for a local subnet ( wireguard rw) as its already created with the IP address.
Also you had the wrong subnet, .3.0 is local you need .1.0 aka match your allowed Ips…
Thanks for your reply, I really appreciate your help.
I didn’t make the changes on router B on first time, because I preferred to send you both router configs. I have applied your recommendations, and it’s working now! I can access computers in network B from road warrior.
