Thanks for the prompt reply. I believe I’m missing something here:
I assigned the “wireguard1” interface to my LAN list as advised- by enabling wireguard on my phone while on LAN there’s some torch activity, however no activity is listed if I attempt to enable it via cellular (i.e. no obvious change following the LAN interface addition).
The following settings appear to produce some results:
No luck with changing the allowed address to 10.0.0.8/32 on routeros and the android client.
I’m somewhat confused by the fact that the log firewall entry shows input-in as “pppoe-outFEED” whenever there’s activity/handshake instead of the assigned interface “wireguard1”, it appears that the traffic is routed through WAN (pppoe-outFEED) instead of the previously assigned LAN (wireguard1) interface. Not sure if related to the solution, guess it’s worth noting. Edit: I inserted an accept-forward rule for the in. interface “wireguard1”, log shows the above message along with WG: forward: in:wireguard1 out:bridge, proto UDP, 10.0.0.8:12117 (android peer)->192.168.88.98:53 (pihole).
The following configuration allows me to ping android peer ↔ LAN, while torch on the wireguard1 interface shows some packets towards 10.0.0.1 (router), 192.168.88.98 (pihole DNS), and some (I believe) external public IPs when opening youtube for example, however internet is still inaccessible.
It looks like you have changed some rules from the defaults. Some of the default rules are configured to use the interface lists LAN and WAN instead of hardcoding a single interface. You have changed all of your firewall rules to use hardcoded “ether1” instead of interface list WAN and hardcoded “bridge” instead of LAN. This hardcoded setup only works as long as you only have a single LAN port and a single WAN port. In your case, you now have two LAN ports, bridge and wireguard1, so you should rethink this configuration.
Not sure I’m following here- I swapped any rules with in/out.interface=ether1 to in/out.interface list=WAN and any of those with in/out.interface=bridge to in/out.interface list=LAN. No firewall rule appears to be “hardcoded” at the moment, and I attempted to disable the interface wireguard1 from the LAN list for troubleshooting purposes.. End result was the same as previous post.
Thanks for your patience.
I strongly suspect the problem is in your firewall rules. Some of your rules don’t make any sense. At one point you have a drop all rule on the input chain, then after that you have more input chain rules that will never be matched because everything will hit that drop all rule instead.
Make a terminal window that is big enough and run:
/system default-configuration script print
That will print the default configuration including the default firewall. Take the default ip firewall and ip firewall nat rules and copy and paste them into your router, then disable or delete the rules that you have in filter, NAT, mangle, and raw tabs. Then add an input chain rule to allow udp to 13231 to that. The MikroTik default firewall should just plain work, with the addition of the UDP 13231 rule and adding the wireguard1 interface to the LAN interface list.
This should be a thread in either Ros7 beta or beginner or general.
Not troubleshooting your config. Specific questions about the wireguard implementation that may need explaining are fine but otherwise just clogs up a good reference document into a mess.
Since this is my first post on this forum, prior to ask about things, I’d like to say HI to you.
I am lacking some knownledge and I’d like to ask you for a help and understanding my case. I prepared small schematic (sorry about performance) of structure of my network. That’s first.
I am trying to get Wireguard working on my mt, but no luck. I tried all suggestions here and on yt posted but no luck.
Back in the days, when I managed old router (before mt) I just had to port forward, to my server with wireguard and all was fine. I suspect now is probably the same case.
Thank you so much!. I wanted to access my home network clients from outside.
Sticking points for me, were:
Stupidly forgetting to assign an ip address to wireguard interface in IP>Addresses
Add the route like you said, destination was the subnet of the wireguard ip, gateway was the wireguard interface name, not ip. (ie. put ‘wireguard1’ or whatever your wireguard interfaces name is in the gateway section
Allowing traffic to be forwarded from the wireguard interface to the local lan bridge and allowing traffic to flow from the wireguard interface to my internet connection interface
I like the clean approach you had in the top of the post, easy to read/understand.
You may have not noticed my post and diagram at #6 that already cover your scenario. Both my wireguard routers ( the server [rb450Gx4] behind the ccr1009, and the client [RB4011] behind the ISPs modem router ). The main difference is that I do not use IP addresses for my wireguard, I only use the interface itself and a mix of rules.
The outcome is that I have to make an additional route etc… both worth equally well.
I saw it, but I couldn’t map the diagram to running RouterOS commands. Thus my triumphant post at having worked out the solution from the top post and other relevant examples and docs.
This works perfectly if there is only one client. As soon as I add another peer, whole thing goes down. Handshake fails for both clients. The thing to note here is my clients don’t have static IPs and they are behind NATs in their ISPs. So I can’t set endpoint address in peers. I thought the different public-keys of different clients would be enough to connect multiple clients. But it doesn’t seem so. All devices are running routeros 7.1.1. Is this a bug in routeros’s wireguard implementation? Of am I doing something wrong? All devices has ip firewall rules empty. So its not firewall messing with anything either.
This is wrong - if you look at the server configuration above in the very top post, you see that the peers under /interface wireguard peers each have an allowed address that is their wireguard IP address /32. Allowed-address=0.0.0.0/0 will not work on the server if it has multiple clients.
Those two routes are unnecessary as the wireguard server device already has an IP on that /24 subnet and so a connected route will automatically exist for the entire /24 that will cover those two /32’s.
Thank you very much. This was my problem. I changed allowed address to 10.x.x.2/32, 10.x.x.3/32 etc… in adding peers and now all client can connect and its all working nicely
Is it just me or is it impossible to also add a “pre-shared” key ? (as an extra layer of post-quantum protection
Whatever I place in that field, I’m always getting “invalid preshared key (6)”
Winbox, CLI , does not matter.
I’ve tried disabling my peer before adapting the value, no luck.
You might not have a “bas64” filter installed, but if not, they’re pretty much available on all platforms.
The final part of that command is macOS-specific. Other platforms have tools for taking piped-in data and sending it to the clipboard so that you can paste it into a command like:
BUT as of 7.1.1., this parameter appears to be completely ignored! As long as you either pass nothing or pass a correctly-formatted value, the clients will connect, regardless of the value on the client side. Sigh.
