Hi Binarus, it is better to post on Wireshark GitLab BugTracker but in your case, i think it is a capture issue coming from npcap and it will be better to post on npcap github issue (What the release of npcap ?)
Cheers On Mon, Oct 5, 2020 at 3:06 PM Binarus <li...@binarus.de> wrote: > Dear Wireshark developers, > > at first, I'd like to thank you for your great work! Wireshark helped me > analyze and solve problems a zillion of times, and it has never crashed > or was unreliable. > > However, I believe that I now have found a bug. If you need more > information than I provide below, I'll happily assist. And please bear > in mind that I am not an expert in this field, so I may have missed > something. > > To clarify and to save time, please note the following: > > - This is NOT about Wireshark not capturing correctly > - This is NOT about Wireshark crashing or being unstable > > This IS solely about Wireshark blocking traffic through a VPN > connection. Having said this: > > O/S > --- > Windows 10 Enterprise X64 v1909, patched up-to-date > > Wireshark version > ----------------- > 3.2.7 (v3.2.7-0-gfb6522d84a3a) > > Compiled (64-bit) with Qt 5.12.9, with WinPcap SDK (WpdPack) 4.1.2, with > GLib 2.52.3, with zlib 1.2.11, with SMI 0.4.8, with c-ares 1.15.0, with > Lua 5.2.4, with GnuTLS 3.6.3 and PKCS #11 support, with Gcrypt 1.8.3, > with MIT Kerberos, with MaxMind DB resolver, with nghttp2 1.39.2, with > brotli, with LZ4, with Zstandard, with Snappy, with libxml2 2.9.9, with > QtMultimedia, with automatic updates using WinSparkle 0.5.7, with > AirPcap, with SpeexDSP (using bundled resampler), with SBC, with > SpanDSP, with bcg729. > > Running on 64-bit Windows 10 (1909), build 18363, with Intel(R) Xeon(R) > CPU E3-1230 v5 @ 3.40GHz (with SSE4.2), with 16277 MB of physical > memory, with locale German_Germany.1252, with light display mode, > without HiDPI, with Npcap version 0.9997, based on libpcap version > 1.9.1, with GnuTLS 3.6.3, with Gcrypt 1.8.3, with brotli 1.0.2, without > AirPcap, binary plugins supported (19 loaded). > > Built using Microsoft Visual Studio 2019 (VC++ 14.27, build 29111). > > I have recently downloaded that version (I did not compile myself). > > Problem > ------- > When I start Wireshark and start capturing at all interfaces (regardless > whether or not there is a capturing filter active and regardless of what > that filter actually is), the traffic through VPN connections is > blocked. As soon as I stop capturing in Wireshark, the VPN tunnel works > again (I don't need to close Wireshark, I just need to stop capturing > for that). > > Exact steps to reproduce > ------------------------ > > 1) The Windows client shall use a LAN connection with IP 192.168.20.100, > and its subnet shall be 192.168.20/24, and shall be connected to the > internet by a common SOHO router with NAT. > > 2) Using the Windows UI, create a VPN connection with name "Test", using > the native Windows IPSec client, using IKEv2, using machine > certificates, MOBIKE disabled, encryption level "Require", credential > storing disabled. > > 3) Fine-tune that VPN connection using the following Powershell commands > as Administrator: > > Set-VpnConnection -Name Test -AllUserConnection -ServerName > remote.vpn.gateway -TunnelType Ikev2 -AuthenticationMethod > MachineCertificate -EncryptionLevel Required -SplitTunneling $true > > Set-VpnConnectionIPsecConfiguration -ConnectionName Test > -AuthenticationTransformConstants GCMAES256 -CipherTransformConstants > GCMAES256 -EncryptionMethod GCMAES256 -IntegrityCheckMethod SHA384 > -PfsGroup PFS2048 -DHGroup Group14 -AllUserConnection > > 4) Install an appropriate machine certificate and the CA certificate > (which has signed the remote gateway's certificate) in Windows. > > 5) Configure the remote gateway so that it accepts the connection when > the Windows client establishes the VPN created in the previous steps. > Furthermore, make sure that the following conditions are met: > > - The remote gateway (besides its public IP address) has the IP address > 192.168.0.250, and it is in the local subnet 192.168.0.0/24. > > - Furthermore, it uses IKE-CFG to assign an IP address to the Windows > client when the latter establishes a VPN connection. The IP address it > assigns shall be 192.168.3.1 > > - The remote gateway routes traffic between 192.168.3.1 and 192.68.0.0, > and the remote gateway's firewall (if any) lets this traffic pass. > > 6) In Windows, establish the VPN connection, and verify that (after > connecting successfully) there is a new network interface with IP > 192.168.3.1 (if it isn't, the VPN is not set up correctly, and this must > be sorted out before proceeding), e.g. by typing ipconfig /all in a > command prompt. > > 7) To tell Windows how it can reach the subnet behind the remote VPN > gateway, add the appropriate route by giving the following command in a > command prompt with administrative permissions: > > route add 192.168.0.0 mask 255.255.255.0 192.168.3.1 > > Check whether Windows now can reach the remote subnet, e.g. via ping: > > ping 192.168.0.10 > > (provided that 192.168.0.10 is reachable in the remote subnet and does > not block ICMP from other subnets, this should work; if it doesn't, the > VPN is not set up correctly, and this must be sorted out before > proceeding). > > 8) On the Windows client, start Wireshark and let it capture on all > interfaces. Repeat the ping command from above and note that it does not > work any more (it produces timeouts, no reply comes back). > > 9) Do not close Wireshark, but stop capturing. Repeat the ping command > from above and note that it works again (no more timeouts, reply comes > back as expected). > > To confirm that the problem can be reproduced, start and stop capturing > in Wireshark as often as you like, and each time check whether the ping > command from above works. Confirm that it does not work while Wireshark > is capturing, and that it does work while Wireshark is not capturing. > > > I know that my setup may be somewhat exotic (normally, you let a VPN > gateway assign IP addresses to the client which are from its internal > subnet so that you don't need to add a route on the client). However, I > believe that this should work and that Wireshark blocking traffic > through the VPN channel is a bug. > > Could you please let me know what you think about that and whether I can > assist in solving the problem? > > Thank you very much, and best regards, > > Binarus > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
