Wireguard DNS error.
Hello, I have a problem with Wireguard DNS proxy. Issue looks like: Trough DNS proxy $ host presence.teams.microsoft.com. Host presence.teams.microsoft.com not found: 2(SERVFAIL) Trough the upstream DNS server: $ host presence.teams.microsoft.com. 10.10.10.1 Using domain server: Name: 10.10.10.1 Address: 10.10.10.1#53 Aliases: presence.teams.microsoft.com is an alias for presence.services.sfb.trafficmanager.net. presence.services.sfb.trafficmanager.net is an alias for a-ups-presence0-prod-azsc.eastus2.cloudapp.azure.com. a-ups-presence0-prod-azsc.eastus2.cloudapp.azure.com has address 52.114.142.202 Logs from server: time="2021-11-26T02:33:56Z" level=debug msg="dns query: dns query for: presence.teams.microsoft.com.:1:1" file="server.go:70" time="2021-11-26T02:33:56Z" level=error msg="failed lookup record with error: dns: overflowing header size\n;; opcode: QUERY, status: NOERROR, id: 53952\n;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0\n\n;; QUESTION SECTION:\n;presence.teams.microsoft.com.\tIN\t A\n" file="server.go:76" Another error: $ host ocsp2.apple.com Host ocsp2.apple.com not found: 2(SERVFAIL) $ host ocsp2.apple.com 10.10.10.1 Using domain server: Name: 10.10.10.1 Address: 10.10.10.1#53 Aliases: ocsp2.apple.com is an alias for ocsp2-lb.apple.com.akadns.net. ocsp2-lb.apple.com.akadns.net is an alias for ocsp2.g.aaplimg.com. ocsp2.g.aaplimg.com has address 17.253.5.203 ocsp2.g.aaplimg.com has address 17.253.1.201 ocsp2.g.aaplimg.com has IPv6 address 2620:149:a00:f000::5 ocsp2.g.aaplimg.com has IPv6 address 2620:149:a1c:f000::1 time="2021-11-26T02:32:17Z" level=debug msg="dns query: dns query for: ocsp2.apple.com.:1:1" file="server.go:70" time="2021-11-26T02:32:17Z" level=error msg="failed lookup record with error: dns: overflow unpacking uint32\n;; opcode: QUERY, status: NOERROR, id: 18718\n;; flags: rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0\n\n;; QUESTION SECTION:\n;ocsp2.apple.com.\tIN\t A\n" file="server.go:76” How to fix this problem? Please advise. Thank you, --- Andrii Petrenko apl...@gmail.com
Re: [PATCH wireguard-go] conn: linux: fix incorrect endpoint address
Hey Minus, I'm not seeing what could be causing this. Could you triple check that it really is busted on Debian 8? Jason
Re: [Windows Client] Out of date Title scare my users
> nothing in the title just the update tab. If you find that an acceptable compromise, it's fine with me.
Re: [Windows Client] Out of date Title scare my users
Hi Diab, Thank you for the detailed explanation. My suggestion to add a new registry key seemed easy, but I understand a limited number of options is important. From your alternatives : 1) Probably the easiest to implement. It's not my favorite, but it would be better no doubt. 2) I used Network Configuration Operators for everyone because no other option was available. It's not great as you said, but users need to start and stop the VPN sometimes. I can't remove all rights. 3) Do you suggest a "read only" interface ? I looks like the opposite of what I need, the less users see the better. 4) It seems pretty complicate for a small improvement. Like you I'm not fan, but why not if Jason like it. It can but combined with the first option. 5) I like this option, but I supposed it wasn't possible. If it is, a group that can only access to the list of tunnels and start or stop them is a good solution for my environment. Removing Network Configuration Operators rights would be an improvement. To summarize, the option 5 is what I'm looking for from the beginning. But if it's to complicate (or impossible) to do, the first one looks like a good start. Rewording can be done easily and quickly (before a better solution is chosen, if possible). In that case, I indicate that I mainly use the french localization (it explains my poor english language level). Maybe the french version seems more aggressive that the english one? I don't know who leads this language translation, but I suggest him (or her) to change the Windows title "Obsolète" (out of date) to something softer, or nothing in the title just the update tab. Thank for your time too, Bruno ANDRY Le 25/11/2021 à 15:23, lazerl...@thezest.dev a écrit : Dear Bruno, Whilst I understand the frustration that having hundreds of users can cause, I don't believe simply reverting the change [as proposed by Jason] is the correct solution. I've come up with a few alternative solutions, but before I present them I'd just like to give a brief introduction into why I requested that change in the first place. WireGuard on Windows exclusively provides a GUI to users of the Administrators group, as well as a limited GUI to users of the Network Configuration Operators group when the `LimitedOperatorUI` DWORD is set. The latter is helpful for users who wish to separate their personal and administrator accounts (to protect themselves against the plethora of UAC exploits, amongst other security issues) where otherwise the user would have to switch accounts to switch tunnels. However, the GUI shown to Network Configuration Operators lacked any information about updates. This lead to users in such setups to not be informed about any updates unless they switched out to the Administrator account and or kept an eye on the releases online. This is quite a problem as users could be running ancient versions of WireGuard for relatively long periods of time without the knowledge that they are doing so (some users may even assume WireGuard automatically updates). As such, I asked Jason if he could add the ability for non-admins to at least be informed of an update which lead to where we are today. After speaking to Jason "off the mailing list", he stated he wouldn't like to add any more configuration options (via the Registry or within the GUI) nor any metadata to updates so bearing that in mind I came up with a few alternatives: 1) Rewording the update prompt for non-admins to appear less "aggressive". Currently, the prompt is "Please ask the system administrator to update." but this could be changed to something along the lines of "There is an update available. The system administrator will update when necessary." which should reduce most, if not all, users from contacting you unnecessarily. I can throw up a patch for this if Jason agrees. 2) Avoiding users seeing the UI at all, where unnecessary. If your users do not need *control* of the WireGuard configuration, then avoiding showing them the UI altogether could be an option. I don't know your system as well as you do, of course, so I can't assure that this solution is valid. However, having hundreds of users as Network Configuration Operators sounds a little "worrying" to me. 3) Showing an even more limited UI for unprivileged users. If the users still need some form of UI, then an even more limited UI could be presented to users not part of the Administrators nor the Network Configuration Operators groups. This would lack any form of control, and could still be under the same `LimitedOperatorUI` Registry DWORD, or not if is deemed "safe enough for the masses". If it is, you could say the semantics refer to "Limited [User or Network] Operator UI". 4) Updates could be hidden from the UI for N days after an update or N updates (preferably two in this case, so that it doesn't pile up) for Network Configuration Operators. This provides you [and any
Re: [PATCH wireguard] wireguard: selftests: refactor the test structure
On Tue, Nov 16, 2021 at 03:35:40PM +0100, Jason A. Donenfeld wrote: > Hi Hangbin, > > I don't know how interested in this I am. Splitting things into two > files means more confusing maintenance, and categorizing sections > strictly into functions means there's more overhead when adding tests > (e.g. "where do they fit?"), because the categories you've chosen are > fairly broad, rather than being functions for each specific test. I'd > be more amenable to something _entirely_ granular, because that'd be > consistent, or what we have now, which is just linear. Full > granularity, though, has its own downsides, of increased clutter. > Alternatively, if you'd like to add some comments around the different > areas to better document what's happening, perhaps that'd accomplish > the same thing as this patch. > Hi Jason, May be my timezone is not very fit for yours. So I will copy my IRC replies in the mail to moving on our kselftest topic. The reason I did this patch is because I want to make the test more clear and able to run each test case separately. My though is to make the wireguard test looks like tools/testing/selftests/net/fib_tests.sh.(Of course this could be discussed). Because the linear structure makes reader hard to find out what test it does. The function name in my current patch is also a little broad to look, which could to be updated. After updating, I'd like to make the test has 2 parts, functional tests and regression test. Functional tests for big part of function tests and regression test for small specific issues. BTW, one downside about current linear structure I think is that when someone want to add a new test, he need to read through the whole test to know that kind of topology at last. But with function structure, when we want to add a new test. We can just do like: 1. set up basic topology 2. configure to specific topo for testing, or just skip the first step and configure to specific topo directly. 3. Do test 4. Clean up environment or reset to basic topology I think this would make adding new test case easier. What do you think? Thanks Hangbin
Re: [ANNOUNCE] wireguard-freebsd snapshot v0.0.20211105 is available
I've done some preliminary tests with the new if_wg kernel module on amd64 with freebsd 13-p4 and 14. It works fine AFAICT. My previous issue's with wireguard-freebsd are also resolved. Good work! Thanks Peter
