* Problems with Windows client
@ 2020-08-27 13:35 Peter Whisker
2020-08-27 19:20 ` Jason A. Donenfeld
0 siblings, 1 reply; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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
` (2 more replies)
1 sibling, 3 replies; 22+ 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] 22+ 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
2 siblings, 0 replies; 22+ 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] 22+ 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
2 siblings, 1 reply; 22+ 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] 22+ 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; 22+ 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] 22+ 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
2 siblings, 1 reply; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ 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; 22+ 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] 22+ messages in thread
end of thread, other threads:[~2021-04-14 21:18 UTC | newest]
Thread overview: 22+ 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
Development discussion of WireGuard
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://inbox.vuxu.org/wireguard/0 wireguard/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 wireguard wireguard/ http://inbox.vuxu.org/wireguard \
wireguard@lists.zx2c4.com
public-inbox-index wireguard
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://inbox.vuxu.org/vuxu.archive.wireguard
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git