Forum Replies Created
-
Posts
-
It appears the system entered sleep mode at 18:03:02 and resumed at 18:14:24, right? However, the error remains unclear—it looks like the handshake packet failed to send over the UDP socket. I can build a version with extended logging to gather more details. At the very least, knowing the specific error code would be helpful. Is the Internet connection functioning correctly after the resume?
The approach largely depends on the context. In general, if you need to work with a process context in the kernel driver, using WFP call-outs makes sense as they provide a more direct way to filter traffic based on process information at the kernel level. However, for user-mode operations, the overhead introduced by GetExtendedTcpTable() is similar to what you would encounter if you implemented the same functionality via a kernel driver.
So, if you’re aiming for a user-mode solution without the complexity of working in kernel mode, GetExtendedTcpTable() is a reasonable choice. But if you’re okay with working in the kernel and need tighter control, WFP call-outs would offer more flexibility and direct access to connection events like Connect and others.
Typically, the WireSock VPN client automatically attempts to reconnect if the VPN connection is lost, as in your situation. Could you provide more details, such as the client version and whether you’re running it as a service or an application? Additionally, any logs you can share would be helpful in diagnosing the issue.
I briefly reviewed the AmneziaWG repositories and noticed that there’s no existing library to handle packet obfuscation/deobfuscation, and I’d prefer not to extract the client code to create one myself. It would be much more convenient if the AmneziaWG authors developed such a library. I’ve submitted an issue about this. If you’re interested in this feature, please consider supporting it:
https://github.com/amnezia-vpn/amneziawg-windows-client/issues/15
Да, есть такая проблема, и без антиспама никак и с ним неудобно. Давайте попробуем один из этих каналов:
https://t.me/wiresock
https://www.reddit.com/r/WireSock/s/zHPkfxYEspCurrently, localhost connections are not supported because they were not prioritized as essential functionality. While the initial handshake packet is sent over Windows sockets, the subsequent packets are injected directly into the NDIS layer, causing them to be misdirected in case of localhost server. I plan to address this and add localhost support in future releases.
I believe that, eventually, it will no longer be possible to sign drivers for Windows 7/8, much like it’s currently impossible for Windows Vista. Depending on your code signing certificate, you may need a cross-certificate to correctly sign drivers for Windows 7/8. In my experience, I’ve encountered the fewest issues with certificates from GlobalSign. However, I agree that driver signing can be tricky.
You’re correct, I did not pass the Windows 7/8 driver through HCK testing, and as you may have noticed, it doesn’t have a Microsoft signature.
In a future release, I plan to handle DisallowedApps at the kernel level. This should improve performance, and while I’m not entirely certain, it might help resolve cases like this one.
Hmm, this might be due to tunnel instability. In virtual adapter mode, activating or deactivating the tunnel changes the routing table, which can lead to disconnects. This issue doesn’t occur in transparent mode (without the -lac option) because it intercepts and processes selected packets directly from your default connection.
