How can i log client/roadwarrior events (connect/disconnect times, failed connects, connection errors and such)? If there are no built-in functions/packages would it be possible to use port sniffers or something like that as a workaround? Something to see what's going on on the network would be great.
That's what I use.
Also the wg program can be ran to keep track of the last handshake and data transferred for each peer.
There is no such thing, your client log may have this.
Not sure what you mean here. Do you mean someone attempting to alter the encrypted packets in transit?
You know it's just an encrypted tunnel, correct?
Which port sniffer do you use exactly? If i reckon correctly there is nothing like fail2ban for OpenWrt.
The reason for logs are mainly to see if ppl with weak or roaming connections hammer/login too frequently or if someone constantly tries to login accidentally with wrong credentials or something like that. I also don't feel all too comfortable to let an open port unwatched.
I use softflowd like on any other interface. I'm not sure that I would term the software as a "port sniffer" though.
Sniffing the udp port would yield encrypted traffic; but will identify the current source IP of the far end.
- I'm lost on what this has to do with "event logging" in Wireguard. Are you trying to block devices you generated key pairs for?
- Perhaps you should remove their public key from your config if/when this is ever an issue.
I think you're somewhat unclear on how Wireguard works. The exchange of the proper keys is the "login" ...consider it more like an "always-on connection."
Thanks. Will take a look.
Its not about intended scenarios. More about things that go wrong. Lost/stolen public keys and such. Things that people didn't notice.
In an ideal world this might work. But if you have a higher count of clients things don't always work as expected.
Its probably too early atm to use it for more than very small private networks.
1 Like
You can't do anything with a stolen public key. You have to exchange keys with the trusted far end. That's the point of public key cryptology.
Practically, you just have to exchange one key (e.g. as in openvpn) as with this one key a connection can be set up to allow passing the other key (with fingerprint or whatever confirmation from the user).
And that's somehow not intended or working in Wireguard atm. When i set up a private key only it passes my(!) private/public key pair with the QR Code to the client (Android). I don't think that's right. What's that QR Code for then?
When i create an additional peer i get "QR Code syntax error in peer" on the client. Pffff.....
And i always have to reboot the machine to have the changes be effective. That's annoying as well.
I'm struggling if i should use it at all...
Your description is extremely different from how Wireguard actually works.
You must pre exchange keys (MANUALLY) using this software.
There is no "login" or automated key setup.
Rebooting to apply config has been fixed in Snapshot. It will be ready for version 19 release.
Possible. That's probably the price for a small code base. I think i can live with it.
Its just that QR Code generator that made me nervous. Its there, it would make life easier but it doesn't work or it's my fault (whatever...). I think i will try it the manual way first.
I'm on r10099 (x86_64, updated yesterday) and its not fixed here.
- Did you install the package that makes the QR Codes work?
- Regarding reboot, did you save/apply or run /etc/init.d/network reload
BTW...I considered the QR process a manual exchange.
Yes, and it does work if you do not define/create a peer (just the upper part with the private key). The QR Code was somewhat smaller if i reckon correctly and it passed the servers private/public key pair. That's probably not correct. The private key should never be exposed i guess. And as i added a peer the QR Code didn't work anymore (syntax error in peer).
No, not tried yet. Will test that next time.
Edit: 'reload' didn't help but 'restart' shows the new public key now on 'wg'.
1 Like
OK, I understand now. You say it should only have the Public key of the OpenWrt interface (I tend to believe that)...you say it has both...that may be why another user has an issue...
I've never tried the QR code...I've always copied/pasted or uploaded a text file to the peer. I'll have to test and reproduce your issue soon...
1 Like
OK @HectoPascal, I've tested this QR Code thing. It actually provides the entire config for the OpenWrt side, including peers and the OpenWrt's private key. This is not helpful to setup a peer device.
Ok, i hope it will make it into v19.
Rebooting to apply config has been fixed in Snapshot. It will be ready for version 19 release.
I have the same issue on release branch 19.07 and master.
If I change the uci peer config, then this will not get applied. A reboot or a /etc/init.d/network restart helps. I think that hast todo with the netifd service. Netifd does only reload the config if an interface section is changed but we changed only the related wireguard section tpye.
So why do you think that was fixed in snapshot or 19 release.
Could you point me to source change?
Is this knowen by the wireguard proto maintaner?
This is supposed to work. What issue are you having?
???
The problem is that I do this on the LuCI network page. And on save&apply the /etc/init.d/network ist not restarted only netifd restarts the deticated interface on change.
I thought wireguard does have a package maintainer so the issue is known! But apparently not.
I konw the repository of openwrt on github. I thought you knew the commit where the change was made that fixed the problem you were talking about in your message above.
What is the issue with that, are you saying WG is not working for you on an interface restart?
The comment I made above was regarding a QR code, and the thread is about logging; and I did provide the link. I guess, to be more specific:
https://git.openwrt.org/?p=project%2Fluci.git&a=search&h=HEAD&st=commit&s=qr
The issue you describe was not what the OP had (wanted to log). Perhaps you should make a new thread for you issue. I did do a little searching for more discussion on your reboot problem; and I found this: 18.06.0 - WireGuard issue
I couldn't find where the commit was discussed.
Thank you very much for your research and response.
I will open a new issue after some research.
thanks
1 Like