Hi. I have a wireguard tunnel set up on my hap ac3. I have two peers configured in the router with addresses 10.1.0.2/24 and 10.1.0.3/24 for a phone and a windows 10 client.
the router itself has an 10.1.0.1/24 address. the firewall rules can be seen in the picture below (rules 1 & 2 are for zerotier).
I also have added wireguard to the LAN interface list to be able to access my router through the vpn tunnel(i think that’s why the LAN list is for).
My problem is that i can’t have simultaneous connections to my home network using phone and pc. When I connect with either one and try to establish the tunnel on the other one, the second one does not work.
-i want to be able to access my whole LAN and have the peers communicate with each other via the tunnel. What changes do I have to make? thanks in advance
I can post my config if it helps.
EDIT: wow.. i just found out why vpn connections /drop/fail/partially work when i establish them from my home network.. I use a hybrid router (adsl + LTE ) and I read online that more users experience vpn issues with hybrid routers.. turning off the bonding tunnel and using raw dsl provides slower speed but stable connection without ups and downs
The items on the allowed-address list of the /interface wireguard peers row should be subnet addresses (prefixes), so 10.1.0.2/32 is fine, 10.1.0.2/24 was not, and I am not sure why RouterOS doesn’t complain about the latter. If it silently “rounded down” the 10.1.0.2/24 to the proper subnet address 10.1.0.0/24, it would explain why only one peer could work at a time, as Wireguard uses this list to choose the proper peer under the same interface and the first one with allowed-address=10.1.0.0/24 shadows the second one with the same allowed-address.
But from what you wrote it seems doing it right (/24 → /32) hasn’t helped, so a stupid question - do you use a distinct private/public key pair for the Windows PC and for the phone?
@sindy
Your last remark should be covered since Mikrotik WG implementation does not allow reuse of private/public key pairs for peers.
You will get an error if you try to do that.
Some consider it a bug, I consider it common sense and logic.
@pitfermi:
If the allowed address contains the IP address of the WG itf, it should be distinct, as indicated. Otherwise WG does not know where to go to.
So /24 will effectively give you problems but using /32 it should work.
Did you try after that change ?
Separate peers should be made with their own private/public key pairs on server side, if you want to call it that, and as a consequence a unique config for each client.
Reusing keys for peers on same WG interface would be problematic, because key is what identifies peer, and peers don’t have to use static endpoints, so you wouldn’t be able to tell one from another. But reusing keys on different WG interfaces could work just fine.
Yes. I think restarting the router and/or the devices’ networks and/or closing wireguard applications did the trick. Now I can connect with both my devices to the MT and also ping each other without problem. However, if I disconnect one device(i tested with my phone only) while both pc and phone are connected, the other device’s connection drops as well.. both my devices are on the same
LAN. Furthermore, switching APs inside my place from main router to an AP/extender(same subnet, acting as switch) and restarting wireguard on my phone does not let me tunnel anymore..
I think this has to do with the endpoint (MT router) not being informed about the connection drop? Is there a thing like “keepalive/” option that i can tune, so that the endpoint can check the connx to the other peers more often?
You can activate keepalive, however the Wireguard protocol should deal silently with an IP address change of one peer at a time even on the fly and dynamically change the socket address of the peer. So a new connection of a client from another address should simply replace the previous one without need that it first timed out or something. The keepalive is there to keep the pinholes in firewalls open, not to monitor the state of the connection and eventually tear it down.
Wireguard is great with moving clients, as soon as it gets first packet from new address:port, it immediatelly switches peer’s endpoint to it. I tried tunnel from dual-WAN router to remote server, kept the ping running inside it and made each outgoing packet use random WAN:
EDIT: wow.. i just found out why vpn connections /drop/fail/partially work when i establish them from my home network.. I use a hybrid router (adsl + LTE ) and I read online that more users experience vpn issues with hybrid routers.. turning off the bonding tunnel and using raw dsl provides slower speed (1200kB/s, yea, dsl sucks in greece) but stable connection without ups and downs.
so a little update. i ran a speedtest through the wireguard tunnel using my mobile phone.. phone–>WG<–Tik—>speedtest and i get almost full upload speed @42mbps(out of 50). see screenshot below.
downloading a file from my NAS behind the Tik, through the WG tunnel only happens @ 24mbps and not close to 42mbps.. that’s half of what the actual WG tunnel can deliver. why??? is this normal?
hi all. i still have speed issues. only a couple kB/s to my NAS.
oepning a port to the router and doing file transfers via port forwarding without tunnel is fine, i get full bandwidth.
@pitfermi
You could create a block list for 15 to 21 [name it buggers] and then create a Firewall Filter rule in RAW that drops those ip addresses … that will provide some more efficiency.
When using Wireguard is the throughput erratic behavior happen all the time or during specific time of day/night?
(1) First question,
Can a WG tunnel be an interface list member of LAN? if so, nice! ( This should be okay, its just I have a nagging feeling that a wg interface is not allowed somewhere in some rule hmmmmm???)
(2) Second question, is there any reason to put zerotier or wireguard
BEFORE the established related rule, or any reason to put it after ??
(3) The input list chain of IPs that you wish to block, what is their purpose and why out of order ??
Since in the order of rules you already dropped all WAN incoming, are you assuming these IPs are coming from the LAN side ???..
