Wireguard from Linux not working

resca · Mon Feb 12, 2024 5:22 pm

Hello, a few days ago, I configured my Mikrotik router with Wireguard to act as a server for some of my devices. I then installed Wireguard on two Android phones, using the parameters that are automatically proposed when generating the Peer on the router (I just had to add the Endpoint) and they both work perfectly. Since I don't need to use them at the same time, I only have one peer on the router and I always access that one. So far, so good.

I then installed wireguard on linux (Fedora XFCE 39) and performed the same steps as on phones: it doesn't work! What I see is that the "Handshake Initiation" packet exits the linux box, arrives in the router and passes the firewall (accept). At this point it vanishes. Unlike what happens when connecting from the phone, nothing appears on the wireguard interface and I don't have any error messages, logs or anything else. I checked all the parameters dozens of times and I don't see any errors.

One strange fact is that, given that on the router I can see both the private and public keys for the peer, I tried to have Linux generate the public key, starting from the same private one (wg pubkey <private >public) and it generates a totally different key compared to the one the router provided:
1dyIGxarO5faR9r+XQ33qp/f6Ykn6PsiTEL2aH5CPCk= is the one from mikrotik, TpPPXH1qSGF8tgP7k3sxW6sKoQO1+IcGxbs30vd2QkA= is the one that generated by linux.

I also installed a new Fedora 39 XFCE Linux box: same behavior!

At this point I suspect that they use a different coding system (possible???) and I am lost.

Suggestions?

Larsa · Mon Feb 12, 2024 7:05 pm

@resca, to trace traffic on the Linux box, use for example, "tcpdump -i name-of-wg-interface". On the MikroTik, use Winbox "Tools -> Packet Sniffer" and select the wg-interface to trace packets in real-time. If you don't receive any traffic on the Linux box, you might have a firewall or double-NAT problem somewhere along the line.

Regarding the Linux WireGuard private/public keys, endpoint address, and port number, they must be an exact copy of the configuration you have on the Android devices.

resca · Tue Feb 13, 2024 12:24 am

@larsa, I understand my description is not complete! Let me say in other words:
-I used WireShark on Linux and I see the "Handshake Initiation" transmission.
-I used Packet Sniffer on Mikrotik and I see the incoming "Handshake Initiation" packet.
-I added an Action-log on my firewall line that accepts the packets on my wireguard line and it triggers, so the packet IS accepted.
-I monitor the Traffic on Wireguard interface and I see NOTHING: no activity at all.
-While wireguard reports 0 input packets, I cannot expect any output packets, so non reason - by now - to check further elements.
In contrast, when I connect with Android, the "Handshake Initiation" causes input packet count on wireguard interface to 1, immediately afterwards one output packet appears on the wireguard interface and a packet is sent to the phone and the handshake continues.

So the problem is definitely that the packet is accepted by the firewall but someway discarded by/before the wireguard interface
I would like to have something to understand why the "Handshake Initiation" is not received by wireguard OR it is received and discarded without any log, message or whatever.
My GUESS, considering this strange difference between the two public keys, is that Linux uses a wrong/incompatible method.

Larsa · Tue Feb 13, 2024 12:41 am

I forgot to mention that the Wireguard endpoint in the Mikrotik also needs to match the network addresses of the received packets. Even if the Linux box is using the correct keys, ROS will simply discard the packets if the "allowed addresses" do not match the Linux address. You can enable WireGuard logging to check addresses, etc., by enabling logging topic=Wireguard.

Mesquite · Tue Feb 13, 2024 12:44 am

I suspect the config is wrong on both wireguard and linux.

Larsa · Tue Feb 13, 2024 12:51 am

@resca; since you only have one peer on the Mikrotik, ensure there isn't already an active session on it. If the handshake of the peer is under two minutes there is likely an active tunnel.

vawtech · Tue Feb 13, 2024 9:51 am

Hi, are you sure the config is correct? I' ve just set up a wireguard vpn and I am using it on linux with no problem. First of all you do not need to have the peer private key on the mikrotik. I use kubuntu, so I use the KDE interface, but I report my configuration which should be the same despite of graphical interface.

The ip of my machine for wireguard is 10.0.1.40.
PrivateKey= the one generated on my machine with wg genkey | wg publickey command

