Forum Replies Created
-
Posts
-
I have not tried to test compatibility with VirtualBox, in general, Ethernet Bridge is just a sample to demonstrate the capabilities of Windows Packet Filter. But it’s quite possible that VirtualBox is using a similar approach to connect to the host network and there is some conflict. This requires more in-depth research.
Путь к файлу конфигурации не нужно ставить в квадратные скобки. Скорее всего из-за этого клиент не может его найти.
Yes, but you will need to relay packets from the virtual NIC to the real one. For example, you can use the Windows Packet Filter for this purpose.
You may be right, at least for the case where wiresock-client is running as an application and neither the primary nor secondary configurations are good/available, it makes sense to exit. As for the service, it may constantly try to restart.
For those facing a similar issue, check the MTU configuration setting. As a rule, it should not exceed 1420 bytes (1440 bytes for IPv4 only tunnels), specifying a larger value, such as 1500, results in the behavior described above.
Thing is: I assume that if wireguard is running, it is connected (as it’s not really possible to query the actual connection state to my knowledge).
Desired behaviour: wiresock process exits if config file is bad/does not exist.
Even so,
running service != active tunnel. For example, the configuration file may be present and correct, but Wireguard server may be down or unreachable.I already have several requests to add a simple application with a tray icon to indicate the status of a WireSock tunnel. So, I need to add some IPC for communication between service and tray app. Probably the simplest would be to create a shared memory section to represent the current state of the service/tunnel, or a simple named pipe request-response mechanism.
More complex, but at the same time more modern and flexible, would be to add a simple web socket server using a third-party library such as websocketpp.
I will give it a think until the next weekend. Any suggestions are appreciated.
Hi,
Looks very similar to this discussion. At that time, the problem was solved by adding SOCKS5 for WireGuard handshake. You can check if it still works.
- %APPDATA% в пути использовать нет смысла, там идет поиск подстроки.
- Видимо имеется ввиду, не то что Хром ходит через VPN туннель, а DNS от Хрома. Дело в том, что DNS резолвинг идет от процесса dnscache, а не от самого Хрома и если в конфиге прописаны DNS, то весь DNS идет в тоннель. Есть мысль перенаправлять не весь DNS, а конкретно dnscache и только если не указан в DisallowedApps. Наверное так и сделаю.
Hello,
Unfortunately, only one active tunnel is currently supported. Adding more configs/tunnels is not that hard, and the idea is fascinating. I’ll add this feature request to the to-do list. Unfortunately, I don’t have much spare time lately, so I can’t say when I’ll be able to my hands on this.
As far as I can see, Firefox works great over VPN, while IE slows down. And I suspect that the problem may be related to DNS. Since you specified DNS in the Wireguard config file, all DNS requests (not only Firefox, but also IE) go to this server. Try removing DNS from the config and/or changing it to something like 8.8.8.8 to see if there is a difference.
One more question, did you run the wiresock client as administrator?
I think the problem you are having is related to the MTU setting in your config file. Try reducing the MTU (for example, from the default 1420 to 1412 or even 1280) and see if there is a difference.
Unlike the standard WireGuard client, WireSock does not support fragmented UDP frames and download performance may be degraded due to packet loss.
Hmm, I’m running Wiresock in a similar setup, although Chrome uses a Wireguard tunnel and Firefox connects directly, and I’ve never noticed much slowdown. Of course, depending on the distance to your Wireguard server (and associated network latency), when you’re browsing the tunnel, websites usually don’t respond as quickly as they would with a direct connection, but that’s expected behavior.
I would first try testing another Wireguard server, preferably one that you set up yourself and has enough CPU and network resources. Otherwise, other VPN clients may affect the performance of your tunnel in unpredictable ways, and a clean test will not be possible.
Do i have to add any tag in the setupcommand for using multiple cores of the processor?
The Wiresock client uses 4 worker threads (4 cores) to process packets, this design seems quite scalable.
