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