Forum Replies Created
-
Posts
-
Hi Dat,
No, the driver won’t do packet fragmentation for you. If, after attaching extra headers, your packet size exceeds MTU (typically Internet MTU never exceeds 1514 bytes, in LAN jumbo frames can reach 9014 bytes size), then you have to fragment it into two INTERMEDIATE_BUFFER structures and inject two packets instead of one. However, I would recommend avoiding fragmentation (fragmented packets are often silently dropped by firewalls/routers) at all. For example, for TCP protocol, you could manipulate the TCP MSS option to limit the maximum packet size and thus reserve space for your extra headers.
Hope it helps.
VadimHi Hardoman,
This is the known disadvantage of proxy mode, which is limited to TCP and UDP protocols only. I will consider adding some sort of ICMP proxy in the future, but meanwhile if you need ICMP then you can switch gateway to the NAT mode.
Hope it helps,
VadimДобавил, можете протестировать:
https://www.ntkernel.com/downloads/Windows Packet Filter 3.2.32.1 x64.msi
https://www.ntkernel.com/downloads/Windows Packet Filter 3.2.32.1 x86.msiОпределения для NDISAPI в ветке develop на github.
You should consider one thing about GetExtendedTcpTable / GetExtendedUdpTable. These functions return you only connections available to the application (more precisely, to the user running the application). It is not a problem if you run as a service under LocalSystem account, but if you execute it under standard user account, you won’t see processes from other users (and services).
Thank you for testing and feedback. I will devote some time to review the changes and create the final build. Maybe I will also add one SOCKS5 authorization method for the consistency. As soon as it is ready, I would appreciate if you give it a try in your environment. If you find out any issues with the current version, then please let me know. Please don’t hesitate to e-mail me directly at vadim(at)ntkernel.com.
Logs are not representative, capture file for the tunnel is empty. Besides this, you could intersect with my tests stopping SOCKS proxy to simulate SOCKS server failure. Below is a slightly updated build, please give it a try. Also, please note that while you are not sending anything over the tunnel boringtun seems to sleep (I can’t see it generating any traffic), but when you start the tunneled application it immediately initiates the handshake and starts tunneling. So, after a pause, try to run something which is supposed to be tunneled.
I’ve looked through the capture logs. The problem is not in keepalive packet. After some timeout, connection to SOCKS proxy is broken (probably ISP NAT removes by timeout) and handshakes can’t reach the destination.
The build below attempts to refresh SOCKS proxy connection after fist non-responded handshake.
Yes, Keepalive packets were sent through the SOCKS proxy, and it caused some problems. Please test the build below:
https://1drv.ms/u/s!AqMWR3uDO7eagdployq7zTR7TJOIdA?e=tUgS7D
Normally, Handshakes are sent every two minutes, while Keepalive packets are sent if no other packets were sent after PersistentKeepalive interval.
Regretfully, #11993 has the same problem with the first handshake. Please test the one below, I hope I have fixed all places where it could come from:
Here is the build which sends only handshake over SOCKS5 but does not allow handshake to go out until SOCKS session is not ready.
However, may be the problem in the first handshake which I have passed over before the SOCKS connection was ready:
It could result in DPI logging the WireGuard connection attempt and subsequent blocking of incoming packets. I will make another build to fix this.
Please try this build
https://1drv.ms/u/s!AqMWR3uDO7eagdphxyLoAnh77tB0UQ?e=H3q4Xf
Please note to reduce WireGuard MTU by 10 bytes. It can be a little noisy on
-log-level allproducing numerous messages from SOCKS:2021-12-21 21:58:39 [SOCKS5]: C2S_BEFORE: 192.168.1.26 : 58615 -> 152.70.176.114 : 59075 2021-12-21 21:58:39 [SOCKS5]: C2S_AFTER: 192.168.1.26 : 58615 -> 132.226.194.27 : 43603 2021-12-21 21:58:39 [SOCKS5]: C2S_BEFORE: 192.168.1.26 : 58615 -> 152.70.176.114 : 59075 2021-12-21 21:58:39 [SOCKS5]: C2S_AFTER: 192.168.1.26 : 58615 -> 132.226.194.27 : 43603 2021-12-21 21:58:39 [SOCKS5]: C2S_BEFORE: 192.168.1.26 : 58615 -> 152.70.176.114 : 59075 2021-12-21 21:58:39 [SOCKS5]: C2S_AFTER: 192.168.1.26 : 58615 -> 132.226.194.27 : 43603 2021-12-21 21:58:39 [SOCKS5]: C2S_BEFORE: 192.168.1.26 : 58615 -> 152.70.176.114 : 59075 2021-12-21 21:58:39 [SOCKS5]: C2S_AFTER: 192.168.1.26 : 58615 -> 132.226.194.27 : 43603 2021-12-21 21:58:39 [SOCKS5]: C2S_BEFORE: 192.168.1.26 : 58615 -> 152.70.176.114 : 59075 2021-12-21 21:58:39 [SOCKS5]: C2S_AFTER: 192.168.1.26 : 58615 -> 132.226.194.27 : 43603 2021-12-21 21:58:39 [SOCKS5]: S2C_BEFORE: 132.226.194.27 : 43603 -> 192.168.1.26 : 58615 2021-12-21 21:58:39 [SOCKS5]: S2C_AFTER: 152.70.176.114 : 59075 -> 192.168.1.26 : 58615Yes, there is a problem, but it is not about the DNS…
Handshake works fine over the UDP proxy and packets are sent out over the tunnel. However, only very few packets come back from WireGuard server. I can see only the following incoming packets:
counter(258):session(1902), counter(199-204):session(1904), counter(250):session(1905). According to the counters, WireGuard server is sending packets to you, but most of them are dropped on the way. I wonder why refreshing the network connection resolves the issue, but it looks that not only handshake can be blocked…We could try to pass all WireGuard traffic over the UDP proxy to see if it improves the behavior.
Could you collect PCAP files with disabled adguard and non-working DNS? I will check what can be wrong with DNS queries.
