* Problems with Windows client @ 2020-08-27 13:35 Peter Whisker 2020-08-27 19:20 ` Jason A. Donenfeld 0 siblings, 1 reply; 27+ messages in thread From: Peter Whisker @ 2020-08-27 13:35 UTC (permalink / raw) To: wireguard Hi The Windows client does not work over my work VPN (Juniper Pulse). I have project servers behind a firewall. I can use Wireguard over the office LAN but not over the VPN. What proves to me that it is a Wireguard client problem is that the TunSafe Wireguard client works perfectly and connects to my project servers over the VPN with the identical configuration. I get an error "Object already exists" from the real Wireguard client. None of the tunnel routes which are being created are there before. This is a longstanding Wireguard Client problem. I can send logs if requested. Thanks Peter ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client 2020-08-27 13:35 Problems with Windows client Peter Whisker @ 2020-08-27 19:20 ` Jason A. Donenfeld 2020-09-01 8:30 ` Peter Whisker 0 siblings, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2020-08-27 19:20 UTC (permalink / raw) To: Peter Whisker; +Cc: WireGuard mailing list On Thu, Aug 27, 2020 at 3:35 PM Peter Whisker <peter.whisker@gmail.com> wrote: > > > Hi > > The Windows client does not work over my work VPN (Juniper Pulse). I > have project servers behind a firewall. I can use Wireguard over the > office LAN but not over the VPN. > > What proves to me that it is a Wireguard client problem is that the > TunSafe Wireguard client works perfectly and connects to my project > servers over the VPN with the identical configuration. > > I get an error "Object already exists" from the real Wireguard client. > None of the tunnel routes which are being created are there before. > > This is a longstanding Wireguard Client problem. > > I can send logs if requested. Yes, please. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client 2020-08-27 19:20 ` Jason A. Donenfeld @ 2020-09-01 8:30 ` Peter Whisker 2020-09-03 13:35 ` Simon Rozman 0 siblings, 1 reply; 27+ messages in thread From: Peter Whisker @ 2020-09-01 8:30 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list Hi Here are the config file and log file while attempting to connect. The network and routes are correct as the identical configuration works with no issues in the TunSafe client 1.5-rc2. However, of course I would prefer to use the real client! Regards Peter ===================== Below is the config file (redacted) [Interface] PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX= Address = 10.2.80.226/32 [Peer] PublicKey = QfjlPwEQa03gx7OYkM3Al8MIrfTx7WY0TT235eg0V1w= PresharedKey = yorTvlJ8aiAmhxd1KpLWeC+MTLsC25EHNKAPi0YtP8A= AllowedIPs = 10.2.80.0/25, 10.12.0.0/23, 10.2.0.34/31, 10.2.2.34/31, 10.2.4.34/31, 10.2.6.34/31 Endpoint = iris-fw1.XXXXXX.com:21820 PersistentKeepalive = 25 ===================== And here are the logs: 2020-09-01 09:18:43.349190: [MGR] Starting WireGuard/0.1.1 (Windows 10.0.18362; amd64) 2020-09-01 09:18:43.360141: [MGR] Starting UI process for user ‘whiskerp@XXXXXX’ for session 1 2020-09-01 09:20:17.731706: [TUN] [lhirisseccom01] Starting WireGuard/0.1.1 (Windows 10.0.18362; amd64) 2020-09-01 09:20:17.734729: [TUN] [lhirisseccom01] Watching network interfaces 2020-09-01 09:20:17.738681: [TUN] [lhirisseccom01] Resolving DNS names 2020-09-01 09:20:17.797513: [TUN] [lhirisseccom01] Creating Wintun interface 2020-09-01 09:20:19.431220: [TUN] [lhirisseccom01] Using Wintun/0.8 (NDIS 6.83) 2020-09-01 09:20:19.778181: [TUN] [lhirisseccom01] Enabling firewall rules 2020-09-01 09:20:20.213362: [TUN] [lhirisseccom01] Dropping privileges 2020-09-01 09:20:20.287150: [TUN] [lhirisseccom01] Creating interface instance 2020-09-01 09:20:20.336012: [TUN] [lhirisseccom01] Routine: event worker - started 2020-09-01 09:20:20.371912: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-01 09:20:20.443225: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-01 09:20:20.479123: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-01 09:20:20.495077: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-01 09:20:20.510035: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-01 09:20:20.512029: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-01 09:20:20.513026: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-01 09:20:20.513026: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-01 09:20:20.517019: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-01 09:20:20.520011: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-01 09:20:20.521004: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-01 09:20:20.521004: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-01 09:20:20.521004: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-01 09:20:20.521004: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-01 09:20:20.522000: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-01 09:20:20.522000: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-01 09:20:20.522000: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-01 09:20:20.522000: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-01 09:20:20.522000: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-01 09:20:20.522000: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-01 09:20:20.522000: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-01 09:20:20.522998: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-01 09:20:20.522998: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-01 09:20:20.522998: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-01 09:20:20.522998: [TUN] [lhirisseccom01] Routine: TUN reader - started 2020-09-01 09:20:20.522998: [TUN] [lhirisseccom01] Setting interface configuration 2020-09-01 09:20:20.523995: [TUN] [lhirisseccom01] UAPI: Updating private key 2020-09-01 09:20:20.524993: [TUN] [lhirisseccom01] UAPI: Removing all peers 2020-09-01 09:20:20.524993: [TUN] [lhirisseccom01] UAPI: Transition to peer configuration 2020-09-01 09:20:20.525990: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Created 2020-09-01 09:20:20.526989: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Updating preshared key 2020-09-01 09:20:20.527984: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Updating endpoint 2020-09-01 09:20:20.527984: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Updating persistent keepalive interval 2020-09-01 09:20:20.528981: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Removing all allowedips 2020-09-01 09:20:20.528981: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-09-01 09:20:20.528981: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-09-01 09:20:20.528981: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-09-01 09:20:20.528981: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-09-01 09:20:20.529979: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-09-01 09:20:20.529979: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-09-01 09:20:20.529979: [TUN] [lhirisseccom01] Bringing peers up 2020-09-01 09:20:20.533973: [TUN] [lhirisseccom01] Routine: receive incoming IPv6 - started 2020-09-01 09:20:20.536959: [TUN] [lhirisseccom01] Routine: receive incoming IPv4 - started 2020-09-01 09:20:20.536959: [TUN] [lhirisseccom01] UDP bind has been updated 2020-09-01 09:20:20.536959: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Starting... 2020-09-01 09:20:20.536959: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: nonce worker - started 2020-09-01 09:20:20.536959: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: sequential receiver - started 2020-09-01 09:20:20.538381: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: sequential sender - started 2020-09-01 09:20:20.538381: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending keepalive packet 2020-09-01 09:20:20.539366: [TUN] [lhirisseccom01] Monitoring default v6 routes 2020-09-01 09:20:20.539366: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-01 09:20:20.539366: [TUN] [lhirisseccom01] Binding v6 socket to interface 0 (blackhole=false) 2020-09-01 09:20:20.539366: [TUN] [lhirisseccom01] Setting device v6 addresses 2020-09-01 09:20:20.542356: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Awaiting keypair 2020-09-01 09:20:20.624124: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake response 2020-09-01 09:20:20.722117: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Obtained awaited keypair 2020-09-01 09:20:21.361710: [TUN] [lhirisseccom01] Monitoring default v4 routes 2020-09-01 09:20:21.373676: [TUN] [lhirisseccom01] Binding v4 socket to interface 22 (blackhole=false) 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. 2020-09-01 09:20:22.090177: [TUN] [lhirisseccom01] Device closing 2020-09-01 09:20:22.103143: [TUN] [lhirisseccom01] Routine: TUN reader - stopped 2020-09-01 09:20:22.503552: [TUN] [lhirisseccom01] Routine: event worker - stopped 2020-09-01 09:20:22.511530: [TUN] [lhirisseccom01] Routine: receive incoming IPv4 - stopped 2020-09-01 09:20:22.526487: [TUN] [lhirisseccom01] Routine: receive incoming IPv6 - stopped 2020-09-01 09:20:22.584831: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Stopping... 2020-09-01 09:20:22.588818: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: sequential receiver - stopped 2020-09-01 09:20:22.588818: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-01 09:20:22.588818: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-01 09:20:22.589820: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-01 09:20:22.589820: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-01 09:20:22.591812: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-01 09:20:22.592806: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-01 09:20:22.592806: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-01 09:20:22.593805: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-01 09:20:22.594801: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-01 09:20:22.595798: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-01 09:20:22.595798: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-01 09:20:22.595798: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-01 09:20:22.598790: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-01 09:20:22.599787: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-01 09:20:22.599787: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-01 09:20:22.599787: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-01 09:20:22.599787: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-01 09:20:22.601782: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-01 09:20:22.601782: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-01 09:20:22.601782: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-01 09:20:22.601782: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-01 09:20:22.601782: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-01 09:20:22.601782: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-01 09:20:22.603775: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-01 09:20:22.606767: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: sequential sender - stopped 2020-09-01 09:20:22.607765: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: nonce worker - stopped 2020-09-01 09:20:22.612750: [TUN] [lhirisseccom01] Interface closed 2020-09-01 09:20:22.621725: [TUN] [lhirisseccom01] Shutting down ^ permalink raw reply [flat|nested] 27+ messages in thread
* RE: Problems with Windows client 2020-09-01 8:30 ` Peter Whisker @ 2020-09-03 13:35 ` Simon Rozman 2020-09-21 10:39 ` Peter Whisker 0 siblings, 1 reply; 27+ messages in thread From: Simon Rozman @ 2020-09-03 13:35 UTC (permalink / raw) To: Peter Whisker, Jason A. Donenfeld; +Cc: WireGuard mailing list Hi Peter! > [Interface] > PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX= > 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client 2020-09-03 13:35 ` Simon Rozman @ 2020-09-21 10:39 ` Peter Whisker 2020-11-24 10:17 ` Peter Whisker 0 siblings, 1 reply; 27+ messages in thread From: Peter Whisker @ 2020-09-21 10:39 UTC (permalink / raw) To: Simon Rozman, Jason A. Donenfeld; +Cc: WireGuard mailing list Hi Simon Ah, OK, that was one issue. I fixed that by disabling the TUN-Windows6 interface. Wireguard happily connects to an external site I have, but still there is an issue to the one via the Pulse tunnel. The tunnel claims to come up, routes are added correctly but the handshakes don't seem very stable and traffic doesn't flow. 2020-09-14 08:37:43.411496: [MGR] Starting WireGuard/0.1.1 (Windows 10.0.18362; amd64) 2020-09-14 08:37:43.422394: [MGR] Starting UI process for user ‘whiskerp@GROUPINFRA’ for session 1 2020-09-14 08:37:46.079843: [TUN] [lhirisseccom01] Starting WireGuard/0.1.1 (Windows 10.0.18362; amd64) 2020-09-14 08:37:46.080833: [TUN] [lhirisseccom01] Watching network interfaces 2020-09-14 08:37:46.085786: [TUN] [lhirisseccom01] Resolving DNS names 2020-09-14 08:37:46.152152: [TUN] [lhirisseccom01] Creating Wintun interface 2020-09-14 08:37:48.451529: [TUN] [lhirisseccom01] Using Wintun/0.8 (NDIS 6.83) 2020-09-14 08:37:48.490161: [TUN] [lhirisseccom01] Enabling firewall rules 2020-09-14 08:37:48.837582: [TUN] [lhirisseccom01] Dropping privileges 2020-09-14 08:37:48.913732: [TUN] [lhirisseccom01] Creating interface instance 2020-09-14 08:37:48.985102: [TUN] [lhirisseccom01] Routine: event worker - started 2020-09-14 08:37:49.029493: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-14 08:37:49.046333: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-14 08:37:49.058219: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-14 08:37:49.071096: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-14 08:37:49.079015: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-14 08:37:49.081985: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-14 08:37:49.114673: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-14 08:37:49.126560: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-14 08:37:49.128541: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-14 08:37:49.133494: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-14 08:37:49.139437: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-14 08:37:49.142408: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-14 08:37:49.144390: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-14 08:37:49.148352: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-14 08:37:49.153305: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-14 08:37:49.170144: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-14 08:37:49.174107: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-14 08:37:49.177078: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-14 08:37:49.180269: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-14 08:37:49.182171: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-09-14 08:37:49.182171: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-14 08:37:49.182171: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-14 08:37:49.183161: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-09-14 08:37:49.183161: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-09-14 08:37:49.183161: [TUN] [lhirisseccom01] Routine: TUN reader - started 2020-09-14 08:37:49.184151: [TUN] [lhirisseccom01] Setting interface configuration 2020-09-14 08:37:49.185142: [TUN] [lhirisseccom01] UAPI: Updating private key 2020-09-14 08:37:49.186132: [TUN] [lhirisseccom01] UAPI: Removing all peers 2020-09-14 08:37:49.186132: [TUN] [lhirisseccom01] UAPI: Transition to peer configuration 2020-09-14 08:37:49.187123: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Created 2020-09-14 08:37:49.187123: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Updating preshared key 2020-09-14 08:37:49.187123: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Updating endpoint 2020-09-14 08:37:49.187123: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Updating persistent keepalive interval 2020-09-14 08:37:49.188113: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Removing all allowedips 2020-09-14 08:37:49.188113: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-09-14 08:37:49.188113: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-09-14 08:37:49.188113: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-09-14 08:37:49.189104: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-09-14 08:37:49.189104: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-09-14 08:37:49.189104: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-09-14 08:37:49.189104: [TUN] [lhirisseccom01] Bringing peers up 2020-09-14 08:37:49.190095: [TUN] [lhirisseccom01] Routine: receive incoming IPv6 - started 2020-09-14 08:37:49.192076: [TUN] [lhirisseccom01] Routine: receive incoming IPv4 - started 2020-09-14 08:37:49.192076: [TUN] [lhirisseccom01] UDP bind has been updated 2020-09-14 08:37:49.193067: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Starting... 2020-09-14 08:37:49.193067: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: sequential receiver - started 2020-09-14 08:37:49.194057: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: nonce worker - started 2020-09-14 08:37:49.194057: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: sequential sender - started 2020-09-14 08:37:49.195049: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending keepalive packet 2020-09-14 08:37:49.195049: [TUN] [lhirisseccom01] Monitoring default v4 routes 2020-09-14 08:37:49.195049: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:37:49.200000: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Awaiting keypair 2020-09-14 08:37:49.200991: [TUN] [lhirisseccom01] Binding v4 socket to interface 22 (blackhole=false) 2020-09-14 08:37:49.201981: [TUN] [lhirisseccom01] Setting device v4 addresses 2020-09-14 08:37:49.251208: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake response 2020-09-14 08:37:49.266067: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Obtained awaited keypair 2020-09-14 08:37:51.847336: [TUN] [lhirisseccom01] Monitoring default v6 routes 2020-09-14 08:37:51.849315: [TUN] [lhirisseccom01] Binding v6 socket to interface 0 (blackhole=false) 2020-09-14 08:37:51.850307: [TUN] [lhirisseccom01] Setting device v6 addresses 2020-09-14 08:37:53.848495: [TUN] [lhirisseccom01] Listening for UAPI requests 2020-09-14 08:37:53.863023: [TUN] [lhirisseccom01] Startup complete 2020-09-14 08:37:54.276293: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:37:54.277285: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:37:59.648263: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:37:59.648263: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:38:04.738217: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:38:04.738217: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:38:10.092874: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:38:10.092874: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:38:15.454052: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:38:15.454052: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:38:20.556130: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:38:20.556130: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:38:25.658524: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:38:25.658524: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:38:31.016112: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:38:31.016112: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:38:47.270325: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Retrying handshake because we stopped hearing back after 15 seconds 2020-09-14 08:38:47.270325: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:38:52.543592: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 2) 2020-09-14 08:38:52.543592: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:38:57.617018: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 3) 2020-09-14 08:38:57.617018: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:39:02.710943: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 4) 2020-09-14 08:39:02.710943: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:39:05.329483: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Retrying handshake because we stopped hearing back after 15 seconds 2020-09-14 08:39:07.775887: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 2) 2020-09-14 08:39:07.775887: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:39:12.852980: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 3) 2020-09-14 08:39:12.855162: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:39:17.944130: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 4) 2020-09-14 08:39:17.944130: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:39:22.810801: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:39:22.810801: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:39:23.010247: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 5) 2020-09-14 08:39:28.165288: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:39:28.165288: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:39:33.520656: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:39:33.520656: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:39:38.884012: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:39:38.886998: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:39:44.246649: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:39:44.246649: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:39:49.594974: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:39:49.594974: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:39:54.952930: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:39:54.953924: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:40:00.054531: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:40:00.055525: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:40:05.363407: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:40:05.415486: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:40:05.416512: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:40:10.421407: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 2) 2020-09-14 08:40:10.422402: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:40:10.515798: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:40:10.516796: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:40:15.679493: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 2) 2020-09-14 08:40:15.679581: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:40:15.872032: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:40:15.872032: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:40:20.760460: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 2) 2020-09-14 08:40:20.975553: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:40:20.975553: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:40:26.267953: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:40:26.325259: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:40:26.335169: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:40:31.424640: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 2) 2020-09-14 08:40:31.424640: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:40:31.690144: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:40:31.690144: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:40:36.560198: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 2) 2020-09-14 08:40:36.793135: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:40:36.793135: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:40:41.896736: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:40:41.896736: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:40:47.224830: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:40:47.253511: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:40:47.253511: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:40:50.180877: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Awaiting keypair 2020-09-14 08:40:52.277130: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 2) 2020-09-14 08:40:52.277130: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-09-14 08:40:52.612274: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:40:52.612274: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:40:57.322421: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 2) 2020-09-14 08:40:57.968623: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:40:57.968623: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:41:00.825600: [MGR] [lhirisseccom01] Tunnel service tracker finished 2020-09-14 08:41:02.363492: [TUN] [lhirisseccom01] Device closing 2020-09-14 08:41:02.363492: [TUN] [lhirisseccom01] Routine: TUN reader - stopped 2020-09-14 08:41:03.331908: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake initiation 2020-09-14 08:41:03.335884: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake response 2020-09-14 08:41:03.774915: [TUN] [lhirisseccom01] Routine: event worker - stopped 2020-09-14 08:41:03.803827: [TUN] [lhirisseccom01] Routine: receive incoming IPv4 - stopped 2020-09-14 08:41:03.810784: [TUN] [lhirisseccom01] Routine: receive incoming IPv6 - stopped 2020-09-14 08:41:03.818736: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Stopping... 2020-09-14 08:41:03.818736: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: sequential receiver - stopped 2020-09-14 08:41:03.819730: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: nonce worker - stopped 2020-09-14 08:41:03.825694: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-14 08:41:03.840197: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-14 08:41:03.847371: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-14 08:41:03.855323: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-14 08:41:03.878184: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-14 08:41:03.893093: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-14 08:41:03.907008: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-14 08:41:03.923906: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-14 08:41:03.924899: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-14 08:41:03.925894: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-14 08:41:03.929869: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-14 08:41:03.930863: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-14 08:41:03.937820: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-14 08:41:03.939809: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-14 08:41:03.941796: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-14 08:41:03.943784: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-14 08:41:03.944779: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-14 08:41:03.946766: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-14 08:41:03.946766: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-14 08:41:03.947760: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-14 08:41:03.948754: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-14 08:41:03.950743: [TUN] [lhirisseccom01] Routine: encryption worker - stopped 2020-09-14 08:41:03.963663: [TUN] [lhirisseccom01] Routine: handshake worker - stopped 2020-09-14 08:41:03.966645: [TUN] [lhirisseccom01] Routine: decryption worker - stopped 2020-09-14 08:41:03.969627: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: sequential sender - stopped 2020-09-14 08:41:03.971615: [TUN] [lhirisseccom01] Interface closed 2020-09-14 08:41:03.975590: [TUN] [lhirisseccom01] Shutting down On 03/09/2020 14:35, Simon Rozman wrote: > Hi Peter! > >> [Interface] >> PrivateKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX= >> 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 ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client 2020-09-21 10:39 ` Peter Whisker @ 2020-11-24 10:17 ` Peter Whisker 2020-11-26 13:04 ` Problems with Windows client over PulseSecure VPN Peter Whisker 0 siblings, 1 reply; 27+ messages in thread From: Peter Whisker @ 2020-11-24 10:17 UTC (permalink / raw) To: Simon Rozman, Jason A. Donenfeld; +Cc: WireGuard mailing list Hi I've taken a futher look at this today with the latest client 0.3.1. The issue is establishing a wireguard connection over a PulseConnect SSLVPN. The Tunsafe client which works (I'm using an identical configuration on both it and the Wireguard client) exchanges handshakes and then Keepalives and then starts transporting packets. My source address is 10.209.29.xxx and my destination address is 158.xxx.xxx.xxx. The config is as below. After Tunsafe starts I see the routing created as: C:\Users\whiskerp>route print /4 | find "10.2.80.226" 10.2.0.34 255.255.255.254 10.2.80.1 10.2.80.226 125 10.2.1.34 255.255.255.254 10.2.80.1 10.2.80.226 125 10.2.80.0 255.255.255.0 On-link 10.2.80.226 281 10.2.80.226 255.255.255.255 On-link 10.2.80.226 281 10.2.80.255 255.255.255.255 On-link 10.2.80.226 281 10.12.0.0 255.255.254.0 10.2.80.1 10.2.80.226 125 224.0.0.0 240.0.0.0 On-link 10.2.80.226 281 255.255.255.255 255.255.255.255 On-link 10.2.80.226 281 Wireguard client starts and exchanges handshakes, sends a keepalive but it does not seem to get to the other end. After 25 seconds, a Keepalive is sent by the other end (and noted by Wireguard at 10:04:41 in the log). No traffic is sent. The routing table created by Wireguard is slightly different too: C:\Users\whiskerp>route print /4 | find "10.2.80.226" 10.2.0.34 255.255.255.254 On-link 10.2.80.226 5 10.2.0.35 255.255.255.255 On-link 10.2.80.226 261 10.2.1.34 255.255.255.254 On-link 10.2.80.226 5 10.2.1.35 255.255.255.255 On-link 10.2.80.226 261 10.2.80.0 255.255.255.0 On-link 10.2.80.226 5 10.2.80.226 255.255.255.255 On-link 10.2.80.226 261 10.2.80.255 255.255.255.255 On-link 10.2.80.226 261 10.12.0.0 255.255.254.0 On-link 10.2.80.226 5 10.12.1.255 255.255.255.255 On-link 10.2.80.226 261 Configuration: [Interface] PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= Address = 10.2.80.226/32 [Peer] PublicKey = QfjlPwEQa03gx7OYkM3Al8MIrfTx7WY0TT235eg0V1w= PresharedKey = yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy= AllowedIPs = 10.2.80.0/24, 10.12.0.0/23, 10.2.0.34/31, 10.2.1.34/31 Endpoint = iris-fw1.xxxxxxxxxx.com:21820 PersistentKeepalive = 25 I can connect with Wireguard to another server across the direct interface just not via the PulseConnect SSLVPN. Tunsafe works in both cases. The log is below. I do not see any repeated Handshakes in a Wireguard capture of all interfaces, just the first one and the one 25 seconds later from the remote side. 2020-11-24 10:03:45.801982: [TUN] [lhirisseccom01] Starting WireGuard/0.3.1 (Windows 10.0.18363; amd64) 2020-11-24 10:03:45.803758: [TUN] [lhirisseccom01] Watching network interfaces 2020-11-24 10:03:45.809030: [TUN] [lhirisseccom01] Resolving DNS names 2020-11-24 10:03:45.841602: [TUN] [lhirisseccom01] Creating Wintun interface 2020-11-24 10:03:46.003480: [TUN] [lhirisseccom01] [Wintun] CreateAdapter: Creating adapter 2020-11-24 10:03:48.023642: [TUN] [lhirisseccom01] Using Wintun/0.9 2020-11-24 10:03:48.069741: [TUN] [lhirisseccom01] Enabling firewall rules 2020-11-24 10:03:48.161811: [TUN] [lhirisseccom01] Dropping privileges 2020-11-24 10:03:48.165901: [TUN] [lhirisseccom01] Creating interface instance 2020-11-24 10:03:48.171574: [TUN] [lhirisseccom01] Routine: event worker - started 2020-11-24 10:03:48.174280: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.175675: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.178308: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.179950: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.180986: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.181626: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.185430: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.185934: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.186070: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.187147: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.190237: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.194832: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.196508: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.197094: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.198466: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.199475: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.199475: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.200682: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.201256: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.203447: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.205727: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.208147: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.209167: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.210297: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.211810: [TUN] [lhirisseccom01] Routine: TUN reader - started 2020-11-24 10:03:48.216323: [TUN] [lhirisseccom01] Setting interface configuration 2020-11-24 10:03:48.224604: [TUN] [lhirisseccom01] UAPI: Updating private key 2020-11-24 10:03:48.230859: [TUN] [lhirisseccom01] UAPI: Removing all peers 2020-11-24 10:03:48.238534: [TUN] [lhirisseccom01] UAPI: Transition to peer configuration 2020-11-24 10:03:48.253111: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Created 2020-11-24 10:03:48.257120: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Updating preshared key 2020-11-24 10:03:48.257692: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Updating endpoint 2020-11-24 10:03:48.363693: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Updating persistent keepalive interval 2020-11-24 10:03:48.369795: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Removing all allowedips 2020-11-24 10:03:48.401343: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-11-24 10:03:48.410717: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-11-24 10:03:48.412264: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-11-24 10:03:48.412364: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-11-24 10:03:48.414098: [TUN] [lhirisseccom01] Bringing peers up 2020-11-24 10:03:48.421934: [TUN] [lhirisseccom01] Routine: receive incoming IPv6 - started 2020-11-24 10:03:48.423727: [TUN] [lhirisseccom01] Routine: receive incoming IPv4 - started 2020-11-24 10:03:48.427885: [TUN] [lhirisseccom01] UDP bind has been updated 2020-11-24 10:03:48.428445: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Starting... 2020-11-24 10:03:48.430048: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: sequential receiver - started 2020-11-24 10:03:48.432758: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: sequential sender - started 2020-11-24 10:03:48.434497: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending keepalive packet 2020-11-24 10:03:48.439271: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: nonce worker - started 2020-11-24 10:03:48.439271: [TUN] [lhirisseccom01] Monitoring default v6 routes 2020-11-24 10:03:48.440310: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:03:48.444410: [TUN] [lhirisseccom01] Binding v6 socket to interface 0 (blackhole=false) 2020-11-24 10:03:48.448834: [TUN] [lhirisseccom01] Setting device v6 addresses 2020-11-24 10:03:48.484249: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Awaiting keypair 2020-11-24 10:03:48.501366: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake response 2020-11-24 10:03:48.505199: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Obtained awaited keypair 2020-11-24 10:03:49.717724: [TUN] [lhirisseccom01] Monitoring default v4 routes 2020-11-24 10:03:49.735153: [TUN] [lhirisseccom01] Binding v4 socket to interface 23 (blackhole=false) 2020-11-24 10:03:49.736441: [TUN] [lhirisseccom01] Setting device v4 addresses 2020-11-24 10:03:51.221490: [TUN] [lhirisseccom01] Listening for UAPI requests 2020-11-24 10:03:51.225480: [TUN] [lhirisseccom01] Startup complete 2020-11-24 10:04:08.258064: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Retrying handshake because we stopped hearing back after 15 seconds 2020-11-24 10:04:08.260207: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:13.543272: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 2) 2020-11-24 10:04:13.545765: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:15.196489: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Receiving keepalive packet 2020-11-24 10:04:18.799504: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 3) 2020-11-24 10:04:18.801789: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:23.881986: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 4) 2020-11-24 10:04:23.883677: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:29.189703: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 5) 2020-11-24 10:04:29.191775: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:32.339743: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Retrying handshake because we stopped hearing back after 15 seconds 2020-11-24 10:04:34.334302: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 2) 2020-11-24 10:04:34.336489: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:39.477027: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 3) 2020-11-24 10:04:39.477590: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:41.821019: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Receiving keepalive packet 2020-11-24 10:04:44.741589: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying This is very strange. Thanks Peter ^ permalink raw reply [flat|nested] 27+ messages in thread
* Problems with Windows client over PulseSecure VPN 2020-11-24 10:17 ` Peter Whisker @ 2020-11-26 13:04 ` Peter Whisker 2020-11-26 13:11 ` Jason A. Donenfeld 2021-03-03 10:54 ` Jason A. Donenfeld 0 siblings, 2 replies; 27+ messages in thread From: Peter Whisker @ 2020-11-26 13:04 UTC (permalink / raw) To: WireGuard mailing list Hi I've taken a futher look at this today with client 0.3.1. The issue is establishing a wireguard connection over a PulseConnect SSLVPN. The Tunsafe client which works (I'm using an identical configuration on both it and the Wireguard client) exchanges handshakes and then Keepalives and then starts transporting packets. My source address is 10.209.29.xxx and my destination address is 158.xxx.xxx.xxx. The config is as below. After Tunsafe starts I see the routing created as: C:\Users\whiskerp>route print /4 | find "10.2.80.226" 10.2.0.34 255.255.255.254 10.2.80.1 10.2.80.226 125 10.2.1.34 255.255.255.254 10.2.80.1 10.2.80.226 125 10.2.80.0 255.255.255.0 On-link 10.2.80.226 281 10.2.80.226 255.255.255.255 On-link 10.2.80.226 281 10.2.80.255 255.255.255.255 On-link 10.2.80.226 281 10.12.0.0 255.255.254.0 10.2.80.1 10.2.80.226 125 224.0.0.0 240.0.0.0 On-link 10.2.80.226 281 255.255.255.255 255.255.255.255 On-link 10.2.80.226 281 Wireguard client starts and exchanges handshakes, sends a keepalive but it does not seem to get to the other end. After 25 seconds, a Keepalive is sent by the other end (and noted by Wireguard at 10:04:41 in the log). No traffic is sent. The routing table created by Wireguard is slightly different too: C:\Users\whiskerp>route print /4 | find "10.2.80.226" 10.2.0.34 255.255.255.254 On-link 10.2.80.226 5 10.2.0.35 255.255.255.255 On-link 10.2.80.226 261 10.2.1.34 255.255.255.254 On-link 10.2.80.226 5 10.2.1.35 255.255.255.255 On-link 10.2.80.226 261 10.2.80.0 255.255.255.0 On-link 10.2.80.226 5 10.2.80.226 255.255.255.255 On-link 10.2.80.226 261 10.2.80.255 255.255.255.255 On-link 10.2.80.226 261 10.12.0.0 255.255.254.0 On-link 10.2.80.226 5 10.12.1.255 255.255.255.255 On-link 10.2.80.226 261 Configuration: [Interface] PrivateKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx= Address = 10.2.80.226/32 [Peer] PublicKey = QfjlPwEQa03gx7OYkM3Al8MIrfTx7WY0TT235eg0V1w= PresharedKey = yyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy= AllowedIPs = 10.2.80.0/24, 10.12.0.0/23, 10.2.0.34/31, 10.2.1.34/31 Endpoint = iris-fw1.xxxxxxxxxx.com:21820 PersistentKeepalive = 25 I can connect with Wireguard to another server across the direct interface just not via the PulseConnect SSLVPN. Tunsafe works in both cases. The log is below. I do not see any repeated Handshakes in a Wireguard capture of all interfaces, just the first one and the one 25 seconds later from the remote side. 2020-11-24 10:03:45.801982: [TUN] [lhirisseccom01] Starting WireGuard/0.3.1 (Windows 10.0.18363; amd64) 2020-11-24 10:03:45.803758: [TUN] [lhirisseccom01] Watching network interfaces 2020-11-24 10:03:45.809030: [TUN] [lhirisseccom01] Resolving DNS names 2020-11-24 10:03:45.841602: [TUN] [lhirisseccom01] Creating Wintun interface 2020-11-24 10:03:46.003480: [TUN] [lhirisseccom01] [Wintun] CreateAdapter: Creating adapter 2020-11-24 10:03:48.023642: [TUN] [lhirisseccom01] Using Wintun/0.9 2020-11-24 10:03:48.069741: [TUN] [lhirisseccom01] Enabling firewall rules 2020-11-24 10:03:48.161811: [TUN] [lhirisseccom01] Dropping privileges 2020-11-24 10:03:48.165901: [TUN] [lhirisseccom01] Creating interface instance 2020-11-24 10:03:48.171574: [TUN] [lhirisseccom01] Routine: event worker - started 2020-11-24 10:03:48.174280: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.175675: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.178308: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.179950: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.180986: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.181626: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.185430: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.185934: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.186070: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.187147: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.190237: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.194832: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.196508: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.197094: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.198466: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.199475: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.199475: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.200682: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.201256: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.203447: [TUN] [lhirisseccom01] Routine: encryption worker - started 2020-11-24 10:03:48.205727: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.208147: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.209167: [TUN] [lhirisseccom01] Routine: handshake worker - started 2020-11-24 10:03:48.210297: [TUN] [lhirisseccom01] Routine: decryption worker - started 2020-11-24 10:03:48.211810: [TUN] [lhirisseccom01] Routine: TUN reader - started 2020-11-24 10:03:48.216323: [TUN] [lhirisseccom01] Setting interface configuration 2020-11-24 10:03:48.224604: [TUN] [lhirisseccom01] UAPI: Updating private key 2020-11-24 10:03:48.230859: [TUN] [lhirisseccom01] UAPI: Removing all peers 2020-11-24 10:03:48.238534: [TUN] [lhirisseccom01] UAPI: Transition to peer configuration 2020-11-24 10:03:48.253111: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Created 2020-11-24 10:03:48.257120: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Updating preshared key 2020-11-24 10:03:48.257692: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Updating endpoint 2020-11-24 10:03:48.363693: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Updating persistent keepalive interval 2020-11-24 10:03:48.369795: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Removing all allowedips 2020-11-24 10:03:48.401343: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-11-24 10:03:48.410717: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-11-24 10:03:48.412264: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-11-24 10:03:48.412364: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - UAPI: Adding allowedip 2020-11-24 10:03:48.414098: [TUN] [lhirisseccom01] Bringing peers up 2020-11-24 10:03:48.421934: [TUN] [lhirisseccom01] Routine: receive incoming IPv6 - started 2020-11-24 10:03:48.423727: [TUN] [lhirisseccom01] Routine: receive incoming IPv4 - started 2020-11-24 10:03:48.427885: [TUN] [lhirisseccom01] UDP bind has been updated 2020-11-24 10:03:48.428445: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Starting... 2020-11-24 10:03:48.430048: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: sequential receiver - started 2020-11-24 10:03:48.432758: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: sequential sender - started 2020-11-24 10:03:48.434497: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending keepalive packet 2020-11-24 10:03:48.439271: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Routine: nonce worker - started 2020-11-24 10:03:48.439271: [TUN] [lhirisseccom01] Monitoring default v6 routes 2020-11-24 10:03:48.440310: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:03:48.444410: [TUN] [lhirisseccom01] Binding v6 socket to interface 0 (blackhole=false) 2020-11-24 10:03:48.448834: [TUN] [lhirisseccom01] Setting device v6 addresses 2020-11-24 10:03:48.484249: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Awaiting keypair 2020-11-24 10:03:48.501366: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Received handshake response 2020-11-24 10:03:48.505199: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Obtained awaited keypair 2020-11-24 10:03:49.717724: [TUN] [lhirisseccom01] Monitoring default v4 routes 2020-11-24 10:03:49.735153: [TUN] [lhirisseccom01] Binding v4 socket to interface 23 (blackhole=false) 2020-11-24 10:03:49.736441: [TUN] [lhirisseccom01] Setting device v4 addresses 2020-11-24 10:03:51.221490: [TUN] [lhirisseccom01] Listening for UAPI requests 2020-11-24 10:03:51.225480: [TUN] [lhirisseccom01] Startup complete 2020-11-24 10:04:08.258064: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Retrying handshake because we stopped hearing back after 15 seconds 2020-11-24 10:04:08.260207: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:13.543272: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 2) 2020-11-24 10:04:13.545765: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:15.196489: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Receiving keepalive packet 2020-11-24 10:04:18.799504: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 3) 2020-11-24 10:04:18.801789: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:23.881986: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 4) 2020-11-24 10:04:23.883677: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:29.189703: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 5) 2020-11-24 10:04:29.191775: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:32.339743: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Retrying handshake because we stopped hearing back after 15 seconds 2020-11-24 10:04:34.334302: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 2) 2020-11-24 10:04:34.336489: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:39.477027: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying (try 3) 2020-11-24 10:04:39.477590: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Sending handshake initiation 2020-11-24 10:04:41.821019: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Receiving keepalive packet 2020-11-24 10:04:44.741589: [TUN] [lhirisseccom01] peer(Qfjl…0V1w) - Handshake did not complete after 5 seconds, retrying This is very strange. Thanks Peter ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2020-11-26 13:04 ` Problems with Windows client over PulseSecure VPN Peter Whisker @ 2020-11-26 13:11 ` Jason A. Donenfeld [not found] ` <2dc629e2-93c9-4ed9-ea57-4318c8b62a73@gmail.com> 2021-03-03 10:54 ` Jason A. Donenfeld 1 sibling, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2020-11-26 13:11 UTC (permalink / raw) To: Peter Whisker; +Cc: WireGuard mailing list Is PulseSecure not setting up a /0 route? If so, then this is a known issue with the lack of policy routing on Windows. ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <2dc629e2-93c9-4ed9-ea57-4318c8b62a73@gmail.com>]
* Re: Problems with Windows client over PulseSecure VPN [not found] ` <2dc629e2-93c9-4ed9-ea57-4318c8b62a73@gmail.com> @ 2021-01-13 15:13 ` Peter Whisker [not found] ` <CAN5wt5r9rQpYcCkshBimOARoAxx7T529oUw6RSNnr4q3_y_31g@mail.gmail.com> 0 siblings, 1 reply; 27+ messages in thread From: Peter Whisker @ 2021-01-13 15:13 UTC (permalink / raw) To: WireGuard mailing list Hi I have managed to work around the issue caused by Wireguard sending packets via default route interface even though the route to the peer is over a different interface (the issue caused by IP_UNICAST_IF). My Wireguard peer is down a corporate Pulse Secure tunnel. I use a PreUp and PostDown script as follows: PreUp ===== for /f "tokens=3" %%a in ('route print -4 0.0.0.0^| find "0.0.0.0"') do if not defined ip set ip=%%a route add 0.0.0.0 mask 128.0.0.0 %ip% METRIC 1 route add 128.0.0.0 mask 128.0.0.0 %ip% METRIC 1 route delete 0.0.0.0 mask 0.0.0.0 PostDown ======== for /f "tokens=3" %%a in ('route print -4 0.0.0.0^| find "0.0.0.0"') do if not defined ip set ip=%%a route add 0.0.0.0 mask 0.0.0.0 %ip% METRIC 1 route delete 0.0.0.0 mask 128.0.0.0 route delete 128.0.0.0 mask 128.0.0.0 This replaces the /0 default route by two /1 routes before bringing up the WireGuard interface. Traffic to the peer then gets sent down the correct route (why is this different from having a default route?). When the WireGuard instance is closed, it recreates the default route and removes the two /1 routes. Is there a way this could be done better in the Wireguard executable (I am currently using 0.3.4). Thanks Peter On 26/11/2020 13:11, Jason A. Donenfeld wrote: >> Is PulseSecure not setting up a /0 route? If so, then this is a known >> issue with the lack of policy routing on Windows. ^ permalink raw reply [flat|nested] 27+ messages in thread
[parent not found: <CAN5wt5r9rQpYcCkshBimOARoAxx7T529oUw6RSNnr4q3_y_31g@mail.gmail.com>]
* Fwd: Problems with Windows client over PulseSecure VPN [not found] ` <CAN5wt5r9rQpYcCkshBimOARoAxx7T529oUw6RSNnr4q3_y_31g@mail.gmail.com> @ 2021-01-15 10:32 ` Christopher Ng 2021-01-19 8:53 ` Peter Whisker 2021-01-19 10:39 ` Peter Whisker 0 siblings, 2 replies; 27+ messages in thread From: Christopher Ng @ 2021-01-15 10:32 UTC (permalink / raw) To: WireGuard mailing list ---------- Forwarded message --------- From: Christopher Ng <facboy@gmail.com> Date: Fri, 15 Jan 2021 at 09:46 Subject: Re: Problems with Windows client over PulseSecure VPN To: Peter Whisker <peter.whisker@gmail.com> i fixed this in my local build by disabling the binding in defaultroutemonitor.go. tbh i'm not sure what it's for, i found an old discussion (about linux) about not binding to only one interface, so i'm not sure why Windows binds to one interface. diff --git a/tunnel/defaultroutemonitor.go b/tunnel/defaultroutemonitor.go index 6ee95129..12456332 100644 --- a/tunnel/defaultroutemonitor.go +++ b/tunnel/defaultroutemonitor.go @@ -6,12 +6,10 @@ package tunnel import ( - "log" "sync" "time" "golang.org/x/sys/windows" - "golang.zx2c4.com/wireguard/conn" "golang.zx2c4.com/wireguard/device" "golang.zx2c4.com/wireguard/tun" "golang.zx2c4.com/wireguard/windows/tunnel/winipcfg" @@ -50,18 +48,22 @@ func bindSocketRoute(family winipcfg.AddressFamily, device *device.Device, ourLU } *lastLUID = luid *lastIndex = index - blackhole := blackholeWhenLoop && index == 0 - bind, _ := device.Bind().(conn.BindSocketToInterface) - if bind == nil { - return nil - } - if family == windows.AF_INET { - log.Printf("Binding v4 socket to interface %d (blackhole=%v)", index, blackhole) - return bind.BindSocketToInterface4(index, blackhole) - } else if family == windows.AF_INET6 { - log.Printf("Binding v6 socket to interface %d (blackhole=%v)", index, blackhole) - return bind.BindSocketToInterface6(index, blackhole) - } + // disable this because if my peers are on different interfaces...well i don't know how it can work. i can't + // bind the socket to only one of them + /* + blackhole := blackholeWhenLoop && index == 0 + bind, _ := device.Bind().(conn.BindSocketToInterface) + if bind == nil { + return nil + } + if family == windows.AF_INET { + log.Printf("Binding v4 socket to interface %d (blackhole=%v)", index, blackhole) + return bind.BindSocketToInterface4(index, blackhole) + } else if family == windows.AF_INET6 { + log.Printf("Binding v6 socket to interface %d (blackhole=%v)", index, blackhole) + return bind.BindSocketToInterface6(index, blackhole) + } + */ return nil } On Wed, 13 Jan 2021 at 17:06, Peter Whisker <peter.whisker@gmail.com> wrote: > > Hi > > I have managed to work around the issue caused by Wireguard sending > packets via default route interface even though the route to the peer is > over a different interface (the issue caused by IP_UNICAST_IF). My > Wireguard peer is down a corporate Pulse Secure tunnel. > > I use a PreUp and PostDown script as follows: > > PreUp > ===== > > for /f "tokens=3" %%a in ('route print -4 0.0.0.0^| find "0.0.0.0"') do > if not defined ip set ip=%%a > route add 0.0.0.0 mask 128.0.0.0 %ip% METRIC 1 > route add 128.0.0.0 mask 128.0.0.0 %ip% METRIC 1 > route delete 0.0.0.0 mask 0.0.0.0 > > PostDown > ======== > > for /f "tokens=3" %%a in ('route print -4 0.0.0.0^| find "0.0.0.0"') do > if not defined ip set ip=%%a > route add 0.0.0.0 mask 0.0.0.0 %ip% METRIC 1 > route delete 0.0.0.0 mask 128.0.0.0 > route delete 128.0.0.0 mask 128.0.0.0 > > This replaces the /0 default route by two /1 routes before bringing up > the WireGuard interface. Traffic to the peer then gets sent down the > correct route (why is this different from having a default route?). When > the WireGuard instance is closed, it recreates the default route and > removes the two /1 routes. > > Is there a way this could be done better in the Wireguard executable (I > am currently using 0.3.4). > > Thanks > > Peter > > On 26/11/2020 13:11, Jason A. Donenfeld wrote: > >> Is PulseSecure not setting up a /0 route? If so, then this is a known > >> issue with the lack of policy routing on Windows. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Fwd: Problems with Windows client over PulseSecure VPN 2021-01-15 10:32 ` Fwd: " Christopher Ng @ 2021-01-19 8:53 ` Peter Whisker 2021-01-30 10:51 ` Christopher Ng 2021-01-19 10:39 ` Peter Whisker 1 sibling, 1 reply; 27+ messages in thread From: Peter Whisker @ 2021-01-19 8:53 UTC (permalink / raw) To: wireguard Hi Thanks, maybe the powers-that-be would consider your change to be a fix and accept it into the next release? I guess by removing the default route I am causing the bind to fail as it doesn't know which interface to bind to which has the same result as removing the bind. The bit of code you removed certainly causes problems! Thanks Peter On 15/01/2021 10:32, Christopher Ng wrote: > ---------- Forwarded message --------- > From: Christopher Ng <facboy@gmail.com> > Date: Fri, 15 Jan 2021 at 09:46 > Subject: Re: Problems with Windows client over PulseSecure VPN > To: Peter Whisker <peter.whisker@gmail.com> > > > i fixed this in my local build by disabling the binding in > defaultroutemonitor.go. tbh i'm not sure what it's for, i found an > old discussion (about linux) about not binding to only one interface, > so i'm not sure why Windows binds to one interface. > > diff --git a/tunnel/defaultroutemonitor.go b/tunnel/defaultroutemonitor.go > index 6ee95129..12456332 100644 > --- a/tunnel/defaultroutemonitor.go > +++ b/tunnel/defaultroutemonitor.go > @@ -6,12 +6,10 @@ > package tunnel > > import ( > - "log" > "sync" > "time" > > "golang.org/x/sys/windows" > - "golang.zx2c4.com/wireguard/conn" > "golang.zx2c4.com/wireguard/device" > "golang.zx2c4.com/wireguard/tun" > "golang.zx2c4.com/wireguard/windows/tunnel/winipcfg" > @@ -50,18 +48,22 @@ func bindSocketRoute(family > winipcfg.AddressFamily, device *device.Device, ourLU > } > *lastLUID = luid > *lastIndex = index > - blackhole := blackholeWhenLoop && index == 0 > - bind, _ := device.Bind().(conn.BindSocketToInterface) > - if bind == nil { > - return nil > - } > - if family == windows.AF_INET { > - log.Printf("Binding v4 socket to interface %d > (blackhole=%v)", index, blackhole) > - return bind.BindSocketToInterface4(index, blackhole) > - } else if family == windows.AF_INET6 { > - log.Printf("Binding v6 socket to interface %d > (blackhole=%v)", index, blackhole) > - return bind.BindSocketToInterface6(index, blackhole) > - } > + // disable this because if my peers are on different > interfaces...well i don't know how it can work. i can't > + // bind the socket to only one of them > + /* > + blackhole := blackholeWhenLoop && index == 0 > + bind, _ := device.Bind().(conn.BindSocketToInterface) > + if bind == nil { > + return nil > + } > + if family == windows.AF_INET { > + log.Printf("Binding v4 socket to interface %d > (blackhole=%v)", index, blackhole) > + return bind.BindSocketToInterface4(index, blackhole) > + } else if family == windows.AF_INET6 { > + log.Printf("Binding v6 socket to interface %d > (blackhole=%v)", index, blackhole) > + return bind.BindSocketToInterface6(index, blackhole) > + } > + */ > return nil > } > > On Wed, 13 Jan 2021 at 17:06, Peter Whisker <peter.whisker@gmail.com> wrote: >> Hi >> >> I have managed to work around the issue caused by Wireguard sending >> packets via default route interface even though the route to the peer is >> over a different interface (the issue caused by IP_UNICAST_IF). My >> Wireguard peer is down a corporate Pulse Secure tunnel. >> >> I use a PreUp and PostDown script as follows: >> >> PreUp >> ===== >> >> for /f "tokens=3" %%a in ('route print -4 0.0.0.0^| find "0.0.0.0"') do >> if not defined ip set ip=%%a >> route add 0.0.0.0 mask 128.0.0.0 %ip% METRIC 1 >> route add 128.0.0.0 mask 128.0.0.0 %ip% METRIC 1 >> route delete 0.0.0.0 mask 0.0.0.0 >> >> PostDown >> ======== >> >> for /f "tokens=3" %%a in ('route print -4 0.0.0.0^| find "0.0.0.0"') do >> if not defined ip set ip=%%a >> route add 0.0.0.0 mask 0.0.0.0 %ip% METRIC 1 >> route delete 0.0.0.0 mask 128.0.0.0 >> route delete 128.0.0.0 mask 128.0.0.0 >> >> This replaces the /0 default route by two /1 routes before bringing up >> the WireGuard interface. Traffic to the peer then gets sent down the >> correct route (why is this different from having a default route?). When >> the WireGuard instance is closed, it recreates the default route and >> removes the two /1 routes. >> >> Is there a way this could be done better in the Wireguard executable (I >> am currently using 0.3.4). >> >> Thanks >> >> Peter >> >> On 26/11/2020 13:11, Jason A. Donenfeld wrote: >>>> Is PulseSecure not setting up a /0 route? If so, then this is a known >>>> issue with the lack of policy routing on Windows. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Fwd: Problems with Windows client over PulseSecure VPN 2021-01-19 8:53 ` Peter Whisker @ 2021-01-30 10:51 ` Christopher Ng 0 siblings, 0 replies; 27+ messages in thread From: Christopher Ng @ 2021-01-30 10:51 UTC (permalink / raw) To: Peter Whisker; +Cc: WireGuard mailing list no problem. On Sun, 24 Jan 2021 at 16:26, Peter Whisker <peter.whisker@gmail.com> wrote: > > Hi > > Thanks, maybe the powers-that-be would consider your change to be a fix > and accept it into the next release? I guess by removing the default > route I am causing the bind to fail as it doesn't know which interface > to bind to which has the same result as removing the bind. The bit of > code you removed certainly causes problems! > > Thanks > Peter > > On 15/01/2021 10:32, Christopher Ng wrote: > > ---------- Forwarded message --------- > > From: Christopher Ng <facboy@gmail.com> > > Date: Fri, 15 Jan 2021 at 09:46 > > Subject: Re: Problems with Windows client over PulseSecure VPN > > To: Peter Whisker <peter.whisker@gmail.com> > > > > > > i fixed this in my local build by disabling the binding in > > defaultroutemonitor.go. tbh i'm not sure what it's for, i found an > > old discussion (about linux) about not binding to only one interface, > > so i'm not sure why Windows binds to one interface. > > > > diff --git a/tunnel/defaultroutemonitor.go b/tunnel/defaultroutemonitor.go > > index 6ee95129..12456332 100644 > > --- a/tunnel/defaultroutemonitor.go > > +++ b/tunnel/defaultroutemonitor.go > > @@ -6,12 +6,10 @@ > > package tunnel > > > > import ( > > - "log" > > "sync" > > "time" > > > > "golang.org/x/sys/windows" > > - "golang.zx2c4.com/wireguard/conn" > > "golang.zx2c4.com/wireguard/device" > > "golang.zx2c4.com/wireguard/tun" > > "golang.zx2c4.com/wireguard/windows/tunnel/winipcfg" > > @@ -50,18 +48,22 @@ func bindSocketRoute(family > > winipcfg.AddressFamily, device *device.Device, ourLU > > } > > *lastLUID = luid > > *lastIndex = index > > - blackhole := blackholeWhenLoop && index == 0 > > - bind, _ := device.Bind().(conn.BindSocketToInterface) > > - if bind == nil { > > - return nil > > - } > > - if family == windows.AF_INET { > > - log.Printf("Binding v4 socket to interface %d > > (blackhole=%v)", index, blackhole) > > - return bind.BindSocketToInterface4(index, blackhole) > > - } else if family == windows.AF_INET6 { > > - log.Printf("Binding v6 socket to interface %d > > (blackhole=%v)", index, blackhole) > > - return bind.BindSocketToInterface6(index, blackhole) > > - } > > + // disable this because if my peers are on different > > interfaces...well i don't know how it can work. i can't > > + // bind the socket to only one of them > > + /* > > + blackhole := blackholeWhenLoop && index == 0 > > + bind, _ := device.Bind().(conn.BindSocketToInterface) > > + if bind == nil { > > + return nil > > + } > > + if family == windows.AF_INET { > > + log.Printf("Binding v4 socket to interface %d > > (blackhole=%v)", index, blackhole) > > + return bind.BindSocketToInterface4(index, blackhole) > > + } else if family == windows.AF_INET6 { > > + log.Printf("Binding v6 socket to interface %d > > (blackhole=%v)", index, blackhole) > > + return bind.BindSocketToInterface6(index, blackhole) > > + } > > + */ > > return nil > > } > > > > On Wed, 13 Jan 2021 at 17:06, Peter Whisker <peter.whisker@gmail.com> wrote: > >> Hi > >> > >> I have managed to work around the issue caused by Wireguard sending > >> packets via default route interface even though the route to the peer is > >> over a different interface (the issue caused by IP_UNICAST_IF). My > >> Wireguard peer is down a corporate Pulse Secure tunnel. > >> > >> I use a PreUp and PostDown script as follows: > >> > >> PreUp > >> ===== > >> > >> for /f "tokens=3" %%a in ('route print -4 0.0.0.0^| find "0.0.0.0"') do > >> if not defined ip set ip=%%a > >> route add 0.0.0.0 mask 128.0.0.0 %ip% METRIC 1 > >> route add 128.0.0.0 mask 128.0.0.0 %ip% METRIC 1 > >> route delete 0.0.0.0 mask 0.0.0.0 > >> > >> PostDown > >> ======== > >> > >> for /f "tokens=3" %%a in ('route print -4 0.0.0.0^| find "0.0.0.0"') do > >> if not defined ip set ip=%%a > >> route add 0.0.0.0 mask 0.0.0.0 %ip% METRIC 1 > >> route delete 0.0.0.0 mask 128.0.0.0 > >> route delete 128.0.0.0 mask 128.0.0.0 > >> > >> This replaces the /0 default route by two /1 routes before bringing up > >> the WireGuard interface. Traffic to the peer then gets sent down the > >> correct route (why is this different from having a default route?). When > >> the WireGuard instance is closed, it recreates the default route and > >> removes the two /1 routes. > >> > >> Is there a way this could be done better in the Wireguard executable (I > >> am currently using 0.3.4). > >> > >> Thanks > >> > >> Peter > >> > >> On 26/11/2020 13:11, Jason A. Donenfeld wrote: > >>>> Is PulseSecure not setting up a /0 route? If so, then this is a known > >>>> issue with the lack of policy routing on Windows. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Fwd: Problems with Windows client over PulseSecure VPN 2021-01-15 10:32 ` Fwd: " Christopher Ng 2021-01-19 8:53 ` Peter Whisker @ 2021-01-19 10:39 ` Peter Whisker 2021-03-02 21:32 ` Steffen Sledz 1 sibling, 1 reply; 27+ messages in thread From: Peter Whisker @ 2021-01-19 10:39 UTC (permalink / raw) To: wireguard Hi I built Wireguard with the change you made below and confirm it fixes the longstanding problem I had - I can now connect to a peer over the PulseSecure tunnel and even simultaneously connect to another peer over the default route (with the MultipleSimultaneousTunnels=1 registry entry). Is there a reason this fix can not be adopted? Peter On 15/01/2021 10:32, Christopher Ng wrote: > ---------- Forwarded message --------- > From: Christopher Ng <facboy@gmail.com> > Date: Fri, 15 Jan 2021 at 09:46 > Subject: Re: Problems with Windows client over PulseSecure VPN > To: Peter Whisker <peter.whisker@gmail.com> > > > i fixed this in my local build by disabling the binding in > defaultroutemonitor.go. tbh i'm not sure what it's for, i found an > old discussion (about linux) about not binding to only one interface, > so i'm not sure why Windows binds to one interface. > > diff --git a/tunnel/defaultroutemonitor.go b/tunnel/defaultroutemonitor.go > index 6ee95129..12456332 100644 > --- a/tunnel/defaultroutemonitor.go > +++ b/tunnel/defaultroutemonitor.go > @@ -6,12 +6,10 @@ > package tunnel > > import ( > - "log" > "sync" > "time" > > "golang.org/x/sys/windows" > - "golang.zx2c4.com/wireguard/conn" > "golang.zx2c4.com/wireguard/device" > "golang.zx2c4.com/wireguard/tun" > "golang.zx2c4.com/wireguard/windows/tunnel/winipcfg" > @@ -50,18 +48,22 @@ func bindSocketRoute(family > winipcfg.AddressFamily, device *device.Device, ourLU > } > *lastLUID = luid > *lastIndex = index > - blackhole := blackholeWhenLoop && index == 0 > - bind, _ := device.Bind().(conn.BindSocketToInterface) > - if bind == nil { > - return nil > - } > - if family == windows.AF_INET { > - log.Printf("Binding v4 socket to interface %d > (blackhole=%v)", index, blackhole) > - return bind.BindSocketToInterface4(index, blackhole) > - } else if family == windows.AF_INET6 { > - log.Printf("Binding v6 socket to interface %d > (blackhole=%v)", index, blackhole) > - return bind.BindSocketToInterface6(index, blackhole) > - } > + // disable this because if my peers are on different > interfaces...well i don't know how it can work. i can't > + // bind the socket to only one of them > + /* > + blackhole := blackholeWhenLoop && index == 0 > + bind, _ := device.Bind().(conn.BindSocketToInterface) > + if bind == nil { > + return nil > + } > + if family == windows.AF_INET { > + log.Printf("Binding v4 socket to interface %d > (blackhole=%v)", index, blackhole) > + return bind.BindSocketToInterface4(index, blackhole) > + } else if family == windows.AF_INET6 { > + log.Printf("Binding v6 socket to interface %d > (blackhole=%v)", index, blackhole) > + return bind.BindSocketToInterface6(index, blackhole) > + } > + */ > return nil > } > > On Wed, 13 Jan 2021 at 17:06, Peter Whisker <peter.whisker@gmail.com> wrote: >> Hi >> >> I have managed to work around the issue caused by Wireguard sending >> packets via default route interface even though the route to the peer is >> over a different interface (the issue caused by IP_UNICAST_IF). My >> Wireguard peer is down a corporate Pulse Secure tunnel. >> >> I use a PreUp and PostDown script as follows: >> >> PreUp >> ===== >> >> for /f "tokens=3" %%a in ('route print -4 0.0.0.0^| find "0.0.0.0"') do >> if not defined ip set ip=%%a >> route add 0.0.0.0 mask 128.0.0.0 %ip% METRIC 1 >> route add 128.0.0.0 mask 128.0.0.0 %ip% METRIC 1 >> route delete 0.0.0.0 mask 0.0.0.0 >> >> PostDown >> ======== >> >> for /f "tokens=3" %%a in ('route print -4 0.0.0.0^| find "0.0.0.0"') do >> if not defined ip set ip=%%a >> route add 0.0.0.0 mask 0.0.0.0 %ip% METRIC 1 >> route delete 0.0.0.0 mask 128.0.0.0 >> route delete 128.0.0.0 mask 128.0.0.0 >> >> This replaces the /0 default route by two /1 routes before bringing up >> the WireGuard interface. Traffic to the peer then gets sent down the >> correct route (why is this different from having a default route?). When >> the WireGuard instance is closed, it recreates the default route and >> removes the two /1 routes. >> >> Is there a way this could be done better in the Wireguard executable (I >> am currently using 0.3.4). >> >> Thanks >> >> Peter >> >> On 26/11/2020 13:11, Jason A. Donenfeld wrote: >>>> Is PulseSecure not setting up a /0 route? If so, then this is a known >>>> issue with the lack of policy routing on Windows. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Fwd: Problems with Windows client over PulseSecure VPN 2021-01-19 10:39 ` Peter Whisker @ 2021-03-02 21:32 ` Steffen Sledz 0 siblings, 0 replies; 27+ messages in thread From: Steffen Sledz @ 2021-03-02 21:32 UTC (permalink / raw) To: Peter Whisker, wireguard On 19.01.21 11:39, Peter Whisker wrote: > I built Wireguard with the change you made below and ... > > Is there a reason this fix can not be adopted? According to https://www.wireguard.com/repositories/ should send a properly formatted patch including a Signed-off-by: line using git-send-email to this list. I suggest to CC the maintainers of the wireguard-windows repo Simon Rozman <simon@rozman.si> and Jason A. Donenfeld <Jason@zx2c4.com>. Regards, Steffen ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2020-11-26 13:04 ` Problems with Windows client over PulseSecure VPN Peter Whisker 2020-11-26 13:11 ` Jason A. Donenfeld @ 2021-03-03 10:54 ` Jason A. Donenfeld 2021-03-03 12:01 ` Heiko Kendziorra ` (3 more replies) 1 sibling, 4 replies; 27+ messages in thread From: Jason A. Donenfeld @ 2021-03-03 10:54 UTC (permalink / raw) To: Peter Whisker; +Cc: WireGuard mailing list Hey Peter, I had a strange idea for how to fix this without requiring recompilation or removal of that code. 1) Enable DangerousScriptExecution: https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md#hklmsoftwarewireguarddangerousscriptexecution 2) Add a PostUp line to your [Interface] section: PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0 3) Try it and tell me if it works? Regards, Jason ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2021-03-03 10:54 ` Jason A. Donenfeld @ 2021-03-03 12:01 ` Heiko Kendziorra 2021-03-04 9:11 ` Peter Whisker ` (2 subsequent siblings) 3 siblings, 0 replies; 27+ messages in thread From: Heiko Kendziorra @ 2021-03-03 12:01 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: Peter Whisker, WireGuard mailing list Hi Jakson, your hint helped for my Problem: https://lists.zx2c4.com/pipermail/wireguard/2021-February/006431.html Thanks a lot! Am Mi., 3. März 2021 um 11:59 Uhr schrieb Jason A. Donenfeld <Jason@zx2c4.com>: > > Hey Peter, > > I had a strange idea for how to fix this without requiring > recompilation or removal of that code. > > 1) Enable DangerousScriptExecution: > https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md#hklmsoftwarewireguarddangerousscriptexecution > > 2) Add a PostUp line to your [Interface] section: > > PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0 > > 3) Try it and tell me if it works? > > Regards, > Jason -- Mit freundlichen Grüßen • With best regards Heiko Kendziorra ----------------------------------------------------------------------------------- Heiko Kendziorra Softwareentwicklung • Software Development DResearch Fahrzeugelektronik GmbH Tor 2, Aufgang R (R03.020) Wolfener Straße 36 12681 Berlin Phone: +49 (30) 515 932 - 265 Fax: +49 (30) 515 932 - 77 Mail: kendziorra@dresearch-fe.de Web: www.dresearch-fe.de General Management • Geschäftsführung: Dr. Michael Weber, Marc-Oliver Brammann Amtsgericht Berlin Charlottenburg; HRB 130120; Ust.-IDNr. DE273952058 Kunden Support/Customer support: Mail: support@dresearch-fe.de Hotline +49 (30) 515 932 112, Mo. - Do. 10:00 Uhr - 16:00 Uhr, Freitags von 10:00 bis 13:00 Uhr ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2021-03-03 10:54 ` Jason A. Donenfeld 2021-03-03 12:01 ` Heiko Kendziorra @ 2021-03-04 9:11 ` Peter Whisker 2021-03-04 13:07 ` Jason A. Donenfeld 2021-03-23 11:01 ` Christopher Ng 2021-07-29 11:00 ` Jason A. Donenfeld 3 siblings, 1 reply; 27+ messages in thread From: Peter Whisker @ 2021-03-04 9:11 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list Hi Jason Yes, that PostUp line does solve the problem. Thanks! Four tunnels up and working with two of them via the PulseSecure VPN. :) Can I ask why you have the section bind code in there when it seems to work fine without it? Regards Peter On 03/03/2021 10:54, Jason A. Donenfeld wrote: > Hey Peter, > > I had a strange idea for how to fix this without requiring > recompilation or removal of that code. > > 1) Enable DangerousScriptExecution: > https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md#hklmsoftwarewireguarddangerousscriptexecution > > 2) Add a PostUp line to your [Interface] section: > > PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0 > > 3) Try it and tell me if it works? > > Regards, > Jason ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2021-03-04 9:11 ` Peter Whisker @ 2021-03-04 13:07 ` Jason A. Donenfeld 0 siblings, 0 replies; 27+ messages in thread From: Jason A. Donenfeld @ 2021-03-04 13:07 UTC (permalink / raw) To: Peter Whisker; +Cc: WireGuard mailing list On 3/4/21, Peter Whisker <peter.whisker@gmail.com> wrote: > Hi Jason > > Yes, that PostUp line does solve the problem. Thanks! Four tunnels up > and working with two of them via the PulseSecure VPN. :) > > Can I ask why you have the section bind code in there when it seems to > work fine without it? https://lore.kernel.org/wireguard/CAHmME9rXV2_YG3fGMErDeTjfHeNKhDC2cCYA6Kw93n9A328QpQ@mail.gmail.com/ ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2021-03-03 10:54 ` Jason A. Donenfeld 2021-03-03 12:01 ` Heiko Kendziorra 2021-03-04 9:11 ` Peter Whisker @ 2021-03-23 11:01 ` Christopher Ng 2021-04-14 9:40 ` Christopher Ng 2021-07-29 11:00 ` Jason A. Donenfeld 3 siblings, 1 reply; 27+ messages in thread From: Christopher Ng @ 2021-03-23 11:01 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list this sort of works for me too, the only problem is 'wg set' never returns (even on the CLI) so the tunnel activation hangs in 'activating' waiting for it to return, which it never does. this is on 0.3.9 in windows On Wed, 3 Mar 2021 at 10:56, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > Hey Peter, > > I had a strange idea for how to fix this without requiring > recompilation or removal of that code. > > 1) Enable DangerousScriptExecution: > https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md#hklmsoftwarewireguarddangerousscriptexecution > > 2) Add a PostUp line to your [Interface] section: > > PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0 > > 3) Try it and tell me if it works? > > Regards, > Jason ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2021-03-23 11:01 ` Christopher Ng @ 2021-04-14 9:40 ` Christopher Ng 2021-04-14 20:19 ` Jason A. Donenfeld 0 siblings, 1 reply; 27+ messages in thread From: Christopher Ng @ 2021-04-14 9:40 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list not sure why this happens on my machine, but changing the command to PostUp = powershell -Command "& {Start-Process -FilePath \"c:\program files\wireguard\wg.exe\" -ArgumentList \"set my-tunnel listen-port 0\"}" works for me and doesn't hang the Wireguard UI On Tue, 23 Mar 2021 at 11:01, Christopher Ng <facboy@gmail.com> wrote: > > this sort of works for me too, the only problem is 'wg set' never > returns (even on the CLI) so the tunnel activation hangs in > 'activating' waiting for it to return, which it never does. this is > on 0.3.9 in windows > > On Wed, 3 Mar 2021 at 10:56, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > > > Hey Peter, > > > > I had a strange idea for how to fix this without requiring > > recompilation or removal of that code. > > > > 1) Enable DangerousScriptExecution: > > https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md#hklmsoftwarewireguarddangerousscriptexecution > > > > 2) Add a PostUp line to your [Interface] section: > > > > PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0 > > > > 3) Try it and tell me if it works? > > > > Regards, > > Jason ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2021-04-14 9:40 ` Christopher Ng @ 2021-04-14 20:19 ` Jason A. Donenfeld 2021-04-14 21:17 ` Christopher Ng 0 siblings, 1 reply; 27+ messages in thread From: Jason A. Donenfeld @ 2021-04-14 20:19 UTC (permalink / raw) To: Christopher Ng; +Cc: WireGuard mailing list Sounds like you probably have an older version of wg.exe somewhere with higher precedence in your PATH. Perhaps C:\windows\system32? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2021-04-14 20:19 ` Jason A. Donenfeld @ 2021-04-14 21:17 ` Christopher Ng 0 siblings, 0 replies; 27+ messages in thread From: Christopher Ng @ 2021-04-14 21:17 UTC (permalink / raw) To: Jason A. Donenfeld; +Cc: WireGuard mailing list ah good call, there was an old version there! now works fine with the vanilla PostUp you suggested. On Wed, 14 Apr 2021 at 21:19, Jason A. Donenfeld <Jason@zx2c4.com> wrote: > > Sounds like you probably have an older version of wg.exe somewhere > with higher precedence in your PATH. Perhaps C:\windows\system32? ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2021-03-03 10:54 ` Jason A. Donenfeld ` (2 preceding siblings ...) 2021-03-23 11:01 ` Christopher Ng @ 2021-07-29 11:00 ` Jason A. Donenfeld 2021-07-30 7:28 ` Peter Whisker 2021-08-03 8:57 ` Peter Whisker 3 siblings, 2 replies; 27+ messages in thread From: Jason A. Donenfeld @ 2021-07-29 11:00 UTC (permalink / raw) To: Peter Whisker, Heiko Kendziorra, Christopher Ng; +Cc: WireGuard mailing list Hi Peter, Heiko, Christopher, and others, An update on: > I had a strange idea for how to fix this without requiring > recompilation or removal of that code. > > 1) Enable DangerousScriptExecution: > https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md#hklmsoftwarewireguarddangerousscriptexecution > > 2) Add a PostUp line to your [Interface] section: > > PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0 I just wanted to let you know that this problem has been entirely fixed (I think?) in the "WireGuardNT" kernel driver project I've been working on (and haven't yet announced aside from development screenshots on Twitter), and therefore the above steps will no longer be necessary. When that ships as part of the v0.4 series of the normal wireguard-windows client, you won't need the "listen-port 0" hack anymore, as the kernel driver uses a more clever trick than the one used by wireguard-go. So please do watch this mailing list in the next few weeks for an announcement of that project, as I'll be very interested in some real world tests and confirmation of the fix. Thanks, Jason ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2021-07-29 11:00 ` Jason A. Donenfeld @ 2021-07-30 7:28 ` Peter Whisker 2021-07-30 15:57 ` Jason A. Donenfeld 2021-08-03 8:57 ` Peter Whisker 1 sibling, 1 reply; 27+ messages in thread From: Peter Whisker @ 2021-07-30 7:28 UTC (permalink / raw) To: Jason A. Donenfeld, Heiko Kendziorra, Christopher Ng Cc: WireGuard mailing list Thanks Jason. Does this mean that the driver speed will improve as it will move out of user space into the Windows Kernel in a similar way to Linux? Peter On 29/07/2021 12:00, Jason A. Donenfeld wrote: > Hi Peter, Heiko, Christopher, and others, > > An update on: > >> I had a strange idea for how to fix this without requiring >> recompilation or removal of that code. >> >> 1) Enable DangerousScriptExecution: >> https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md#hklmsoftwarewireguarddangerousscriptexecution >> >> 2) Add a PostUp line to your [Interface] section: >> >> PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0 > I just wanted to let you know that this problem has been entirely > fixed (I think?) in the "WireGuardNT" kernel driver project I've been > working on (and haven't yet announced aside from development > screenshots on Twitter), and therefore the above steps will no longer > be necessary. When that ships as part of the v0.4 series of the normal > wireguard-windows client, you won't need the "listen-port 0" hack > anymore, as the kernel driver uses a more clever trick than the one > used by wireguard-go. So please do watch this mailing list in the next > few weeks for an announcement of that project, as I'll be very > interested in some real world tests and confirmation of the fix. > > Thanks, > Jason ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2021-07-30 7:28 ` Peter Whisker @ 2021-07-30 15:57 ` Jason A. Donenfeld 0 siblings, 0 replies; 27+ messages in thread From: Jason A. Donenfeld @ 2021-07-30 15:57 UTC (permalink / raw) To: Peter Whisker; +Cc: Heiko Kendziorra, Christopher Ng, WireGuard mailing list On Fri, Jul 30, 2021 at 9:25 AM Peter Whisker <peter.whisker@gmail.com> wrote: > Does this mean that the driver speed will improve as it will move out of > user space into the Windows Kernel in a similar way to Linux? Please save further inquiries about topics unrelated to pulsesecure until future announcements are made, in an applicable thread. ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2021-07-29 11:00 ` Jason A. Donenfeld 2021-07-30 7:28 ` Peter Whisker @ 2021-08-03 8:57 ` Peter Whisker 2021-08-03 10:57 ` Jason A. Donenfeld 1 sibling, 1 reply; 27+ messages in thread From: Peter Whisker @ 2021-08-03 8:57 UTC (permalink / raw) To: Jason A. Donenfeld, Heiko Kendziorra, Christopher Ng Cc: WireGuard mailing list Hi Jason and team Thank you all for this amazing effort! I upgraded to v0.4 this morning and thought I should give it a go. I set DWORD "ExperimentalKernelDriver = 1" in the registry. My simple "normal" tunnel which goes directly and not via PulseSecure works fine. :) I removed the "PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0" from my configs which go via the PulseSecure tunnel however traffic does not flow, the received byte counter remains at zero although the tunnel allegedly becomes "Activated" - see the log below. Regards Peter 2021-08-03 09:52:13.130462: [TUN] [mini-deb2] Starting WireGuard/0.4 (Windows 10.0.19042; amd64) 2021-08-03 09:52:13.130462: [TUN] [mini-deb2] Watching network interfaces 2021-08-03 09:52:13.134477: [TUN] [mini-deb2] Resolving DNS names 2021-08-03 09:52:13.144960: [TUN] [mini-deb2] Creating network adapter 2021-08-03 09:52:13.150857: [TUN] [mini-deb2] WireGuardCreateAdapter: Creating adapter 2021-08-03 09:52:13.357365: [TUN] [mini-deb2] SelectDriver: Using existing driver 0.1 2021-08-03 09:52:13.986764: [TUN] [mini-deb2] Using WireGuardNT/0.1 2021-08-03 09:52:13.990466: [TUN] [mini-deb2] Enabling firewall rules 2021-08-03 09:52:13.990984: [TUN] [mini-deb2] Interface created 2021-08-03 09:52:13.994159: [TUN] [mini-deb2] Dropping privileges 2021-08-03 09:52:13.995190: [TUN] [mini-deb2] Peer 1 created 2021-08-03 09:52:13.997778: [TUN] [mini-deb2] Monitoring MTU of default v4 routes 2021-08-03 09:52:13.998285: [TUN] [mini-deb2] Sending keepalive packet to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:13.998285: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:13.998285: [TUN] [mini-deb2] Interface up 2021-08-03 09:52:14.009369: [TUN] [mini-deb2] Setting device v4 addresses 2021-08-03 09:52:14.012575: [TUN] [mini-deb2] Monitoring MTU of default v6 routes 2021-08-03 09:52:14.012575: [TUN] [mini-deb2] Setting device v6 addresses 2021-08-03 09:52:14.017056: [TUN] [mini-deb2] Startup complete 2021-08-03 09:52:19.001078: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:24.162600: [TUN] [mini-deb2] Handshake for peer 1 (158.234.90.60:51820) did not complete after 5 seconds, retrying (try 2) 2021-08-03 09:52:24.162600: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:29.276205: [TUN] [mini-deb2] Handshake for peer 1 (158.234.90.60:51820) did not complete after 5 seconds, retrying (try 2) 2021-08-03 09:52:29.276205: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:34.380120: [TUN] [mini-deb2] Handshake for peer 1 (158.234.90.60:51820) did not complete after 5 seconds, retrying (try 3) 2021-08-03 09:52:34.380120: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:39.412842: [TUN] [mini-deb2] Handshake for peer 1 (158.234.90.60:51820) did not complete after 5 seconds, retrying (try 4) 2021-08-03 09:52:39.412842: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:44.441204: [TUN] [mini-deb2] Handshake for peer 1 (158.234.90.60:51820) did not complete after 5 seconds, retrying (try 5) 2021-08-03 09:52:44.443407: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) 2021-08-03 09:52:49.471250: [TUN] [mini-deb2] Handshake for peer 1 (158.234.90.60:51820) did not complete after 5 seconds, retrying (try 6) 2021-08-03 09:52:49.471250: [TUN] [mini-deb2] Sending handshake initiation to peer 1 (158.234.90.60:51820) On 29/07/2021 12:00, Jason A. Donenfeld wrote: > Hi Peter, Heiko, Christopher, and others, > > An update on: > >> I had a strange idea for how to fix this without requiring >> recompilation or removal of that code. >> >> 1) Enable DangerousScriptExecution: >> https://git.zx2c4.com/wireguard-windows/about/docs/adminregistry.md#hklmsoftwarewireguarddangerousscriptexecution >> >> 2) Add a PostUp line to your [Interface] section: >> >> PostUp = wg set %WIREGUARD_TUNNEL_NAME% listen-port 0 > I just wanted to let you know that this problem has been entirely > fixed (I think?) in the "WireGuardNT" kernel driver project I've been > working on (and haven't yet announced aside from development > screenshots on Twitter), and therefore the above steps will no longer > be necessary. When that ships as part of the v0.4 series of the normal > wireguard-windows client, you won't need the "listen-port 0" hack > anymore, as the kernel driver uses a more clever trick than the one > used by wireguard-go. So please do watch this mailing list in the next > few weeks for an announcement of that project, as I'll be very > interested in some real world tests and confirmation of the fix. > > Thanks, > Jason ^ permalink raw reply [flat|nested] 27+ messages in thread
* Re: Problems with Windows client over PulseSecure VPN 2021-08-03 8:57 ` Peter Whisker @ 2021-08-03 10:57 ` Jason A. Donenfeld 0 siblings, 0 replies; 27+ messages in thread From: Jason A. Donenfeld @ 2021-08-03 10:57 UTC (permalink / raw) To: Peter Whisker; +Cc: Heiko Kendziorra, Christopher Ng, WireGuard mailing list Hi Peter, Thanks for the report. This is due to an embarrassing mistake on my part, fixed here: https://git.zx2c4.com/wireguard-nt/commit/?id=9da6a84089d01ddee0018198eea0ab271916d934 . But hey, that's what experimental registry flags are for, right? ;-) I'll email you offlist with a testing build and some instructions in case you're eager to see this work before the next release. Jason ^ permalink raw reply [flat|nested] 27+ messages in thread
end of thread, other threads:[~2021-08-03 11:00 UTC | newest] Thread overview: 27+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-08-27 13:35 Problems with Windows client Peter Whisker 2020-08-27 19:20 ` Jason A. Donenfeld 2020-09-01 8:30 ` Peter Whisker 2020-09-03 13:35 ` Simon Rozman 2020-09-21 10:39 ` Peter Whisker 2020-11-24 10:17 ` Peter Whisker 2020-11-26 13:04 ` Problems with Windows client over PulseSecure VPN Peter Whisker 2020-11-26 13:11 ` Jason A. Donenfeld [not found] ` <2dc629e2-93c9-4ed9-ea57-4318c8b62a73@gmail.com> 2021-01-13 15:13 ` Peter Whisker [not found] ` <CAN5wt5r9rQpYcCkshBimOARoAxx7T529oUw6RSNnr4q3_y_31g@mail.gmail.com> 2021-01-15 10:32 ` Fwd: " Christopher Ng 2021-01-19 8:53 ` Peter Whisker 2021-01-30 10:51 ` Christopher Ng 2021-01-19 10:39 ` Peter Whisker 2021-03-02 21:32 ` Steffen Sledz 2021-03-03 10:54 ` Jason A. Donenfeld 2021-03-03 12:01 ` Heiko Kendziorra 2021-03-04 9:11 ` Peter Whisker 2021-03-04 13:07 ` Jason A. Donenfeld 2021-03-23 11:01 ` Christopher Ng 2021-04-14 9:40 ` Christopher Ng 2021-04-14 20:19 ` Jason A. Donenfeld 2021-04-14 21:17 ` Christopher Ng 2021-07-29 11:00 ` Jason A. Donenfeld 2021-07-30 7:28 ` Peter Whisker 2021-07-30 15:57 ` Jason A. Donenfeld 2021-08-03 8:57 ` Peter Whisker 2021-08-03 10:57 ` Jason A. Donenfeld
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).