I set a WireGuard server-client with success, now I'm able to use AdGuard Home and access my network while traveling, but I got suck on something that seems simple lol. I want to be able to see my WireGuard server's log, I tried using logread, but it doesn't show the info I wanna see, it shows a lot of not related info and when I connect to the server on my phone I don't see any registered information. How could I see it? I'd like to see the information when a connection occurs or fails
To run logs, I believe that you need to compile from source and turn on a few options to enable logging.
Since wireguard is stateless, the logs are of less general relevance than they would be in stateful protocols, and you may end up getting log spam as a result since it would generate log entries for more than just a connection/disconnection or success/failure condition.
As far as a connection failure, the scenarios are fairly simple:
- an unauthorized connection that has incorrect cryptographic keys and/or the wrong address will simply be ignored. There will be no response to the host that initiated the connection, thus they will not know that there was even an active Wireguard peer available on the port that they tried.
- this also applies to errors in your own (authorized) connections, but once you have a working configuration, this is not an issue.
- the remote peer is unreachable/down or otherwise blocked. In this case, the connection simply wouldn't be established. The reason may or may not be obvious, but you'll only get limited information from a log (if enabled) because the peer local to you would simply not be able to reach the other side.
- An example of this would be trying to connect when you don't have a general purpose internet connection (i.e. in an airplane with paid wifi available but you haven't paid), or if your connection was blocked by an upstream firewall that was doing DPI and dropping WG packets.
- If one end is unable to connect to the other, the other would be unaware of the connection attempt and there would be no log data to be had anyway.
- If your device is getting connection attempts from unauthorized remote peers, you might be able to see that information in the log on your side, but the connection request would have been unanswered so the remote user wouldn't have gained any information; unless these are connection attempts by you, you don't really need to worry or know about those attempts since they have no real value.
So... with that in mind, you can certainly enable logging (I can't tell you the specifics, but I do know it needs to be done by compiling from source), but it may not be of much/any value except maybe if you are deeply probing from the perspective of a developer or security researcher.
As @psherman states, wireguard is stateless, and for most all intents mute.
Pretty well the best you’ll get can be found in the GUI under Status/Wireguard for the Instance and Peer Details.
That's one of the reasons I want to see those logs, I'd like to see when someone tries to connect to it or brute force it, we all know it is safe, but I am extremely curious as the internet is constantly being scanned and people are constantly scanning IPs seeking vulnerabilities. That's the first time I use plain WireGuard because I was always behind CGNAT, but now I have a unique public IPv4, so I can "expose" or shelf-host my server. Someone on Reddit had a WireGuard server and his log showed some connection attempts from China, Canada, Russia. I thought it was easy to display those logs in OpenWrt, it seemed interesting to read them on my server.
*Sep 3 14:41:16 atl-wg sshd[25895]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=112.85.42.88 user=root *
*Sep 3 14:41:18 atl-wg sshd[25895]: Failed password for root from 112.85.42.88 port 11962 ssh2 *
*Sep 3 14:41:25 atl-wg sshd[25895]: message repeated 2 times: [ Failed password for root from 112.85.42.88 port 11962 ssh2] *
*Sep 3 14:41:27 atl-wg sshd[25895]: Received disconnect from 112.85.42.88 port 11962:11: [preauth] *
*Sep 3 14:41:27 atl-wg sshd[25895]: Disconnected from authenticating user root 112.85.42.88 port 11962 [preauth] *
*Sep 3 14:41:27 atl-wg sshd[25895]: PAM 2 more authentication failures; logname= uid=0 euid=0 tty=ssh ruser= rhost=112.85.42.88 user=root *
*Sep 3 14:41:49 atl-wg sshd[25897]: Received disconnect from 222.186.30.57 port 28207:11: [preauth] *
*Sep 3 14:41:49 atl-wg sshd[25897]: Disconnected from 222.186.30.57 port 28207 [preauth] *
*Sep 3 14:43:07 atl-wg sshd[25903]: Received disconnect from 112.85.42.88 port 50809:11: [preauth] *
*Sep 3 14:43:07 atl-wg sshd[25903]: Disconnected from 112.85.42.88 port 50809 [preauth]*
Source: https://www.reddit.com/r/WireGuard/comments/im3cji/brute_force_attempts/
Compile with dynamic debug set:
https://www.kernel.org/doc/html/v4.19/admin-guide/dynamic-debug-howto.html
Enable debugging while loading the WG module:
dmesg will show the WG logging
2 Likes
Reddit, really?
- The quoted log is of SSH entries. It seem you didn't understand the poster's issue prompting review of the log.
- The server just happened to be running Wireguard, the vulnerable service was SSH.
- Wireguard uses keys, not username/passwords
- Wireguard is silent if the incorrect keys/IPs are presented with the encrypted traffic
1 Like
So security by obscurity is not a reliable method of reducing risk, but in the case of a protocol like wireguard that is not chatty, using a non-standard port might make it significantly less likely that anyone will actually attempt to connect via wireguard to your router. Probes will not turn up any evidence of WG being active on your system, so the odds are really against random hammering (they'd have to manage to get the port number, plus both the private key for their local peer and the public key of your peer, and the preshared key if you're using it, and they'd also have to know the correct address (allowed IPs on your side) for the actual peer that they'd spoof). That's a tall order with vanishingly small probabilities, meaning that I'd guess wg brute-force efforts on private systems (i.e. random addresses on the internet vs attacks against high value targets) are not worth the bandwidth and time to attempt.
That said, aside from the curiosity, what else would you do with the information? Is it worth the effort to build from source for this visibility? And if it ends up causing log-spam, is it worth that aspect (potentially making it difficult for you to see important log information before it rolls off the buffer)?
3 Likes
100% agree with former speakers, that is why it is called debugging, so that is what it is for 
(I used it once for that purpose and it works well)
2 Likes