In the "peers" section:
Publickey: the one from mikrotik
Allowed ips: 0.0.0.0/0
Endpoint address: domain name of my office
Endpoint port: obviously the port of my office firewall I am connecting to

In IPV4 section
method: manual
Address: 10.0.1.40
Netmask: 255.255.255.255
Gateway: 0.0.0.0

resca · Tue Feb 13, 2024 2:45 pm

Hi, are you sure the config is correct?

No, I am quite sure it isn't!

First of all you do not need to have the peer private key on the mikrotik.

Yes, I do not need, and this is possibly the point!
Even if I don't need, when I configure the peer, Mikrotik is so kind to prepare for me a sample of the configuration file to copy on the client and it contains the private and the public key (and other stuff). I just copied this file to two Android phones and they both work. So, my guess (correct me if I am wrong) Mikortik generates a random private key and the related public key so I don't need to generate anything on the client (linux box, android or whatever). Exactly as I had to generate nothing on the phones.

I made TWO tests: 1) Generate the public key from the private key: the result is not the same key. 2) Ignore the file generated by Mikrotik, generate a pair of keys on linux and place the public key in Mikrotik's peer. In both cases, the incoming "Handshake Initiation" is accepted and then ignored.

Do you confirm you discard the Mikrotik generated sample and 1) Generate Private and related Public keys on linux, place the public in the peer and that is all? This doesn't work for me.

My linux configuration is:
PrivateKey = ....
Address = 10.3.53.2/24
DNS = 10.3.53.1
ListenPort = 13231

[Peer]
PublicKey = ....
AllowedIPs = 0.0.0.0/0
Endpoint = 1234567890.sn.mynetname.net:13231

And Mikrotik configuration is
>interface/wireguard/print
Flags: X - disabled; R - running
0 R name="wireguard1" mtu=1420 listen-port=13231 private-key="...."
public-key="...."
> interface/wireguard/peers/print
Columns: INTERFACE, PUBLIC-KEY, ENDPOINT-PORT, ALLOWED-ADDRESS
# INTERFACE PUBLIC-KEY ENDPOINT-PORT ALLOWED-ADDRESS
0 wireguard1 .... 13231 0.0.0.0/0

You can enable WireGuard logging to check addresses, etc., by enabling logging topic=Wireguard.

As I mentioned before, /system logging add topics=Wireguard produces NOTHING: this is the reason I insist the packet is accepted and then discarded. IF there is a way to see the reason Mikrotik discards the incoming packet (wrong key, wrong IP, whatever) it is welcome.

Larsa · Tue Feb 13, 2024 8:07 pm

To check how the raw Wireguard packets might appear on the Mikrotik, use Winbox by going to "Tools -> Packet Sniffer". Select the WAN interface and port 13231. Click on [Apply], [Start], and finally the [Packets] button to open the window where the tracing is displayed. Remember to press the [Stop] button to end the capture when you're done.

On the Linux box, use: "tcpdump -i -name-of-wireguard-interface port 13231" to trace the packet flow. You might also use "nc -v -u 1234567890.sn.mynetname.net 13231" to send udp packets. One UDP packet is sent for each [enter].

resca · Tue Feb 13, 2024 9:47 pm

To check how the raw Wireguard packets might appear on the Mikrotik, use Winbox by going to "Tools -> Packet Sniffer". Select the WAN interface and port 13231. Click on [Apply], [Start], and finally the [Packets] button to open the window where the tracing is displayed. Remember to press the [Stop] button to end the capture when you're done.

On the Linux box, use: "tcpdump -i -name-of-wireguard-interface port 13231" to trace the packet flow. You might also use "nc -v -u 1234567890.sn.mynetname.net 13231" to send udp packets. One UDP packet is sent for each [enter].

Did you understand that it is one week that I am performing ALL these very elementary debugging steps?
How do you think I could write "I see a packet exiting the linux ... reaching the filter ... being accepted" without those tools?
Instead of nc, I used netcat -v -u -z 1234567890.sn.mynetname.net 13231 does it matter?

Larsa · Tue Feb 13, 2024 11:05 pm

I believe that packet-level tracing provides an excellent starting point to ensure that packets reach their destination without obstacles along the way. However, it's up to you to choose the tools that best fit your situation.

A tip to improve your chances of getting help in this user forum is to attach a complete export of your MikroTik configuration, along with relevant parts of your Linux environment, such as Wireguard.conf, iptables, or any firewalls in use. It's also helpful to provide a brief network typology, including whether your connection is public or private, as well as other details like WAN connections, and so forth.

