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
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.
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
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
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
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
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
Is PulseSecure not setting up a /0 route? If so, then this is a known issue with the lack of policy routing on Windows.
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.
---------- 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.
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.
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.
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.
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
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
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
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
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/
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
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
Sounds like you probably have an older version of wg.exe somewhere with higher precedence in your PATH. Perhaps C:\windows\system32?
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?
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
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
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.
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
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