Problems with Windows client

Problems with Windows client

[Peter Whisker]

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

Re: Problems with Windows client

[Jason A. Donenfeld]

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.

Re: Problems with Windows client

[Peter Whisker]

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

RE: Problems with Windows client

[Simon Rozman]

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

Re: Problems with Windows client

[Peter Whisker]

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

Re: Problems with Windows client

[Peter Whisker]

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

Problems with Windows client over PulseSecure VPN

[Peter Whisker]

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

Re: Problems with Windows client over PulseSecure VPN

[Jason A. Donenfeld]

Is PulseSecure not setting up a /0 route? If so, then this is a known
issue with the lack of policy routing on Windows.

Re: Problems with Windows client over PulseSecure VPN

[Peter Whisker]

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.

Fwd: Problems with Windows client over PulseSecure VPN

[Christopher Ng]

---------- 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.

Re: Fwd: Problems with Windows client over PulseSecure VPN

[Peter Whisker]

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.

Re: Fwd: Problems with Windows client over PulseSecure VPN

[Peter Whisker]

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.

Re: Fwd: Problems with Windows client over PulseSecure VPN

[Christopher Ng]

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.

Re: Fwd: Problems with Windows client over PulseSecure VPN

[Steffen Sledz]

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

Re: Problems with Windows client over PulseSecure VPN

[Jason A. Donenfeld]

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

Re: Problems with Windows client over PulseSecure VPN

[Heiko Kendziorra]

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

Re: Problems with Windows client over PulseSecure VPN

[Peter Whisker]

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

Re: Problems with Windows client over PulseSecure VPN

[Jason A. Donenfeld]

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/

Re: Problems with Windows client over PulseSecure VPN

[Christopher Ng]

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

Re: Problems with Windows client over PulseSecure VPN

[Christopher Ng]

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

Re: Problems with Windows client over PulseSecure VPN

[Jason A. Donenfeld]

Sounds like you probably have an older version of wg.exe somewhere
with higher precedence in your PATH. Perhaps C:\windows\system32?

Re: Problems with Windows client over PulseSecure VPN

[Christopher Ng]

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?

Re: Problems with Windows client over PulseSecure VPN

[Jason A. Donenfeld]

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

Re: Problems with Windows client over PulseSecure VPN

[Peter Whisker]

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

Re: Problems with Windows client over PulseSecure VPN

[Jason A. Donenfeld]

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.

Re: Problems with Windows client over PulseSecure VPN

[Peter Whisker]

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

Re: Problems with Windows client over PulseSecure VPN

[Jason A. Donenfeld]

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