Btw, netcat is the same as nc, so it shouldn't matter.

Mesquite · Tue Feb 13, 2024 11:10 pm

Too funny Larsa, I wonder how many times that needs to be stated, to "See the Light" regarding ensuring first posts are relevant .

Death by a 1000 cuts LOL.. I simply dont help those that dont post the required information anymore. I tried to make it better but failed.

Larsa · Wed Feb 14, 2024 12:37 am

@resca: Have you checked the handshake status of the Wireguard peer using WinBox? When everything is okay, the handshake timer will increment up to two minutes and then start over again. If the handshake is okay, you might have other problems like routing or a firewall blocking the payload traffic.

resca · Wed Feb 14, 2024 9:04 am

Too funny Larsa, I wonder how many times that needs to be stated, to "See the Light" regarding ensuring first posts are relevant .
Death by a 1000 cuts LOL.. I simply dont help those that dont post the required information anymore. I tried to make it better but failed.

I worked in customer support for 40+ years: X25, SNA, UDLC, Uniscope, TCP, OSI, etc. I was between the field engineers and the producer of software/hardware. At that time, bugs were very, very, usual: problems had to be reproduced and clearly reported to developers! I also got prizes for my great support skill. Unfortunately I am not an expert in today's protocols, even if I try to learn day by day. I think I know how to supply all the needed information. It is simply annoying for support people to read huge quantity of useless information so I try to focus to the basics and supply more info (that, may be, I cannot guess they exist) as soon as the expert says it is required.

Of course, while I am not expert in this particular scenario, it MIGHT be enough to say: I feed the mikrotik produced client configuration to both Android and Linux. The first works, the latter doesn't and MAY BE an expert can say: yes, we know this is due to that. Very very easy.

ALL, I say again ALL the requests by "Larsa" are of already supplied data and suggest to use the tools that I already used: no value added. The only appreciable contribution is by "vawtech" that, at least, supplied a configuration and confirms wireguard may work between Linux and Mikrotik.

No one ever answered on the main question: how can I trace/log/log why a packet accepted it not passed to wireguard. No one!
What is the missing required information: The model of the router? The color of the Fedora 39 PC? The brand of the Android phone that connects with no problem? Let me know, please!

Mesquite · Wed Feb 14, 2024 1:19 pm

From the little revealed:

Looking at your linux settings.
- missing keep alive

Mikrotik. Allowed IPs 0.0.0.0/0 is wrong.

Best to post complete MT config minus sensitive bits.
I ignored the post thus far due to this omission. The problem is not yours its the lack of guidance provided by the site, to ensure new posters
were well prepared to make their first post.

jaclaz · Wed Feb 14, 2024 2:30 pm

Judging from the number of results for a google search for github projects related to mikrotik wireguard:
http://www.google.com/search?hl=it&sour ... +wireguard
you must be not the first one to have difficulties in properly configuring wireguard (from Linux).

You could try this one (bash):
https://github.com/IgorKha/wireguard-mikrotik
and see if it creates a different setup from the one you now have.

A non-written note says that it won't work on orange or yellow Fedora 39 PC's (not on tuesdays or wednesdays, unless there is a full moon and the year is a leap one).

Larsa · Wed Feb 14, 2024 3:25 pm

Here is a link to Anav's user guide "Wireguard Success For The Beginner" which might come in handy..

resca · Wed Feb 14, 2024 4:14 pm

From the little revealed:

Looking at your linux settings.
- missing keep alive

Mikrotik. Allowed IPs 0.0.0.0/0 is wrong.

Best to post complete MT config minus sensitive bits.
I ignored the post thus far due to this omission. The problem is not yours its the lack of guidance provided by the site, to ensure new posters
were well prepared to make their first post.

I thought the MT configuration I posted on Tue Feb 13, 2024 1:45 pm was what is needed. Is that not enough? Or you mean that the full configuration of MT is required? You can fid it here: http://www.rescas.eu/listing/download/public/pippo.zip. That said, while android works fine, I am pretty convinced the MT side is OK and the problem must be on the linux side. In other words, once a very similar packet comes from Android (two different android phones) and it is passed to wireguard and a very similar one is not passed, something in the packet itself must be wrong, so no need at all to investigate on MT!

