RE: wireguard-windows: Wireguard does not start a previously activated tunnel from time to time
Hi, > Event 7023, ServiceControlManager: The service "WireGuardTunnel$HOST- > WG2" was terminated with the following error: The requested name is valid, > but no data of the requested type was found. The error message you are mentioning is WSANO_DATA 11004 which is related to DNS resolution problems. Which is kind of expected early in the boot process when the Dnscache service is starting and/or Dhcp service might not yet configured the DNS. I presume changing the Endpoint= lines of peers to contain IPs rather than hostnames could solve your problem. See if it helps. If you can confirm it, maybe we can add some retry on WSANO_DATA in the wireguard-windows. (Personally, I would avoid adding hard dependency on Dnscache and Dhcp services. As there are situations where they can be disabled, preventing the WireGuard tunnel service startup then.) Regards, Simon
RE: WireGuard App on Android allows only one connection simultaneously
Hi, > on Linux multiple connections at the same time are possible, on Windows > also. I don't have a Mac so I can't test there. > > When having two tunnels configured in the Android App, while one is > connected if I connect to the second one, the first one disconnects. > > Is there any reason as why the Android App only allows one connection at > the same time? Unfortunately, this is a limitation of Android OS supporting only 1 (one) VPN connection at a time. Regards, Simon
Re: Incompatibility between wintun.dll and go module
Hi!
The 0.14+ is not binary compatible with 0.13. The API changed considerably:
https://git.zx2c4.com/wintun/diff/api/wintun.h?id=544fdaaf8fb970d9657a59c1fc4c4569de4f2d3e
The wireguard-go repo was adjusted for this API change in
https://git.zx2c4.com/wireguard-go/commit/?id=82d2aa87aa623cb5143a41c3345da4fb875ad85d.
Wintun adapter pools were completely discontinued; however, your stack trace
indicates you are still using an outdated version of wireguard-go calling
wintun.(*Pool).OpenAdapter.
Please, update wireguard-go and update.
Regards,
Simon
-Original Message-
From: WireGuard on behalf of Thomas
Hallgren
Date: Tuesday, 14 June 2022 at 11.32
To: "wireguard@lists.zx2c4.com"
Subject: Incompatibility between wintun.dll and go module
Hi,
We're using the wintun.dll and the go module
golang.zx2c4.com/wireguard/windows v0.5.3 in our product. The dll
initialization fails when upgrading the wintun.dll to version 0.14.1
(or 0.14, it doesn't matter). 0.13 works fine. Relevant stack trace
below.
Thanks for an excellent library. Without it, it would be much harder
to port our product to Windows.
unexpected fault address 0x
fatal error: fault
[signal 0xc005 code=0x0 addr=0x pc=0xe8b29d]
goroutine 65 [running, locked to thread]:
runtime.throw({0x27b93d9?, 0x0?})
runtime/panic.go:992 +0x76 fp=0xc000a393d8 sp=0xc000a393a8 pc=0xce8996
runtime.sigpanic()
runtime/signal_windows.go:261 +0x125 fp=0xc000a39420 sp=0xc000a393d8
pc=0xcfbb05
golang.org/x/sys/windows.UTF16PtrToString(0x240e6a0?)
golang.org/x/sys@v0.0.0-20220209214540-3681064d5158/windows/syscall_windows.go:132
+0x1d fp=0xc000a39468 sp=0xc000a39420 pc=0xe8b29d
golang.zx2c4.com/wireguard/tun/wintun.setupLogger.func1(0xc57590?, 0x0?)
golang.zx2c4.com/wireguard@v0.0.0-20210427022245-097af6e1351b/tun/wintun/wintun_windows.go:53
+0x1c fp=0xc000a394b0 sp=0xc000a39468 pc=0x1f321bc
runtime.call16(0x0, 0x28df468, 0xc000a39538, 0x0, 0x0, 0x10, 0xc000a39790)
runtime/asm_amd64.s:701 +0x50 fp=0xc000a394d0 sp=0xc000a394b0 pc=0xd14530
runtime.callbackWrap(0x7c95ffebc0)
runtime/syscall_windows.go:378 +0x134 fp=0xc000a398b0 sp=0xc000a394d0
pc=0xd04074
runtime.cgocallbackg1(0xd03f40, 0x0?, 0x0)
runtime/cgocall.go:314 +0x2ca fp=0xc000a39980 sp=0xc000a398b0 pc=0xcb4b8a
runtime.cgocallbackg(0xc000583380?, 0x30002?, 0xc000583380?)
runtime/cgocall.go:233 +0x106 fp=0xc000a39a18 sp=0xc000a39980 pc=0xcb47c6
runtime.cgocallbackg(0xd03f40, 0x7c95ffebc0, 0x0)
:1 +0x36 fp=0xc000a39a40 sp=0xc000a39a18 pc=0xd18356
runtime.cgocallback(0xcb464b, 0xd17be0, 0xc0001002c0)
runtime/asm_amd64.s:971 +0xd7 fp=0xc000a39a68 sp=0xc000a39a40 pc=0xd160f7
runtime.systemstack_switch()
runtime/asm_amd64.s:436 fp=0xc000a39a70 sp=0xc000a39a68 pc=0xd13fe0
runtime.cgocall(0xd17be0, 0xc0001002c0)
runtime/cgocall.go:167 +0xab fp=0xc000a39aa8 sp=0xc000a39a70 pc=0xcb464b
syscall.SyscallN(0x7ffc169c3a90?, {0xc000a39b40?, 0x3?, 0x0?})
runtime/syscall_windows.go:538 +0x109 fp=0xc000a39b20 sp=0xc000a39aa8
pc=0xd12de9
syscall.Syscall(0xc000479590?, 0x1a428c8510a?, 0x1a428c8510a?, 0x0?, 0x0?)
runtime/syscall_windows.go:476 +0x3b fp=0xc000a39b68 sp=0xc000a39b20
pc=0xd129fb
golang.zx2c4.com/wireguard/tun/wintun.(*Pool).OpenAdapter(0xc000187800,
{0x27b825c?, 0x1a403910598?})
golang.zx2c4.com/wireguard@v0.0.0-20210427022245-097af6e1351b/tun/wintun/wintun_windows.go:89
+0xad fp=0xc000a39bd8 sp=0xc000a39b68 pc=0x1f3256d
golang.zx2c4.com/wireguard/tun.CreateTUNWithRequestedGUID({0x27b825c,
0x4}, 0x0?, 0x0)
golang.zx2c4.com/wireguard@v0.0.0-20210427022245-097af6e1351b/tun/tun_windows.go:75
+0x4d fp=0xc000a39c50 sp=0xc000a39bd8 pc=0x1f3384d
golang.zx2c4.com/wireguard/tun.CreateTUN(...)
golang.zx2c4.com/wireguard@v0.0.0-20210427022245-097af6e1351b/tun/tun_windows.go:63
RE: Wintun on Windows 11
> The README states that Wintun "is a layer 3 TUN driver for Windows 7, 8, > 8.1, and 10": > https://git.zx2c4.com/wintun/tree/README.md#n4 > > You should add Windows 11 to the list. Thanks. Added. Regards, Simon
RE: Wireguard Windows Client questions
> 1. The documentation implies that if I executed the following command > from a command line "wireguard.exe" that it will start the Manager > Service and show the UI. It then states that calling wireguard.exe > /installmanagerservice is suitable for silent installation but what I > find is that the Management GUI is still activated and shown on the > desktop. > Is there anyway to start the service without the GUI window appearing? > And is there anyway to prevent the UI in the system tray from being > installed? Try wireguard.exe /installtunnelservice mytunnel.conf and wireguard.exe /uninstalltunnelservice mytunnel.conf. > 2. If for any reason the Wireguard peer is not reachable then the > Handshake does not complete. When using the GUI the tunnel is shows > Active but it is the tunnelservice that is active not the connection. Is > there a way to limit the number of handshake retries before giving up on > trying to connect? WireGuard is connection-less. Only after there is a packet for a peer, it'll perform handshake with the peer and sent the packet to it. See it as on-demand connection. Now, if you insist on verifying if the connection is possible over the VPN tunnel, send a ping thru the tunnel and see if the handshake occurs and succeeds. > 3. From time to time the endpoint address of the peer system may have > changed (I do not use a dynamic DNS service) so when trying to connect I > hit the problem described in 2 above. I know what the new endpoint > address is and can set it dynamically using the wg set command and the > connection is then made. I would like to be able to programmatically > save this change without having to manually edit the client config > files. I tried using wg syncconf but get a permissions error because of > the properties around the dpapi config files. > Is there an alternative way to doing this short of deleting the existing > dpapi file and adding a new .conf file and have the manager service > encrypt it but that approach means I need to keep the private key in the > clear somewhere in order to create the new conf file.\ Jason suggested me to add a Scheduled Task to call wg.exe set mytunnel peer pubkey endpoint 1.2.3.4:1 on a few minute basis. It works like a charm when roaming back and forth between local and remote networks. It's way more efficient than deactivating the tunnel, updating config and reactivating the tunnel. > 4. There are 2 option listed under wireguard command line options namely > /managerservice and /tunnelservice CONFIG_PATH - can someone tell me > what they are supposed to do every time I try running one of them I get > an error popup that says - The service process could not connect to the > service controller.wireguard Those options are to be used by Windows SCM when wireguard.exe runs as a service. If you are familiar with programming, you might want to take a look into the embeddable-dll-service folder in the wireguard-windows repo. Regards, Simon
RE: Wireguard Windows Service Issues
Hi, > The problem still is occurring, the service seems to get torn down never > to come back again once the user comes back to the office and connects > back into the main network with ethernet. When the user is on the main > network the VPN host address will not get resolved by DNS by design. We > do not want the user to be on the VPN when they are already on the > internal network. If there's a better way to handle the VPN not > connecting when the non-admin user is on the internal network I'm open > to that too. We use a hostname for VPN server resolution because we use > both IPv4 and IPv6 for host connectivity. When your laptop is connected to the "main network" and boots, the tunnel service will give up on the DNS resolution failure after a few minutes and exit. The manager service will notice that the service is dead and will clean it up. Hence your tunnel service ceases to exist and doesn't get started on the next boot any more. Split DNS is not the right way to prevent WireGuard tunneling of the on-link traffic. On my devices, I keep the VPN tunnel active all the time. Regardless the network the device is physically connected to. You are not using the IP addresses from your main network subnet for WireGuard clients. So, when you connect your laptop physically into the main network, the NICs' on-link route should be preferred over the route added by WireGuards' AllowedIPs. This makes the local network traffic flow directly. But - and very important for seamless roaming - schedule periodic elevated calls of `wg.exe set vpn.domain.com peer endpoint vpn..org:51820`. It's cheap and can be scheduled to trigger every 2 minutes (and immediately after scheduled time is missed). If your laptop is connected on your main network, WireGuard roaming will learn 192.168.99.1 as the peer endpoint. Then you put your laptop to sleep and wake it up at home in a different network. It will continue to use 192.168.99.1 as peer endpoint, but that's no longer correct. Periodic reset of peer endpoint fixes this. > 2022-01-21 14:00:25.385109: [MGR] Starting at boot WireGuard/0.5.3 > (Windows 10.0.19043; amd64) > 2022-01-21 14:00:25.385617: [TUN] [vpn.domain.com] Starting at boot > WireGuard/0.5.3 (Windows 10.0.19043; amd64) > 2022-01-21 14:00:25.392357: [TUN] [vpn.domain.com] SCM locked for 1s by > .\NT Service Control Manager, marking service as started > 2022-01-21 14:00:25.397054: [TUN] [vpn.domain.com] Watching network > interfaces > 2022-01-21 14:00:25.399865: [TUN] [vpn.domain.com] Resolving DNS names > 2022-01-21 14:00:25.640575: [TUN] [vpn.domain.com] Host not found when > resolving vpn..org, but no Internet connection available, sleeping > for 4 seconds > 2022-01-21 14:00:29.648660: [TUN] [vpn.domain.com] Host not found when > resolving vpn..org, but no Internet connection available, sleeping > for 4 seconds > 2022-01-21 14:00:33.657345: [TUN] [vpn.domain.com] Host not found when > resolving vpn..org, but no Internet connection available, sleeping > for 4 seconds > 2022-01-21 14:00:37.672796: [TUN] [vpn.domain.com] Host not found when > resolving vpn..org, but no Internet connection available, sleeping > for 4 seconds > 2022-01-21 14:00:41.682472: [TUN] [vpn.domain.com] Host not found when > resolving vpn..org, but no Internet connection available, sleeping > for 4 seconds The on-boot connectivity detection was unreliable and was removed in https://git.zx2c4.com/wireguard-windows/commit/?id=b75cc38c60e36e1117bb40fd4ac78c44f1aae1f6. If SCM started the tunnel service before Dnscache and other networking services, WireGuard couldn't tell from the Windows DNS resolving response whether the resolve failure is transient or not. This fix has not yet been published, but it will not help your tunnel deactivation on split DNS issue. Best regards, Simon
RE: Wireguard Windows Service Issues
Hi, > From this description, it seems that there's room for improvement. > > It doesn't seem reasonable for the WireGuard service to stop. Log and > perhaps display an error, sure. But stopping seems harsh, and would > prevent other tunnel endpoints from working - not a good user > experience. > > It would seem better for the service to set a timer and retry failures > periodically - many DNS issues are transient. > > It also seems to me that it would be better for the default to be option > 3 - make all tunnels dependent on DNSCache without requiring any > user/admin action. One could condition this on an endpoint being > specified as a hostname, but that doesn't seem worth the effort. Pretty > much any use of a tunnel needs name resolution. Even if your resolvers > are at the other end of the tunnel, starting the client before it's up > is harmless. > > Anyone concerned about DNS snooping on name resolution of the endpoints > can avoid it by using either of the other two options: hardcoded IP in > the configuration, or an entry in "hosts". > > "It just works" seems much more desirable than mystery service stops. A > UI status "waiting for hostname resolution" would be ideal. The DNSCache service is optional on Windows 7/8/8.1/Server 2008R2/2012R2 and may be even disabled. (And the resolution would work just fine.) Since SCM treats all service dependencies as "hard" dependencies, that would render all WireGuard tunnel services fail to start. It's a fairly rare use case, but a demonstration SCM service dependencies must be authored with extreme care. I'd rather suggest pursuing the macOS approach where services don't have any dependencies to force developers engineer their services to sleep and retry until their dependencies get available. As you suggested first. However, WireGuard for Windows already has DNS resolution retrying loop. Maybe it needs improvement? Let's wait to see what OP's log says. Regards, Simon
RE: Wireguard Windows Service Issues
Hi, > I believe there's a bug in the Windows service implementation, if this > issue is by design, it's problematic. > > I have non-admin users were when I initially set them up with wireguard, > I configured it to use the service, using the command: > > wireguard /installtunnelservice "C:\Program > Files\WireGuard\Data\Configurations\vpn.domain.org.conf.dpapi" > > The tunnel worked fine the first time. Then the user reboots the laptop, > or closes it or leaves whatever coffee shop they were at and get > disconnected from the wireless network they were using. When this > happens, for some reason, the wireguard service then gets torn down > never to come back again until I issue the command from my admin account > again. Can you do the wireguard /dumplog > wireguard.log and investigate. > There was an issue with some users initial configuration in that they > could not query hostname via DNS, so that entering the command to > installservice would not even create the service. WireGuard services start early on boot - sometimes even before the DNSCache (DNS Client). If the service can't resolve hostnames used in the config file, it will stop. But it will log this. Resolution to this problem is: - Use IPs rather than hostnames. - Add hostnames you use in your .conf file to C:\Windows\system32\drivers\etc\hosts. - Add DNSCache dependency to the WireGuardTunnel$ service. I personally would pick one of the first two options above. Don't like the idea my laptop is asking a coffee shop's DNS what is my VPN endpoint IP address. > Here's a few notes that might help with understanding. > - Users must have the VPN established before they log into the active > directory servers on the remote network so that they can get all of > their GPO directives. > - Wireguard Service should stay up so that any time a users connects to > any network, the VPN is established immediately after that. > - The Wireguard service should also stay because non-admin users cannot > create a new service I understand. That is exactly how we use WireGuard in our company. > If this issue is how things will stay, and this is not considered a bug, > how would you configure windows non-admin users to tunnel to an > enterprise network before login via WireGuard and to continuously try to > establish the tunnel while the user is not connected to a network? Let me assure you, the behavior you are expecting is definitely pathological. Please investigate the log file why the tunnel service does not persist as it should. Best regards, Simon
RE: Error when connecting from windows client
Hi, > 2021-04-26 14:45:33.382398: [TUN] [Home] Creating Wintun interface > 2021-04-26 14:45:33.519928: [TUN] [Home] [Wintun] CreateAdapter: > Creating adapter > 2021-04-26 14:45:33.828328: [TUN] [Home] [Wintun] SelectDriver: Using > existing driver 0.10 > 2021-04-26 14:45:34.289159: [TUN] [Home] [Wintun] CreateAdapter: > Failed to setup adapter (status: 0x0): The operation completed > successfully. (Code 0x) Your log indicates that the adapter device was created, but has a problem code with a STATUS_SUCCESS problem status. I have reintroduced the problem code check in https://git.zx2c4.com/wintun/commit/?id=2881164bff0e819f6b0b6d5fc5d3a185ecb47457. This should evaluate the Wintun adapter state with better precision. Meanwhile, can you please examine your C:\Windows\INF\setupapi.dev.log file for clues. (Note that a 0x1f/0xc495 problem code/status is normal when Wintun adapter is created early at boot. Hence the STATUS_PNP_DEVICE_CONFIGURATION_PENDING check in the code.) Regards, Simon
RE: Allowing space for packet headers in Wintun Tx/Rx
Hi, > > Looks good to me; thanks. Just need to work out how to cross-build it > > (I can muster up a Windows VM for testing, but *building* on it is > > beyond my tolerance of Windows for now). > > +1 to all that. Don't worry. Once Jason is back, reviews and (hopefully) approves the changes, we shall prepare an official release for you. > > We'll also need to be able to WintunAllocateSendPacket() of the full > > possible MTU, then receive and decrypt into that, and send only the > > actual size of the packet we received. How about this: https://git.zx2c4.com/wintun/commit/?id=03b6cd410c8963d1888966edf31fdc35a4c8b523 Should be backward compatible. Tested with the existing stable wireguard-windows release 0.3.10. > There are two cases worth considering where the packet size could > actually *expand*: > > 1) Some VPN protocols support compression of the tunneled packets. It > would be bad behavior to use this to stuff a packet of >(advertised > MTU) bytes in <(advertised MTU) bytes, but it wouldn't surprise me if it > exists in the wild. We now deal with receipt of larger-than-expected-MTU > packets in OpenConnect in a relatively uniform way: allocate MAX(mtu, > 16384) bytes for packets coming from the VPN (if using TLS transport) or > MAX(mtu, 2048) if using DTLS. > 2) Some VPN protocols concatenate multiple packets into a single > aggregate on the wire. On Linux we can decrypt, truncate, and send to > the tunnel interface without further copying. > > Case (1) can be handled with overallocate-and-shrink. Case (2) is pretty > rare among the protocols that OpenConnect supports, so fallback to > memcpy seems fine. Phew! Thanks. :) Regards, Simon
RE: Allowing space for packet headers in Wintun Tx/Rx
Hi David,This is my proposal:https://git.zx2c4.com/wintun/commit/?id=eebd6aea4f75551f6e847a1d4fff857450bac6e9Awaiting review and zx2c4 approval. Regards, Simon smime.p7s Description: S/MIME cryptographic signature
RE: [Wintun] Does wintun.dll support IOCP API?
> Does wintun.dll support IOCP API? > If yes, how to do it? No. Wintun does not communicate with user space using I/O at all. Please, use wintun.dll API described here https://git.zx2c4.com/wintun/about/ Regards, Simon
RE: Windows Tunnl.dll fails to start as a service.
Hi, > Log Name: System > Source:Service Control Manager > Date: 1/21/2021 9:41:25 AM > Event ID: 7024 > Task Category: None > Level: Error > Keywords: Classic > User: N/A > Computer: MANI-WIN10-TEST > Description: > The ProsimoTunnel_if_cbc2a056dfdc25f7 service terminated with the > following service-specific error: > The system cannot find the path specified. "The system cannot find the path specified." <= is your service path correct? Double check it. Mind the path deflection for WoW64 processes. SCM is always native (x64 on x64 Windows, x86 on x86 Windows...). So, the service path must match the path as a native process would see it. Or is it just the fact that something returns status 2 which is interpreted as ERROR_FILE_NOT_FOUND by the Event Log? > 2021-01-21 10:04:20.181831: [TUN] [if_1ea7d00c23a616b1] Creating Wintun > interface > 2021-01-21 10:04:20.896480: [TUN] [if_1ea7d00c23a616b1] Using > Wintun/0.8 (NDIS 6.83) > 2021-01-21 10:04:20.909065: [TUN] [if_1ea7d00c23a616b1] Enabling > firewall rules > 2021-01-21 10:04:22.126556: [TUN] [if_1ea7d00c23a616b1] Starting > WireGuard/0.1.1 (Windows 10.0.19041; amd64) > 2021-01-21 10:04:22.127580: [TUN] [if_1ea7d00c23a616b1] Watching network > interfaces > 2021-01-21 10:04:22.128604: [TUN] [if_1ea7d00c23a616b1] Resolving DNS > names > 2021-01-21 10:04:22.135234: [TUN] [if_1ea7d00c23a616b1] Creating Wintun > interface > 2021-01-21 10:04:24.156638: [TUN] [if_1ea7d00c23a616b1] Starting > WireGuard/0.1.1 (Windows 10.0.19041; amd64) > 2021-01-21 10:04:24.159365: [TUN] [if_1ea7d00c23a616b1] Watching network > interfaces > 2021-01-21 10:04:24.159365: [TUN] [if_1ea7d00c23a616b1] Resolving DNS > names > 2021-01-21 10:04:24.165375: [TUN] [if_1ea7d00c23a616b1] Creating Wintun > interface > 2021-01-21 10:04:24.616820: [TUN] [if_1ea7d00c23a616b1] Unable to create > Wintun interface: Error registering rings: Error listing NDIS > interfaces: no interfaces found Wintun 0.8 is out of our support. Please, upgrade your wireguard-go and Wintun to the latest version first and see if the problem persists. Why is that important? Because, we completely rewrote the wireguard-go <-> Wintun communication in v0.0.20201118 and v0.10 respectively. The issue you are seeing is triggered in a part of the code that is now gone from wireguard-go and has been rewritten in the new wintun.dll. (The new Wintun no longer ships as a driver package you need to install, but rather as a self-contained do-it-all DLL. Don't worry, the new wireguard-go knows how to use it. Just add wintun.dll next to it.) Regards, Simon
Re: wireguard on multi user windows ?
Hi, If your chief finds out, your company laptop is being used by your kid and wife, taken to kid's school and what not, *then*, your chief will get very very very unhappy. :) Imagine your kid having a trojan horse running on his desktop, just locks the desktop, you borrow back the computer to do some company work. When you connect to your company, the trojan horse gets all the network access to your company resources your VPN connection allows. The WireGuard tunnel profiles are bound to computer, not individual users with a reason: on Windows, VPN connects the entire computer to a network. Not just a particular user. Sorry, WireGuard is and will remain "unusable" for such ill and unsafe practices like yours. Regards, Simon -Original Message- From: WireGuard on behalf of Henning Ryll Date: Sunday, 29 November 2020 at 22.03 To: "wireguard@lists.zx2c4.com" Subject: wireguard on multi user windows ? Hello, I'm looking for a (more or less) secure solution of installing and running wireguard. In our family we have only one notebook running win10/64. Since this is the only device with internet access it has to be reliable as possible. So we are running 4 accounts. admin, father, mother, son. Of course only the admin has admin rights. But all users have operator rights because the notebook is taken to different locations i.e. at school, to friends, during holiday. I'm running OpenVPN to do my homework with this notebook too. And because my openvpn.p12 file is protected by a password my family can not use it because the did not know my password. Even if they have physical access to it. But with wireguard there is no such protection. And with the new wireguard for windows the key files have been moved. And as far as i undertstud everybody in the operator group can start the wireguard tunnel. But my chief will be very very unhappy if this will occur How to install wireguard on a multiuser system. And only the owner of a keyfile can run his tunnel? Other users may be able to run other tunnels. Or is wireguard still unuseable for me and I have to stay at OpenVPN? Henning
RE: Actual plans for Windows client: PostUp/PreDown possible?
Hi, Stefan, your feedback is greatly appreciated. > While I like your suggested "always-on" solution for fixed desktop PCs I > don't like the "work-around" for client laptops. A Task Scheduler which > is trying every 3 minute to set a wiregurad tunnel when you are sitting > in a train using a mobile connecting is nothing I'd like to see. The "wg set peer endpoint" is very lightweight and makes no network requests. Nor it burns CPU/battery. It merely resets an IP address (4 bytes for IPv4, 16 for IPv6) inside the WireGuard tunnel peer list. Would have been even nicer if Task Scheduler could have a trigger "network connection changed". > I think > there are also other scenarios where you just want to "click Connect > button" on demand. E.g. when your company has multiple locations and you > don't want (or cannot) use multiple VPN connections a the same time you > will always have the "somewhat broken" > network drives in the windows explorer too, since they weren't > disconnected within a PreDown script. Each WireGuard tunnel supports multiple peers (i.e. multiple company endpoints). 10.0.0.0/16 is office A, 10.1.0.0/16 is office B, etc. Just list them all in your tunnel config and your laptop should reach all those networks. Maybe "tunnel" is not the best word to describe it. Imagine it as a "network", or a "mesh". > Another problem (which I skipped so far) is related in point 4. of your > suggestion and as I see this a also discussed within another thread here > on the mailinglist. While a simple network drive can of cause be setp to > a fixed IP adress to drive z: using fixed adresse is IMHO not a good > solution. > Like Yves Goergen pointed out in the thread "Add local DNS forwarder to > Windows client" I'd like an option to add the remote DNS server to the > serach list so that that I don't have to keep IP adresses in mind. But I > think this discussion should be shifted to the other thread. You may. But once you do add DNS line to your tunnel config, your client will exclusively use that DNS. All local and others are blocked. If your company DNS server does the forwarding too, this shouldn't be a problem. The down side is, you cannot access local LAN resources by name. But that is discussed in another thread, indeed. Regards, Simon
Re: Actual plans for Windows client: PostUp/PreDown possible?
Hi! WireGuard for Windows and OpenVPN are fundamentally different. Consider WireGuard on Windows as an "always-on" VPN. Once configured by admin, it is just always there, and users don't need to explicitly connect or disconnect. Trust me, this is something your users will grow to love - no searching for a GUI to click Connect button when all you want is to quickly view a business document on Z:. Think differently. These are my recommendations for your use-case: 1. Configure the WireGuard tunnel at the company endpoint. Use specific port rather than random. 2. Configure WireGuard tunnel on client computers and leave it active at all times. 3. Instruct users to connect \\10.0.0.1\data as the network drive Z: and choose Reconnect on logon to make it persistent. (I am pushing a logon-script to do it in my deployment.) Why users? Because, seldomly users disconnect the network drive by accident, and it pays off they know how to reconnect it. 4. Don't add DNS line to the WireGuard tunnel config. Otherwise, WireGuard blocks all other DNS servers and users will not be able to access their home LAN by hostnames. 5. On client laptops that roam in and out of the network where your company endpoint resides, the tunnel company endpoint will auto-switch from public IP to local IP. Then you put your laptop to sleep and go home. When resuming at home, the WireGuard tunnel will still try to contact the company endpoint by local IP and the tunnel traffic will stall. To mitigate this, I make a task in Task Scheduler to run "wg.exe set peer endpoint :" command every 3 minutes. This resets the tunnel endpoint to its public IP. The tunnel traffic is restored after leaving company network in no later than 3 minutes. The client endpoint roaming is handled by WireGuard. As this scheduled task is the same for all clients, once configured and tested, it can be exported and imported on other computers (I deploy it using Group Policy). And that's about it. Your users will always have their Z: drive there. No need for PostUp/PreDown. Best regards, Simon -Original Message- From: WireGuard on behalf of Stefan Puch Date: Tuesday, 10 November 2020 at 14.08 To: "wireguard@lists.zx2c4.com" Subject: Actual plans for Windows client: PostUp/PreDown possible? Hello! I’d like to raise the question regarding an option for PostUp/PreDown with the Windows client again, which was (to my research) first discussed here on the mailing list at the beginning of December 2019 by Rémi and Jason A. I thought about switching our OpenVPN setup to the modern Wireguard and started reading if all my requirements could be fulfilled. So far I have some users with no administrative privileges on their Windows computer when they want to connect to a remote server in order to access some shared space (Samba filesystem). Currently the users are using OpenVPN, which has a background service running with admin rights (Windows service). Thus the users can simply use a shortcut on the desktop to the OpenVPN-GUI including an appropriate config-file to connect to the remote server. After the tunnel is established OpenVPN uses the (optional) solution to place a batch file within the userspace (%USERPROFILE%\OpenVPN\config) as CONFIG-NAME_up.bat / CONFIG-NAME_down.bat where some stuff can be placed to mount a Samba filesystem after the connecting and tunnel are established (net use z: \\10.0.0.1\data) and to unmount before the tunnel is disconnected. I’ve seen the concerns from Jason A. about spreading malware and the hint that “Linux command line users can generally be trusted to check the config files they're writing into /etc/wireguard”. From my point of view the same holds with the solution provided from OpenVPN to use the batch files, which are optional, can be checked by the user and have to be explicitly defined for each VPN profile. Looking into the Windows specific todo list on the Wireguard homepage I didn’t find any comments if this will be considered for later versions of the windows client, if there will or won’t be a solution like this. Maybe I have missed something, so my question would be, if someone can tell me something about the current status or a possible implementation? Kind regards Stefan
RE: Problems with Windows client
Hi Peter! > [Interface] > PrivateKey = XXX= > Address = 10.2.80.226/32 > 2020-09-01 09:20:21.374673: [TUN] [lhirisseccom01] Setting device v4 > addresses > 2020-09-01 09:20:21.445471: [TUN] [lhirisseccom01] Listening for UAPI > requests > 2020-09-01 09:20:21.452451: [TUN] [lhirisseccom01] Startup complete > 2020-09-01 09:20:21.461427: [TUN] [lhirisseccom01] Unable to set > interface addresses, routes, dns, and/or interface settings: The object > already exists. You don't happen to have a TunSafe created TUN-Windows6 adapter around with 10.2.80.226 IP already taken, do you? Regards, Simon
RE: WireGuard on Windows: Unable to create Wintun interface: Error registering rings: Error listing NDIS interfaces: no interfaces found
Hi, > I have installed WireGuard on Windows server 2017. When I manually > activate the tunnel through the client application (manager) all works > fine. After I restart the computer, WireGuard fails to start > automatically. The log contains the following error: > > [tun] [wg0] Unable to create Wintun interface: Error registering > rings: Error listing NDIS interfaces: no interfaces found > > I can explicitly/manually activate the tunnel through the client > application but I need the tunnel to start automatically if the machine > restarts. > > I have it installed in other Windows Server 2017 machines and on those > machines WireGuard starts automatically when the system boots. > > I would appreciate your help in addressing the problem of WireGuard auto > start when the machine boots. Looks like the WireGuard tunnel service is started too early on this particular computer - even before Windows networking (NDIS). We need to investigate, which additional service or resource we need to make the Wireguard tunnel services depend on. I would suggest you to change the WireGuard Manager and Tunnel services startup to Automatic (Delayed), but I am afraid the WireGuard Manager service deletes the tunnel services on each shutdown and recreates them on startup. Furthermore, delayed-started services come up way after the Group Policy Client service. If you use WireGuard to remotely connect this computer to your Active Directory, the boot-time Group Policies won't apply. So, anyway you slice it... we need to fix this in WireGuard service dependencies (or add a retry loop on boot as a last resort). Stay tuned. Regards, Simon
RE: WINTUN: Error registering rings (Error 87, INVALID_ARGUMENT)
Hi,
> I am currently trying to create a testtool using the WINTUN driver to
> establish a 1:1 connection to another client and see what wintun is
> capable of. Unfortunately I cannot get the rings to register. I have
> written a small testprogram in order to reproduce this.
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #include
> #include
> #include
> #include
>
> #pragma pack(push, 1)
Remove the #pragma pack(push, 1)!!!
> typedef struct _TUN_PACKET_PROTO {
> ULONG Size;
> UCHAR Data[]; // max packet size as defined by the driver.
> } TUN_PACKET_PROTO;
>
> typedef struct _TUN_RING_PROTO {
> volatile ULONG Head;
> volatile ULONG Tail;
> volatile LONG Alertable;
> UCHAR Data[];
> } TUN_RING_PROTO;
.
.
.
> typedef struct _TUN_RING {
> volatile ULONG Head;
> volatile ULONG Tail;
> volatile LONG Alertable;
> UCHAR Data[WINTUN_RING_CAPACITY + (TUN_MAX_PACKET_SIZE-
> TUN_ALIGNMENT)];
> } TUN_RING;
>
> typedef struct _TUN_PACKET {
> ULONG Size;
> UCHAR Data[WINTUN_MAX_PACKET_SIZE]; // max packet size as
> defined by the driver.
> } TUN_PACKET;
>
> typedef struct _TUN_REGISTER_RINGS {
> struct {
> ULONG RingSize;
> TUN_RING *Ring;
> HANDLE TailMoved;
> } Send, Receive;
> } TUN_REGISTER_RINGS;
> #pragma pack(pop)
Remove #pragma pack(pop)
> I cannot figure out what I am doing wrong. Can somebody point out the
> error for me? Thanks!
With the #pragma removed, your test program kind of works:
Output with #pragma pack:
Opened wintun device.
Could not register ring buffers (87).
Experiment failed.
Size TUNRING: 8454156 (8454156)
Capacity: 8388608
Output without #pragma pack:
Opened wintun device.
Size TUNRING: 8454156 (8454156)
Capacity: 8388608
And one more thing... Markus, please: why all the profanity in your code? Code
is a work of art. A poetry. I understand Microsoft is silly a lot of times and
difficult to go along with. But don't let that turn *you* into a silly grumpy
geek. :)
Regards,
Simon
RE: DNS Issues with Wireguard for Windows
WireGuard for Windows adds a firewall rules to block all DNS traffic except to the DNS servers listed in the WireGuard config. This is by design (preventing data leakage). Regards, Simon > -Original Message- > From: WireGuard On Behalf Of Andrew > Burkett > Sent: Saturday, July 11, 2020 1:31 AM > To: wireguard@lists.zx2c4.com > Subject: DNS Issues with Wireguard for Windows > > I was running into dns issues with wireguard on windows using the > released gui app. It seems like a bug with wireguard, but not sure if it > was actually something about my networking configs that messed it up. I > was able to work around the issue by changing the wireguard config (in a > way that seemed odd to me), but I thought it might be useful to share > what I was seeing in case its helpful to others or if it is in fact a > bug in wireguard. I'll share the configs at the bottom of the email, but > I'm just going to describe what I'm seeing first. > > My basic setup is I have wireguard running on a linux box functioning as > a server/router to a remote network. I've got a windows desktop > connecting to the linux box via wireguard. There are dns servers on the > remote network that I would like to use from the desktop. I added the > dns servers from the remote network to my desktop wireguard config. > Everything was working fine for awhile. At some point, my windows box > started complaining about not being connected to the internet. I was > able to pinpoint it with some confidence to dns requests failing when > wireguard was connected. Even though windows was complaining about not > having a network connection, my browser still worked though it seemed > slow so I assumed it was trying a dns server and then falling back to a > different one after a timeout (at least that was my guess). The "cause" > of the problem was adding > 192.168.7.12/32 to the AllowedIPs on the peer (the wireguard network in > my case is 10.98.1.0/24 and the rest of the network is under > 10.0.X.X) After adding it and waiting for a couple hours windows will > inevitably claim that there is no internet access from my network > adapter. Sometimes nslookup and ping still work fine, sometimes they > start to report errors. My solution that reliably fixes it is to add my > local dns server (which is my local router in this case > 192.168.86.1) to the dns section of the wireguard config, which seems > like an odd fix since I'm not actually sending local dns traffic to > wireguard. > > I couldn't figure out how to use wireshark to view wireguard traffic on > windows to see what's happening to the dns requests, nor do I know of > another way to view traffic (If someone wants to point me at how to do > that, or some other way to view network traffic on windows, I'm happy to > look at it). > > Anyway, thanks for the software. It's the best vpn software I've used by > a mile. > > Andrew > > My Local Gateway/DNS is 192.168.86.1 > My Local IP is in 192.168.86.0/24 subnet > > Working Config 1 > > [Interface] > PrivateKey = X > Address = 10.98.1.103/32 > DNS = 10.0.X.X, 10.0.Y.Y > > [Peer] > PublicKey = XX > AllowedIPs = 10.0.0.0/16, 10.98.1.0/24 > Endpoint = XXX > > Working Config 2 > > [Interface] > PrivateKey = X > Address = 10.98.1.103/32 > DNS = 10.0.X.X, 10.0.Y.Y , 192.168.86.1 > > [Peer] > PublicKey = XX > AllowedIPs = 10.0.0.0/16, 10.98.1.0/24, 198.168.7.12/32 Endpoint = > XXX > > NonWorking Config > > [Interface] > PrivateKey = X > Address = 10.98.1.103/32 > DNS = 10.0.X.X, 10.0.Y.Y > > [Peer] > PublicKey = XX > AllowedIPs = 10.0.0.0/16, 10.98.1.0/24, 198.168.7.12/32 Endpoint = > XXX
RE: Windows Client - UI improvement
> I'm no Picasso, but take a look at the attached. > > Essentially pin the standard set of options to be always visible, and > make the conf area scrollable. No, that's unfortunately not possible with the stock Win32 menu. However, it is possible to move the tunnel list to a submenu. Maybe when there are more than 10 tunnels. This would make the first level of menu contain only ~5 items. Regards, Simon smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH 0/1] wintun: use standard volatile semantics
Hi Shawn! Thank you. This generally looks good. I can't find any official documentation on the set of functions and macros from wdm.h, but that's nothing new with Microsoft. I have some nitpicks thou. 1. As the atomic.h is no longer used; it could be deleted from the repo. 2. By removing #include "atomic.h", you should add #include . wintun.c is now directly using functions and macros declared in wdm.h. 3. Please add "Signed-of-by: Shawn Hoffman " line to your commit message. 4. You are right, there is no WireGuard for Windows 10 ARM64 yet, because there is no MinGW and Go support for Windows 10 ARM64 yet. If we can get arm-w64-mingw32-native, we could use set GOARCH=arm to compile 32-bit ARM wireguard.exe. 32-bit ARM runs at native speed on Windows 10 ARM64. The challenge I see is making SetupAPI work. I do know the SetupAPI does not work in x86 processes on AMD64 Windows. The System32 folder deflection makes it fail when attempting to create a device. I am expecting the same in ARM process on ARM64 Windows. I have the ARM/ARM64 support high on my TODO list. I do hope to find some time next week to play with your patch and WireGuard ARM. Regards, Simon -Original Message- From: WireGuard on behalf of Shawn Hoffman Date: Friday, 24. April 2020 at 22:52 To: "wireguard@lists.zx2c4.com" Cc: Shawn Hoffman Subject: [PATCH 0/1] wintun: use standard volatile semantics Make all archs are use the standardized concept of volatile. This patch will cause the most changes to arm64 codegen, and has yet to be tested on arm64 so is currently being submitted for comments. If someone would like to test on arm64 it would be appreciated. I do have an arm64 device, but it seems there's no existing arm64/windows wireguard binary package, so I can't just install such a thing and swap out the driver. Shawn Hoffman (1): replace atomic.h with provided APIs switch to /volatile:iso wintun.c | 76 +- wintun.vcxproj | 5 ++- wintun.vcxproj.filters | 3 -- 3 files changed, 40 insertions(+), 44 deletions(-) -- 2.20.1 smime.p7s Description: S/MIME cryptographic signature
Re: Search Domain/DNS Suffix
Hi, I have a similar requirement - to set connection specific DNS suffix. I solved it by extending the wireguard-windows: https://git.zx2c4.com/wireguard-windows/commit/?h=sr/mydist=3672fbc0bcb1821c98566fac32ba0638d4d4c611 However, I do not plan to ask zx2c4 to merge it upstream, as he has better idea to provide PostUpExec feature which would allow universal mean for any extra system configuration required. Stay tuned. Meanwhile, just a suggestion (haven't tested it thou)... Add a task to Task Scheduler to fire every couple of minutes doing: reg.exe add HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces\ /v Domain /t REG_SZ /d contoso.local This should setup the connection specific DNS suffix soon after the tunnel is established and keep it set. But its nuts and doesn't scale. The PostUpExec will be the right approach. Regards, Simon * On Windows 10 the WG adapter GUID is pseudo-random based on your WG config. As long as your config is static, it won't change. Once WG connected, look it up in HKLM\SYSTEM\CurrentControlSet\services\Tcpip\Parameters\Interfaces. -Original Message- From: WireGuard on behalf of Duncan X Simpson Date: Sunday, 5 April 2020 at 23:51 To: "wireguard@lists.zx2c4.com" Subject: Search Domain/DNS Suffix Hello all, I'm trying to deploy a wireguard VPN for a small company and it's working great, with one issue: On Windows/Mac I can't find a way to set search domains on the connection. Windows, I can probably just set a system-wide search domain via the registry (I plan to test that tonight), but on Mac I can't figure out anything. Even the normal command line method, networksetup -setsearchdomains [interface], doesn't take effect - I can retrieve whatever I set with networksetup -getsearchdomains [interface], but it's not used by the system. Does anybody know a solution or workaround? Duncan X Simpson, K7DXS Removal of this tagline is a violation of Federal Law. smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH wireguard-windows] Calculate the actual route metric by summing interface and route metric.
Hi Ludwig, Would a support for ExecPostUp/ExecPreDown satisfy your need? Regards, Simon -Original Message- From: WireGuard on behalf of Ludwig Herzog Date: Tuesday, 31 March 2020 at 05:33 To: "wireguard@lists.zx2c4.com" Subject: Re: [PATCH wireguard-windows] Calculate the actual route metric by summing interface and route metric. Hi, I'm reading this maillist since a longer time and was never brave enough to mention my problem since I'm not a developer or programmer and don't know if I can describe it properly. Now this windows/metric stuff came up, so I take a heart ;-) In short: I have windows 10 client softwares which only work properly with manually set adapter and gateway metrics in the VPN network adapter, what works for openVPN (even better for a logmein test setup) but not for wireguard, since manual metric settings are not recognized / overwritten by the windows wireguard app. Is it possible to set the metrics somehow in the config file? Or prevent the windows wireguard app from overwriting? Regards Ludwig smime.p7s Description: S/MIME cryptographic signature
RE: WINTUN example user space app?
Hi, > In my case, I need to take packets - encapsulate them into a serial > protocol and send them to a radio, Then - take packets from the radio > and pump them back into the network stack. > It is sort of like SLIP ... but its not... > > For me - the above is trival on Linux, but.. my challenge is this > statement: > > Site: https://git.zx2c4.com/wintun/about/ > > >>> After loading the driver and creating a network interface the > typical way using SetupAPI, open the NDIS device object associated with > the PnPInstanceId, enabling all forms of file sharing: > > There are ENDLESS windows rabbit holes, and rat holes to go exploring... > I just don't know the setup api that well. > > Is there a "full simple windows example app" that I can use as a > starting point? > > Something simplistic to start with, in C, C++ or C# > > a) Given an network interface name on the command line > b) Opens that interface > c) Prints to stdout the some of the packets it received. > d) Possibly injects a few example packets, ie: send a ping to some > address like Yahoo.com or something? Long story short... 1. Installing the Wintun driver on your computer: You have some options: - install WireGuard, even if you don't plan to use it, just to get Wintun driver installed - install WiX Toolset, adapt the sample MSI installer provided in the Wintun repo, build your own Wintun driver MSI installer (recommended) 2. Creating/deleting Wintun adapters: To manage Wintun adapters on your system, checkout the https://github.com/Microsoft/Windows-driver-samples and build the setup\devcon utility. Invoke as "devcon install Wintun.inf Wintun". Get the Wintun.inf from the Wintun repo (ouch, you need colossal WDK installed to build the driver to spit out the final Wintun.inf). Once you get familiar with devcon, examine the devcon source code how it creates the adapter. You will notice it needs Wintun.inf file only to detect that the Wintun device is of the "NET" class. 3. Using Wintun adapters: See the source snippets in https://git.zx2c4.com/wintun/about/. This is the general big picture. Good luck and once you have particular technical details to discuss, feel free to ask. Regards, Simon smime.p7s Description: S/MIME cryptographic signature
Re: [PATCH wireguard-windows] l18n: change EnumerationSeparator for Japanese.
Arigato!
Rebuilt the zgotext.go file, amended to your commit, and applied to sr/l18n
patch.
Regards, Simon
-Original Message-
From: WireGuard on behalf of Eiji Tanioka
Date: Thursday, 27 February 2020 at 10:43
To: "wireguard@lists.zx2c4.com"
Subject: [PATCH wireguard-windows] l18n: change EnumerationSeparator for
Japanese.
I grepped source tree and found that 'EnumerationSeparator' is used
for multiple IP addresses separation. In these situation, comma is
better than "、" in Japanese.
("、" is used for Japanese sentence separator, but separation by comma
is more preferable to enumerate ASCII values.)
Signed-off-by: Eiji Tanioka
---
locales/ja/messages.gotext.json | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/locales/ja/messages.gotext.json
b/locales/ja/messages.gotext.json
index 3501458..723cb6c 100644
--- a/locales/ja/messages.gotext.json
+++ b/locales/ja/messages.gotext.json
@@ -455,7 +455,7 @@
{
"id": "[EnumerationSeparator]",
"message": "[EnumerationSeparator]",
-"translation": "、",
+"translation": ", ",
"comment": "Inserted between items when listing (e.g. ‘, ’ or
‘、’)"
},
{
@@ -1494,4 +1494,4 @@
]
}
]
-}
\ No newline at end of file
+}
--
2.25.0
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
smime.p7s
Description: S/MIME cryptographic signature
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] DO_NOT_LAUNCH parameter was ignored by MSI, should work now
Hi Arjen, I was not able to reproduce the problem your patch was supposed to solve. Running: msiexec /i https://download.wireguard.com/windows-client/wireguard-amd64-0.0.38.msi /l* setup.log DO_NOT_LAUNCH=1 did not launch the WireGuard after setup was complete. Screencast here: https://1drv.ms/v/s!AsRKV9itoeUTi0Y-LT895Ynvh0da Running the same command in elevated prompt neither. Screen cast here: https://1drv.ms/v/s!AsRKV9itoeUTi0cEkCG_n2FEX1WA When adding /qn to completely silence the MSI progress neither. Screen cast here: https://1drv.ms/v/s!AsRKV9itoeUTi0izY000CEIE4axC So, how were you setting the `DO_NOT_LAUNCH` property in the first place? Regards, Simon -Original Message- From: WireGuard on behalf of Arjen Brouwer Date: Tuesday, 25 February 2020 at 01:51 To: "wireguard@lists.zx2c4.com" Cc: Arjen Brouwer Subject: [PATCH] DO_NOT_LAUNCH parameter was ignored by MSI, should work now From: Arjen Brouwer The `DO_NO_LAUNCH` parameter did not actually work. After running the installer with the DO_NO_LAUNCH parameter, the UI still showed up afterwards and the MSI log had the following entry: ``` MSI (c) (28:08) [14:43:17:966]: Ignoring disallowed property DO_NOT_LAUNCH ``` By explicitly defining the DO_NOT_LAUNCH property and making it secure, solved the problem. --- installer/wireguard.wxs | 7 --- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/installer/wireguard.wxs b/installer/wireguard.wxs index 5bbb1eb..781d20c 100644 --- a/installer/wireguard.wxs +++ b/installer/wireguard.wxs @@ -45,7 +45,8 @@ - + + @@ -135,7 +136,7 @@ --> - (WireGuardFeature = 3) AND NOT DO_NOT_LAUNCH + - (WireGuardFeature = -1) AND (!WireGuardFeature = 3) AND NOT DO_NOT_LAUNCH + -- 2.24.1.windows.2 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard smime.p7s Description: S/MIME cryptographic signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
RE: [PATCH 1/2 wireguard-windows] Add Japanese translation to resources.rc
Thank you very much. I have applied your patch to the sr/l18n branch. Looking forward to locales/ja/messages.gotext.json Best regards, Simon > -Original Message- > From: WireGuard On Behalf Of Eiji > Tanioka > Sent: Tuesday, February 25, 2020 4:44 PM > To: wireguard@lists.zx2c4.com > Subject: [PATCH 1/2 wireguard-windows] Add Japanese translation to > resources.rc > > Signed-off-by: Eiji Tanioka > --- > resources.rc | 7 +++ > 1 file changed, 7 insertions(+) > > diff --git a/resources.rc b/resources.rc index 14c0ce0..b5b779a 100644 > --- a/resources.rc > +++ b/resources.rc > @@ -56,6 +56,13 @@ VERSIONINFO_TEMPLATE( >"https://www.wireguard.com/; > ) > > +LANGUAGE LANG_JAPANESE, SUBLANG_DEFAULT VERSIONINFO_TEMPLATE( > + "041104b0", 0x411, 0x4b0, > + "WireGuard: 高速で、現代的で、セキュアな VPN トンネル", > + "https://www.wireguard.com/; > +) > + > LANGUAGE LANG_SLOVENIAN, SUBLANG_DEFAULT VERSIONINFO_TEMPLATE( >"042404b0", 0x424, 0x4b0, > -- > 2.25.0 > > ___ > WireGuard mailing list > WireGuard@lists.zx2c4.com > https://lists.zx2c4.com/mailman/listinfo/wireguard smime.p7s Description: S/MIME cryptographic signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] Add japanese translation.
Hi Eiji, Yes, Microsoft-assigned locale ID for Japanese is 0x0411. (0x04b0 stands for UTF-16. Legacy software would probably specify 0x03a4 = Japan (Shift – JIS X-0208) here. I'm not sure if this property is actually used anywhere other than Windows 95.) Just put something like this to the resources.rc file after French (to keep the list sorted by language names in English): LANGUAGE LANG_JAPANESE, SUBLANG_DEFAULT VERSIONINFO_TEMPLATE( "041104b0", 0x411, 0x4b0, "WireGuard: 高速で最新の安全なVPNトンネル", "https://www.wireguard.com/; ) Best regards, Simon -Original Message- From: Eiji Tanioka Date: Tuesday, 25 February 2020 at 08:07 To: Simon Rozman Cc: "wireguard@lists.zx2c4.com" Subject: Re: [PATCH] Add japanese translation. Hi Simon, I read "resources.rc", and start working. and I have question about it. - For Japanese resource, copy from line 45-50 and paste it at EOF - Rewrite "LANG_ENGLISH" to "LANG_JAPANESE" - Rewrite "040904b0" to "041104b0" - Rewrite "0x409" to "0x411" - Translate "WireGuard: Fast, Modern, Secure VPN Tunnel" into Japanese I googled and found that "0x411" means "Japanese". https://docs.microsoft.com/en-us/windows/win32/menurc/versioninfo-resource Is this correct? Regards, smime.p7s Description: S/MIME cryptographic signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
RE: [PATCH] Add japanese translation.
Hi!
1. For starters, I'll need the translation of "WireGuard: Fast, Modern, Secure
VPN Tunnel" string. This string is written into .exe resources and is located
separately (in resources.rc).
2. Translate this file:
https://git.zx2c4.com/wireguard-windows/tree/locales/ja/messages.gotext.json?h=sr/l18n.
Fill the "translation" string properties with Japanese text. Japanese doesn't
have plural, right? If you need to word some translation differently (based on
a cardinal variable), you may extend "translation" string property into to a
"select" object. See
https://git.zx2c4.com/wireguard-windows/tree/locales/en/messages.gotext.json?h=sr/l18n
or
https://git.zx2c4.com/wireguard-windows/tree/locales/fr/messages.gotext.json?h=sr/l18n
for plural examples (search for "plural"). (Yes, we are using
English-to-English translation to translate "{Seconds} second(s)" into nicer to
read "1 second", "2 seconds"...)
3. Deliver translation to me and I shall handle a commit in your name. Before
publishing, I will make some screenshots in Japanese, for you to confirm.
Best regards,
Simon
> -Original Message-
> From: Eiji Tanioka
> Sent: Sunday, February 23, 2020 9:35 AM
> To: Simon Rozman ; wireguard@lists.zx2c4.com
> Subject: Re: [PATCH] Add japanese translation.
>
> Thank you for quick reply!
>
> I read README.md.
> But I don't have Windows environment I can use freely, so could you
> generate Japanese messages.json file?
>
> Thanks,
>
> 2020年2月23日(日) 17:23 Simon Rozman :
> >
> > Hi!
> >
> > Please, see the simple translation instructions in the sr/l18n branch
> README.md file.
> >
> > If you don't have Windows at your disposal, I can generate an empty
> Japanese messages.json file for you.
> >
> > Best regards,
> > Simon
> >
> > From: Eiji Tanioka
> > Sent: Sunday, 23 February 2020 08:49
> > To: Simon Rozman; wireguard@lists.zx2c4.com
> > Subject: Re: [PATCH] Add japanese translation.
> >
> > Hi Simon!
> >
> > I finished wireguard-apple translation to Japanese.
> > So I will start to translate wireguard-windows.
> >
> > How do I work on it?
> > I guess:
> > - checkout sr/i18n
> > - create locales/ja/messages.gotext.json
> > - translate "message" into "translation" field
> > - send patch to ML
> >
> > Is this correct?
> > Thanks,
> >
smime.p7s
Description: S/MIME cryptographic signature
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
Re: [PATCH] Add japanese translation.
Hi! Please, see the simple translation instructions in the sr/l18n branch README.md file. If you don't have Windows at your disposal, I can generate an empty Japanese messages.json file for you. Best regards, Simon From: Eiji Tanioka Sent: Sunday, 23 February 2020 08:49 To: Simon Rozman; wireguard@lists.zx2c4.com Subject: Re: [PATCH] Add japanese translation. Hi Simon! I finished wireguard-apple translation to Japanese. So I will start to translate wireguard-windows. How do I work on it? I guess: - checkout sr/i18n - create locales/ja/messages.gotext.json - translate "message" into "translation" field - send patch to ML Is this correct? Thanks, 2020年2月16日(日) 23:13 Eiji Tanioka : > > Hi Simon, > > Sure! I will be pleased to help wireguard-windows localization. > Currently, I'm working on wireguard-apple translation. When finished, > I will try to translate wireguard-windows to Japanese. > > Regards, > Eiji > > > 2020年2月16日(日) 18:40 Simon Rozman : > > > > Hi Eiji! > > > > > > > > I wonder if you might be willing to contribute Japanese translation for the > > wireguard-windows as well? > > > > > > > > The wireguard-windows has pending localization support here > > https://git.zx2c4.com/wireguard-windows/log/?h=sr/l18n. I have translated > > it to Slovenian already. Furthermore, I should get the French translation > > to integrate soon too. > > > > > > > > Regards, Simon > > > > > > > > From: WireGuard On Behalf Of Eiji > > Tanioka > > Sent: Saturday, February 15, 2020 11:23 AM > > To: Samuel Holland > > Cc: wireguard@lists.zx2c4.com > > Subject: Re: [PATCH] Add japanese translation. > > > > > > > > Thank you for applying my patch! > > > > > > > > I'm now translating wireguard-apple into Japanese. When finished, I will > > send patch. > > > > Next time, I will not forget your advice. > > > > > > > > Thanks, > > > > > > > > 2020年2月15日(土) 15:14 Samuel Holland : > > > > On 2/14/20 11:27 PM, Eiji Tanioka wrote: > > > Hi, Samuel. > > > > > > Thank you for your reply! > > > I re-created patch. > > > > Thanks, applied: > > https://git.zx2c4.com/wireguard-android/commit/?id=822f72df956ecd3aaa6a2b254e059e38ba5122e4 ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
RE: [PATCH] Add japanese translation.
Hi Eiji! I wonder if you might be willing to contribute Japanese translation for the wireguard-windows as well? The wireguard-windows has pending localization support here https://git.zx2c4.com/wireguard-windows/log/?h=sr/l18n. I have translated it to Slovenian already. Furthermore, I should get the French translation to integrate soon too. Regards, Simon From: WireGuard On Behalf Of Eiji Tanioka Sent: Saturday, February 15, 2020 11:23 AM To: Samuel Holland Cc: wireguard@lists.zx2c4.com Subject: Re: [PATCH] Add japanese translation. Thank you for applying my patch! I'm now translating wireguard-apple into Japanese. When finished, I will send patch. Next time, I will not forget your advice. Thanks, 2020年2月15日(土) 15:14 Samuel Holland mailto:sam...@sholland.org> >: On 2/14/20 11:27 PM, Eiji Tanioka wrote: > Hi, Samuel. > > Thank you for your reply! > I re-created patch. Thanks, applied: https://git.zx2c4.com/wireguard-android/commit/?id=822f72df956ecd3aaa6a2b254e059e38ba5122e4 smime.p7s Description: S/MIME cryptographic signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
RE: After win2019 server reboot, Wireguard tunnel doesn't start
Hi, Can you send the %SystemRoot%\inf\SetupAPI.dev.log file, please? Regards, Simon smime.p7s Description: S/MIME cryptographic signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
RE: WireGuard-Windows sets wrong gateway IP address in routes
> it appears I found a bug in the Windows implementation of the WireGuard > client. > I'm not sure, because it seems to be a rather trivial one, but I guess > you will tell me if it's not the case. It's not the case. Windows will know correctly to send packets to the WireGuard interface. Mind the "Interface" column in your "route print" output. Once Windows sends packets to the WireGuard interface, WireGuard will handle the rest: tunnel them to the appropriate peer according to AllowedIPs. > So: When you activate a configured tunnel, WG sets the very first IP > address of a network as gateway, instead of the first usable address. > > That means, if you have a VPN (sub)net like 10.0.10.0/24, where your > server has 10.0.10.1 and the Windows machine 10.0.10.4, the client tries > to use 10.0.10.0 as gateway. This obviously doesn't work, because this > address is reserved / not usable, and the gateway has a different IP. > The first usable address for hosts is 10.0.10.1, which the WireGuard > client should set as gateway. > > Same applies for IPv6. Who guarantees you the first usable address will always be the gateway? Some use .254 for the gateway. > I didn't try it out yet though, don't have a WireGuard dev env set up. > If you want me to, I can take a look and maybe send a patch if I get it > to work. Please try it and see it just works as it is. Mind boggling, isn't it? :) Best regards, Simon smime.p7s Description: S/MIME cryptographic signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
RE: Wireguard for Windows - local administrator necessary?
Hi Chris! This is WireGuard design. Reconfiguring network - which (dis)connecting VPN is – is administrative task. If your organization issues laptops to their employees, the corporate VPN should be up at all times. You don't want them to disconnect from VPN and use those laptops on compromised networks, do you? I did have an issue when roaming laptops to and from corporate WiFi, as the endpoint IP changes – restarting the tunnel helped, but adding a scheduled task to reset endpoint IP every 2 minutes using wg.exe command line works like a charm here. If that's the reason you would want your users to manipulate WireGuard tunnels? Best regards, Simon From: WireGuard On Behalf Of Chris Bennett Sent: Thursday, September 26, 2019 4:35 AM To: wireguard@lists.zx2c4.com Subject: Wireguard for Windows - local administrator necessary? Hi there, I've been experimenting with the use of the Windows Wireguard agent for corporate VPN access. It's been working really well! However I've found the logged in user needs local Administrator access to activate and de-activate a tunnel. Is there any way around this? Is it in the roadmap to remove this requirement? Thanks! Chris smime.p7s Description: S/MIME cryptographic signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
RE: Windows client "Unable to create Wintun device"
Hi Richard,
I apologise for the delay. (Becoming my standard letter introduction these
days. ☹)
Your error is saying that NetCfgInstanceId value did not appear in the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{4d36e972-e325-11ce-bfc1-08002be10318}\
registry key in 10 seconds. Can you check the registry key what's going on
there, please?
Also, check the event log (System and Application and Service
Logs\Microsoft\Windows\DeviceSetupManager) for any errors at the time you are
attempting to activate the tunnel. Maybe there's some disabled service causing
interface device creation to fail?
Maybe your Windows is attempting to access Windows Update for a newer version
of Wintun driver first, triggering 10 second timeout in WireGuard?
Best regards,
Simon
From: WireGuard On Behalf Of Richard Reiner
Sent: Tuesday, November 12, 2019 5:38 AM
To: wireguard@lists.zx2c4.com
Subject: Windows client "Unable to create Wintun device"
On one of my machines, the Wireguard Windows client 0.0.35 was previously
working well, but as of today whenever attempting to activate any tunnel it
generates errors with log messages like:
2019-11-11 17:32:48.033: [TUN] [tun22] Unable to create Wintun device: Unable
to create Wintun interface: GetStringValueWait(NetCfgInstanceId) failed:
Timeout waiting for registry value
An uninstall - reboot - reinstall has not corrected this/
The affected machine has received some Windows 10 updates recently as well as a
VMware Player update.
But another machine with the same software installed works fine.
Any thoughts or suggestions?
smime.p7s
Description: S/MIME cryptographic signature
___
WireGuard mailing list
WireGuard@lists.zx2c4.com
https://lists.zx2c4.com/mailman/listinfo/wireguard
RE: Unable to create Wintun Interface
Please check if you have any network adapter that has a name similar to the tunnel name you are trying to use (Control Panel\Network and Internet\Network Connections). WireGuard needs to have a network adapter with the name that corresponds to the tunnel name. In your case, it fails naming it. Maybe you named your Ethernet/Wifi adapter as "MyCompany", and then created a WireGuard tunnel with the same name "MyCompany". Maybe you have a WiFi SSID named "MyCompany". Try picking different name for your WireGuard tunnel. Other than WireGuard tunnel and adapter names must be aligned internal limitation, the name of the tunnel doesn't play any significant role. You can select a different name (e.g. "MyCompanyWG", "wg0", etc.) and try again. Best regards, Simon From: WireGuard On Behalf Of Mark Nichols Sent: Wednesday, November 20, 2019 8:04 PM To: wireguard@lists.zx2c4.com Subject: Unable to create Wintun Interface I've just installed Wireguard on Windows 10 64-bit using the msi installer. When I create a tunnel and try to connect, I get: Unable to create Wintun interface: Error creating interface: Unable to set name of Wintun interface: NciSetConnectionName failed: The requested operation was made in the context of a transaction that is no longer active. I have uninstalled and reinstalled from the command prompt as the administrator. I have validated the tunnel works with the configured parameters on a Mac. Any suggestions? Mark Nichols Discrimination, oppression, and injustice are challenges to be overcome, tools to sharpen our determination, and reflections on the poor character of the oppressor. Lack of opportunity is a calling to create something new and better. If we choose to see circumstances as something to overcome on our way to success instead of allowing them to define us as a victim, we retain the power to pursue our highest destiny. smime.p7s Description: S/MIME cryptographic signature ___ WireGuard mailing list WireGuard@lists.zx2c4.com https://lists.zx2c4.com/mailman/listinfo/wireguard
