Hi! I tested again with latest Wireguard (.35) and Windows 2019 (.914) and the problem remains easy to reproduce.
In short, after restarting a Windows that is doing NAT for a peer behind a Wireguard tunnel, the tunnel stops correctly moving packets. I can see the Wiregurad "sent" and "received" counts increment to some degree but the end result is that pings do not work after some restarts of the tunnel/server). I remain ready to assist in further diagnosis if a more informed person can guide me to what data might be useful. Cheers, Sander Saares, Advisor, Axinom phone: +49 911 80109-54 | [email protected] -----Original Message----- From: Sander Saares Sent: esmaspäev, 5. august 2019 10:55 To: '[email protected]' <[email protected]> Subject: Windows tunnel shows established but traffic sometimes does not move after recycling tunnel Hi! I submit a report on a problem encountered attempting to use WireGuard in a Windows-to-Windows "VPN gateway/proxy" deployment. I have a test deployment available in case I can provide further data for ease of debugging. Scenario: * Server A set up as WireGuard server, accepting connections from server B. * Traffic from WireGuard network is forwarded and NATed by server A using built-in Windows networking features. * Server B connects through WireGuard tunnel to access the internet. For purpose of experimentation, the internet is defined as 8.8.8.8/32. Expected result: tunnel is successfully established, internet traffic of server B is forwarded through server A. Actual result: tunnel is successfully established (at least as shown in WireGuard GUI) but sometimes the expected traffic flows do not occur. Occasionally, actual result matches expected result. Method of observation: mutual ping on private IP address; ping from server B (WG client) to 8.8.8.8. In failure case: * both pings time out (server A and server B cannot ping each other on private IP) * ping to 8.8.8.8 times out, EXCEPT for the first ping after tunnel is re-established (server B always seems to get 1 response before connectivity vanishes; possibly this is a ping not routed through the VPN, so it just goes directly out from server B to the internet?) In success case, all pings work fine and get expected responses. I suspect some startup/lifecycle/timing issue disrupting proper operation of the tunnel and/or associated routing configuration. If I can provide more data that may prove useful, I am happy to do so when instructed on how to collect it. Configuration and experiment log follows. Both systems are Windows 2019 (17763.652) running in clean Azure VMs, fully patched. WireGuard 0.0.19. WireGuard server (server A) ======================= [Interface] PrivateKey = ListenPort = 9000 Address = 172.16.16.1/24 [Peer] PublicKey = AllowedIPs = 172.16.16.0/24 WireGuard client (server B) ======================= [Interface] PrivateKey = Address = 172.16.16.2/24 [Peer] PublicKey = AllowedIPs = 172.16.16.0/24, 8.8.8.8/32 Endpoint = xxx:9000 Forward+NAT setup (server A) ================= PS C:\Users\saares> $interfaces = Get-NetIPInterface PS C:\Users\saares> $interfaces[4] ifIndex InterfaceAlias AddressFamily NlMtu(Bytes) InterfaceMetric Dhcp ConnectionState PolicyStore ------- -------------- ------------- ------------ --------------- ---- --------------- ----------- 3 wg-test IPv4 1420 5 Disabled Connected ActiveStore PS C:\Users\saares> $interfaces[4] | Set-NetIPInterface -Forwarding Enabled PS C:\Users\saares> New-NetNat -Name NAT -InternalIPInterfaceAddressPrefix "172.16.16.0/24" Name : NAT ExternalIPInterfaceAddressPrefix : InternalIPInterfaceAddressPrefix : 172.16.16.0/24 IcmpQueryTimeout : 30 TcpEstablishedConnectionTimeout : 1800 TcpTransientConnectionTimeout : 120 TcpFilteringBehavior : AddressDependentFiltering UdpFilteringBehavior : AddressDependentFiltering UdpIdleSessionTimeout : 120 UdpInboundRefresh : False Store : Local Active : True Experiment log =============== Immediate after setup -> all OK Recycle tunnel on server -> all OK Restart server PC -> tunnel reestablished but traffic does not move Recycle tunnel on server -> all OK Recycle tunnel on server -> all OK Recycle tunnel on server -> all OK Recycle tunnel on server -> all OK Recycle tunnel on server -> all OK Recycle tunnel on server -> all OK Restart server PC -> all OK Restart server PC -> tunnel reestablished but traffic does not move Recycle tunnel on server -> tunnel reestablished but traffic does not move Recycle tunnel on server -> tunnel reestablished but traffic does not move Recycle tunnel on server -> tunnel reestablished but traffic does not move Recycle tunnel on server -> tunnel reestablished but traffic does not move Recycle tunnel on server -> all OK Recycle tunnel on server -> tunnel reestablished but traffic does not move Recycle tunnel on server -> tunnel reestablished but traffic does not move Recycle tunnel on server -> tunnel reestablished but traffic does not move Cheers, Sander Saares Advisor Axinom | Soola 8 | 51004 Tartu | Estonia phone: +49 911 80109-54 [email protected] | www.axinom.com Managing Directors: Sergei Gussev, Oleg Knut Tartu Circuit Court, Reg. 11046287 _______________________________________________ WireGuard mailing list [email protected] https://lists.zx2c4.com/mailman/listinfo/wireguard