Please note that, to avoid to disrupt the working connection I use with Android, I configured a second wireguard interface on port 13232 dedicated to linux but my final goal would be to connect just to only one with all my devices. Of course not simultaneously!

Looking to change keepalive and Allowed IPs on linux. Thanks for the suggestion.

Mesquite · Wed Feb 14, 2024 4:30 pm

Yes full config please.
Also 0.0.0.0/0 is fine on the android but NOT on the mikrotik

resca · Wed Feb 14, 2024 5:21 pm

Yes full config please.
Also 0.0.0.0/0 is fine on the android but NOT on the mikrotik

This is the full config.
http://www.rescas.eu/listing/download/public/pippo.zip
... or you need it pasted in full text into a code block (quite long!)?

Can you explain, in few words, while android connects fine, why the present configuration may be wrong? Shouldn't MT be unaware if the client is a phone, a linux or a windows PC?

Mesquite · Wed Feb 14, 2024 8:55 pm

As I already stated, putting 0.0.0.0/0 in the MT ( server for handshake is a bad idea ), even worse you did it for both your clients.
(also remove the endpoint port as well):
Error in orange, remove in green.

From:
/interface wireguard peers
add allowed-address=0.0.0.0/0 client-address=0.0.0.0/0 client-endpoint="" \
client-listen-port=13231 disabled=no endpoint-address="" endpoint-port=\
13231 interface=wireguard1 preshared-key="" private-key=\
"============================================" public-key=\

add allowed-address=0.0.0.0/0 client-address=0.0.0.0/0 client-endpoint="" \
client-listen-port=13232 disabled=no endpoint-address="" endpoint-port=\
13232 interface=wireguardX preshared-key="" private-key=\
"============================================" public-key=\

TO:
Your work after thinking about it.

One should understand the wireguard routing process.
For outbound traffic or return traffic to a peer ( entering the tunnel ),
1. the router needs to ensure
a. that your firewall rules allow traffic to enter the tunnel
b. that there is a route how to get to the tunnel

2. Wireguard processing reviews the traffic trying to enter the tunnel and attempts to
a. match the destination address of the traffic to an existing peer identified address on the allowed IPs.
b. send the traffic down that peer.

It starts at the first peer identified and works its way down

FOR INBOUND TRAFFIC, not so difficult (exiting the tunnel and the local router),
1. the router needs to ensure
a. that firewall rules allow this traffic to go where it needs to go. lan in forward chain, config in input chain

2. Wireguard processing simply acts as a filter here, and checks if the source address is on the allowed IPs.....

+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Now based on the outbound traffic, you should be able to tell me why your config is wrong and what the correct entry for each rule should be.

Larsa · Wed Feb 14, 2024 9:32 pm

I had a quick glance at the configuration, though only for WireGuard and the firewall. Everything seems to be in order, and considering that the mobile devices are working, there probably isn't any issue with your RB2011. Thus, unfortunately you'll have to continue troubleshooting with your Linux box, the local network, or perhaps even your ISP.

Here are some thoughs and suggestions for further troubleshooting:

- Keep in mind that with MikroTik ROS, having 0.0.0.0 as the "allowed IP", you can only have one connection per "peer". As a suggestion, create a dedicated WireGuard interface and peer specifically for testing with your Linux box. Could it possibly be "WireGuardX" that you're using for this?

- Is the ingress traffic for the Linux box working? Are you receiving any traffic, for example, with tcpdump -i wg-interface 'UDP port xxxx'?

- Does it make any difference if you connect the Linux box to internet using your Android?

- When connecting the Androids compared to Linux, what is the status of the "handshake" on the RB2011?

- Try connecting to another Linux box using the same keys as on RB2011. Does it work?
--

EDIT:
1. Next time you perform an export, you can simply use "/export" without any other flags.
2. OT - Welcome back Anav!

Mesquite · Wed Feb 14, 2024 10:18 pm

2. Only because Ive signed in on firefox and to lazy to sign out and sign back in again LOL

resca · Thu Feb 15, 2024 1:13 pm

I had a quick glance at the configuration, though only for WireGuard and the firewall. Everything seems to be in order, and considering that the mobile devices are working, there probably isn't any issue with your RB2011. Thus, unfortunately you'll have to continue troubleshooting with your Linux box, the local network, or perhaps even your ISP.

