Re: [Wireshark-dev] Should "lts-" branches be Protected branches?
On 10/4/20 11:46 AM, chuck c wrote: > https://gitlab.com/wireshark/wireshark/-/branches/all?utf8=%E2%9C%93&search=lts > > History? - https://www.wireshark.org/lists/wireshark-dev/201404/msg00163.html > > What are Protected branches? - > https://docs.gitlab.com/ee/user/project/protected_branches.html They're now protected. ___ Sent via:Wireshark-dev mailing list 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
Re: [Wireshark-dev] Possible bug (Wireshark blocking VPN traffic)
On Mon, 5 Oct 2020 at 14:06, Binarus 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 does
[Wireshark-dev] Possible bug (Wireshark blocking VPN traffic)
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 p
Re: [Wireshark-dev] nas_eps value type change request
On Oct 4, 2020, at 11:51 PM, Anders Broman via Wireshark-dev wrote: > The proper way to request features or report bugs is through > https://bugs.wireshark.org/bugzilla/ Now, it's through https://gitlab.com/wireshark/wireshark/-/issues (see the "New Issue" button). Bugzilla is now read-only. ___ Sent via:Wireshark-dev mailing list 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