Yes: from the very beginning I was convinced the problem is ONLY in the Linux box. I opened this post while I was in the hope someone had already faced the problem and/or could give generic help.
By the way @Mesquite says my configuration is wrong... I followed his suggestions and now I have:

/interface wireguard
add listen-port=13231 mtu=1420 name=wireguard1
/interface wireguard peers
add allowed-address=10.3.53.2/32 interface=wireguard1 private-key="xxx" public-key="xxx"

And Android still works, so I think my configuration was "not perfect, with some dummy data" but not "wrong".

- Keep in mind that with MikroTik ROS, having 0.0.0.0 as the "allowed IP", you can only have one connection per "peer". As a suggestion, create a dedicated WireGuard interface and peer specifically for testing with your Linux box. Could it possibly be "WireGuardX" that you're using for this?

Fixed. Yes, it was WireGuardX, but now I am back to one WireGuard interface and I am testing only on that one. I have some configuration backups and I am no longer worried to break my working Android connection.

- Is the ingress traffic for the Linux box working? Are you receiving any traffic, for example, with tcpdump -i wg-interface 'UDP port xxxx'?

Ok, may be my environment was not detailed: that linux box is connected via 5G network to a "mobile phone" provider (Iliad) and can access internet (web, email, etc.) with no problem. The MT is connected to a fiber provider (TIM) and, as well, can access the internet. The mobile phones are connected to the same 5G network. I NEVER try to connect both phone + linux to wireguard.

So, the answer is NO, the ONLY packet (on my WG port) I see is the OUTGOING "Handshake Initiation" packet. I see that exact same packet INCOMING in MT (packet sniffer) and it triggers my firewall ACCEPT rule (I have logging enabled). Then nothing else. In contrast, with the phone, after the packet passes the accept filter, I see the in and OUT counts on WG interface grow and, finally, I see MANY outgoing (packet sniffer) packets.

My guess is that packets are someway ignored by WG. WHY? Unfortunately I don't know if there is a way to see the reason. WG logging shows NOTHING. Loog shows NOTHING. Should MT show what it doesn't like, I could try to fix it in the linux side!

- Does it make any difference if you connect the Linux box to internet using your Android?

Sorry, I think I don't full understand the question. If you mean place one working phone in tethering, connect to it with Linux and try WG, yes, I tried, no it behaves exactly in the same way.

- When connecting the Androids compared to Linux, what is the status of the "handshake" on the RB2011?

Where can I see the handshake? By the way, in WinBox -> Wireguard -> I see Tx and Rx count grow with Android and stay at 0 (after reset, of course) with linux.

- Try connecting to another Linux box using the same keys as on RB2011. Does it work?

You mean configure an other linux box as WG server? Not easy/fast to do in my environment but I will plan to do that in the future: very clever idea!

1. Next time you perform an export, you can simply use "/export" without any other flags.

Wilco. You now have the present configuration here: http://www.rescas.eu/listing/download/public/pippo.zip

mozerd · Thu Feb 15, 2024 2:07 pm

When testing your Linux WireGuard Config following link provides you with excellent clues

Mesquite · Thu Feb 15, 2024 2:50 pm

LInux firewall getting in the way?

Larsa · Thu Feb 15, 2024 3:42 pm

When testing your Linux WireGuard Config following link provides you with excellent clues

I absolutely love the format of the Pro Custodibus blogs!

A brilliantly elaborate pedagogy using images in combination with a well-thought-out flow of explanatory text is among the best resources you can find on the internet. This is how I think User Guides and examples should look like on the Mikrotik help page.

EDIT:
@resca:
- There are a bunch of very good articles in the link above regarding Wireguard's internal architecture and various practical use cases.
- Are you absolutely sure there isn't a typo when you copied the keys from the Android to the Linux box or perhaps swaped public/privat key with each other? It happened to me a number of times.
- Maybe you can perform a local test by setting up a new Linux box (using a virtual machine for example) on the same network as the other linux and use the same keys as you have on the RB2011?

mozerd · Thu Feb 15, 2024 5:30 pm

I absolutely love the format of the Pro Custodibus blogs!

A brilliantly elaborate pedagogy using images in combination with a well-thought-out flow of explanatory text is among the best resources you can find on the internet. This is how I think User Guides and examples should look like on the Mikrotik help page.

@Larsa, "A brilliantly elaborate pedagogy " .... I could not have said better myself .... ]Pro Custodibus Team are TRUE masters of guidance

resca · Thu Feb 15, 2024 6:46 pm

When testing your Linux WireGuard Config following link provides you with excellent clues

Yes, I am between B1 and B2. I am afraid English is not my mother tongue and I am not able to explain something from the very beginning:
-The handshake packet is sent by Linux and it is received by MT: i see it in the tcpdump on linux, in MT Sniffer.
-The packet is accepted by this filter and the message is in the log:

add action=accept chain=input comment="*** WireGuard ***" dst-port=13231 log=    yes log-prefix="rsc WIREGUARD VPN UDP" protocol=udp

-At this point the message is lost. There is no further log, message o whatever.

So, I cannot imagine how can - at this stage - a firewall/masquerade rule in Linux can cause the problem: the firs packet is sent, nothing comes back. At the same time, while a formally identical packet (from android) is processde by wireguard on MT, the problem must be in the packet itself: something is wrong. What may be wrong: key, IP and ? May be something else? You know? As far as I know, bot IP and Key are correct but, as I said at the very beginning, a public key computed from linux is NOT the same of the public key computed by MT. I strongly guess I need a parameter [in linux] to alter this.

-Packet that is answered and starts the successful connection (android):

Frame 2: 190 bytes on wire (1520 bits), 190 bytes captured (1520 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 37.161.45.106, Dst: 82.54.167.114
User Datagram Protocol, Src Port: 18645, Dst Port: 13231
WireGuard Protocol
    Type: Handshake Initiation (1)
    Reserved: 000000
    Sender: 0x3e73b8ff
    Ephemeral: Cso1+7+SM0xqi9PSbrYfbqmk95Nc94negMEoIadh7jk=
        [Has Private Key: False]
    Encrypted Static
    Encrypted Timestamp
    mac1: ea1db43525f35fd49dc3ece66ea67287
    mac2: 00000000000000000000000000000000
    [Stream index: 1]
    [Response in Frame: 3]

Packet that is not answered (linux):

Frame 1: 190 bytes on wire (1520 bits), 190 bytes captured (1520 bits)
Ethernet II, Src: 00:00:00_00:00:00 (00:00:00:00:00:00), Dst: 00:00:00_00:00:00 (00:00:00:00:00:00)
Internet Protocol Version 4, Src: 37.161.45.106, Dst: 82.54.167.114
User Datagram Protocol, Src Port: 18645, Dst Port: 13231
WireGuard Protocol
    Type: Handshake Initiation (1)
    Reserved: 000000
    Sender: 0x4b775352
    Ephemeral: 3zxzPOAfrZUs14W2tE7Ztaj2PAX8o0+E7qbeZMMityw=
        [Has Private Key: False]
    Encrypted Static
    Encrypted Timestamp
    mac1: dd28c99cd37f4f51d4f3818e4852d047
    mac2: 00000000000000000000000000000000
    [Stream index: 0]

At this point, I hope to find a forum for Fedora problems but I would like to have something on MT to know WHY the packet is ignored so I could make a more specific request.

Larsa · Thu Feb 15, 2024 10:13 pm

To begin with I think your English is almost perfect, so there are absolutely no problems understanding what you mean.

Back to business:

The standard system log in RouterOS for Wireguard lacks logging at the packet level so you need to use WinBox "Packet Sniffer" to trace the Wireguard ingress/egress traffic.

If the Linux machine's interface isn't directly connected to the internet, I suggest you deactivate any firewall, ZeroTier, Tailscale, Docker or anything else that might affect the network traffic. After that's sorted out, check that iptables are completely empty and that the routing table doesn't have any strange entries. FYI, having two firewalls in sequence might cause problems if "double-NAT" occurs.

Just to be on the safe side regarding how to manage the Wireguard keys: If you want to connect Linux to the same Wireguard peer that your Androids use, you must have an exact copy of the mobile's private and public keys in the Linux Wireguard configuration. If you instead use Linux genkey/pubkey, you must update the corresponding keys in Mikrotik's Wireguard Peer configuration.

resca · Fri Feb 16, 2024 9:51 am

The standard system log in RouterOS for Wireguard lacks logging at the packet level so you need to use WinBox "Packet Sniffer" to trace the Wireguard ingress/egress traffic.

I used it and I see the incoming "Handshake Initiation" packet coming in.

If the Linux machine's interface isn't directly connected to the internet, I suggest you deactivate any firewall, ZeroTier, Tailscale, Docker or anything else that might affect the network traffic. After that's sorted out, check that iptables are completely empty and that the routing table doesn't have any strange entries. FYI, having two firewalls in sequence might cause problems if "double-NAT" occurs.

Here is why I seriously doubt my writing is understandable: IF the "Handshake Initiation" packet reaches the MT, how can "any firewall, ZeroTier, Tailscale, Docker or anything else" play a rule? If MT would answer to "Handshake Initiation", yes, I could guess something in the return path that blocks it, but I cannot imagine anything in the present scenario.

Just to be on the safe side regarding how to manage the Wireguard keys: If you want to connect Linux to the same Wireguard peer that your Androids use, you must have an exact copy of the mobile's private and public keys in the Linux Wireguard configuration. If you instead use Linux genkey/pubkey, you must update the corresponding keys in Mikrotik's Wireguard Peer configuration.

Yes, that is very clear and is what I did from the beginning.

Back to sniffer tool, I see the incoming packet; then I see it accepted by the filter; can I sniff between firewall filter and wireguard? Is there something between the filter and wireguard? If it is wireguard itself that refuses the packet, shouldn't I see any errors logged somewhere? May be I do not log enough? May be /system logging add topics=wireguard action=echo is not enough? It shows nothing!

By the way, I subscribed a Fedora Forum and I am starting to get some suggestions/answers, but not solved yet. Of course I will post the solution ... if I find it!

resca · Fri Feb 16, 2024 10:13 am

UPDATE: the present opinion of Fedora experts is that the Handshake Initiation packet is encrypted ... twice!

resca · Fri Feb 16, 2024 6:24 pm

FIXED!!!

The idea from the Fedora forum (double encryption) was not winning!

The problem was the wrong Private Key in linux wg0.conf.

Basically, while the mikrotik produced configuration file (and QR code) is applicable for Android, it doesn't work for Linux. Once as Private Key I used the same one I use in Android - and verified with pubkey on linux generates the same public key as on android - it works fine!

By the way, it would have been more simple if MT had logged somewhere "key mismatch" or something the like.

Thanks everybody for the time lost giving help to a dumb novice!

patrikg · Fri Feb 16, 2024 8:19 pm

Now you can press this bar to mark your thread as solved.

Mesquite · Fri Feb 16, 2024 10:05 pm

Makes no sense to me.

Linux device should produce both a private key and a public key.
The public key should be placed in the peer settings on the mikrotik router
and the Mikrotik public key should be placed on the peers settings of the linux machine.

Note: Even stupid windows generates a public key from its private key.
The private key is not required for any of the transactions, its simply not used, its the public keys that are checked.

Thus the statement that linux had the wrong private key makes no sense to me.
If you didnt use the private key and public generated key from your linux device in creating the wireguard interface, thats an error on your part.
To be fair though I have not tried to use the MIkrotik to generate anything for another device, so there may be some tricks there.

Even my iphone wireguard creates its own private key and generates its own public Key to put in the peer settings on my mikrotik.

Another note is that wrieguard crypto routing is designed for peer devices to have their own unique public key but I assume that
if all peer devices had same public key, they would still match up and traffic encryption decryption would occur and are still differentiated by allowed IPs,
when the router selects peer for traffic and with allowed IPs traffic to enter the tunnel, or allows peer to exit the tunnel

resca · Fri Feb 16, 2024 10:15 pm

Linux device should produce both a private key and a public key.

In this case, there is no way to have just one peer for both Android and Linux.

Thus the statement that linux had the wrong private key makes no sense to me.

Linux had the wrong private key while I placed it trusting the configuration file produced by Mikrotik.

I wrongly supposed that I could do the same steps for Android and linux and this was not true.

If you didnt use the private key and public generated key from your linux device in creating the wireguard interface, thats an error on your part.

Yes, it was my fault due to the reason above.

Larsa · Fri Feb 16, 2024 10:33 pm

FIXED!!!

Thank you for the feedback and great to hear you’ve managed to locate the root cause. Even though it might be challenging when things don't work as expected, you usually learn a whole lot during the troubleshooting process.

Have a nice weekend!

Wireguard from Linux not working [SOLVED]

Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working [SOLVED]

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Re: Wireguard from Linux not working

Who is online