Vadim Smirnov

Forum Replies Created

Viewing 15 posts - 406 through 420 (of 1,496 total)
  • Author
    Posts
  • Vadim Smirnov
    Keymaster

      Thanks for pointing this out, I have fixed it in 1.0.32.

      in reply to: “WIresock Client” and “Socksify Sample” #12096
      Vadim Smirnov
      Keymaster

        Socksify is just sample demo code to illustrate the approach. It is not supposed to be an end-user application. Also, please note that it does not support UDP, it is TCP only. However, it can be extended to socksify UDP.

        in reply to: “WIresock Client” and “Socksify Sample” #12092
        Vadim Smirnov
        Keymaster

          I’m sorry, this is my fault. I was so keen about the new SOCKS5 feature that had not tested the latest build without it. The handshake without SOCKS5 was broken in v.1.0.47 and v.1.0.48.

          Please download v1.0.49 and give it a try.

          in reply to: “WIresock Client” and “Socksify Sample” #12089
          Vadim Smirnov
          Keymaster

            From what I can see, your WireGuard server at google.com:2408 does not respond. Handshake Initiate packets are sent out, but a Handshake Response is never received.

            BTW, does Google provide WireGuard service?

            in reply to: “WIresock Client” and “Socksify Sample” #12087
            Vadim Smirnov
            Keymaster

              Thanks for your reply, I dont understand that you said dont specify, i try to delete “AllowedApps” line and restart wiresock service and there is no connection over VPN, i also try leave blank AllowedApps = “blank” , it doesnt work too.

              Since I’m usually running WireSock VPN Client for the Chrome browser app, it was straightforward to test. I have commented out AllowedApps and restarted service. Now, Firefox/Edge also show the VPN address on https://www.whatismyip.com/. Here is the resulted configuration file (key and passwords are stripped out):

              [Interface]
              PrivateKey = PRIVATE_KEY=
              Address = 10.66.66.2/32, fd42:42:42::2/128
              DNS = 94.140.14.14, 94.140.15.15
              MTU = 1420
              
              [Peer]
              PublicKey = PUBLIC_KEY=
              AllowedIPs = 0.0.0.0/0, ::/0
              Endpoint = oracle.sshvpn.me:50812
              #AllowedApps = chrome
              DisallowedIPs = 192.168.1.0/24
              Socks5Proxy = oracle3.sshvpn.me:1080
              Socks5ProxyUsername = SOCKS5_USER
              Socks5ProxyPassword = SOCKS5_PASSWORD

              Can you share your config file? Also, if you experience any problems, then try running Wiresock VPN Client as a console application with -log-level all and share the output.

              About Socksify sample, can you support it tunnell all apps, not only selected apps ?

              This is relatively easy to do, just remove the application name check, and it will tunnel every new TCP connection via the SOCKS5.

               

              in reply to: “WIresock Client” and “Socksify Sample” #12085
              Vadim Smirnov
              Keymaster

                I don’t think I understand your question. If you want Wiresock VPN Client to tunnel all the applications over WireGuard tunnel, then just don’t specify AllowedApps parameter in the configuration file.

                Socksify sample serves a different task, it forwards the selected application via the SOCKS5 proxy server. I will consider making the background service based on the Socksify sample code.

                 

                Vadim Smirnov
                Keymaster

                  I have finally released v.1.0.48 of WireSock VPN Client with SOCKS5 support for WireGuard handshakes. This build supports username/password authentication. If you have a chance to test it, then please update me on how it works in your environment.

                  Here is the short guide on setting up free SOCKS5 server with UDP ASSOCIATE support in Oracle Cloud: https://www.ntkernel.com/wireguard-and-socks5/

                   

                  in reply to: Wireguard and OpenVPN Nested Tunnel #12059
                  Vadim Smirnov
                  Keymaster

                    I’ve just set a nested WireGuard tunnels setup to test and provide you with some examples. Regretfully, there is one problem, the last version of WireGuard for Windows I have tested nested wireguard/wiresock tunnels was v0.5, and it looks one of the more recent updates has broken this setup (internal handshake packet sent by wiresock can’t reach the destination).

                    However, recently, I have added a new feature to Wiresock which allows sending a handshake packet through the SOCKS5 server. Please see the related post on bypassing Egypt’s WireGuard ban here. And surprisingly, this allows to resolve the issue, handshake packet is not recognized by stock Wireguard and reaches its destination.

                    The Wireguard for Windows configuration (external tunnel):

                    [Interface]
                    PrivateKey = PRIVATE_KEY_HERE
                    Address = 10.10.11.3/24
                    DNS = 8.8.8.8, 1.1.1.1
                    MTU = 1412
                    
                    [Peer]
                    PublicKey = PUBLIC_KEY_HERE
                    AllowedIPs = 0.0.0.0/0
                    Endpoint = WIREGUARD_EXTERNAL_SERVER_IP:50812
                    PersistentKeepalive = 25

                    Wiresock VPN Client configuration(internal tunnel for Chrome browser only):

                    [Interface]
                    PrivateKey = PRIVATE_KEY_HERE
                    Address = 10.66.66.2/32, fd42:42:42::2/128
                    DNS = 8.8.8.8, 1.1.1.1
                    MTU = 1332
                    
                    [Peer]
                    PublicKey = PUBLIC_KEY_HERE
                    AllowedIPs = 0.0.0.0/0, ::/0
                    Endpoint = WIREGUARD_INTERNAL_SERVER_IP:50812
                    AllowedApps = chrome
                    DisallowedIPs = 192.168.1.0/24
                    Socks5Proxy = SOCKS5_PROXY_ADDRESS:1080
                    Socks5ProxyUsername = SOCKS5_USERNAME
                    Socks5ProxyPassword = SOCKS5_PASSWORD

                    SOCKS5 handshake feature is not released yet, but if you’re interested in testing it, then you can download binaries here. Just copy these over the installed ones in C:\Program Files\WireSock VPN Client\bin.

                    in reply to: Wireguard and OpenVPN Nested Tunnel #12057
                    Vadim Smirnov
                    Keymaster

                      I had not tested nested tunnels with Open VPN Client, but I have tested the official Wireguard VPN Client along with Wiresock VPN Client to organize nested VPN tunnels:

                      WireSock VPN Client is compatible and can be used with official WireGuard for Windows to organize nested WireGuard tunnels completely on the client side. In such configuration, the official client organizes the external tunnel (to the first WireGuard Server instance) and WireSock VPN Client the internal one (to the second WireGuard Server instance). You only need to remember to adjust MTU parameter for the internal tunnel accordingly to avoid fragmentation and throughput degradation.

                      However, I can’t see why it could not work a similar way with Open VPN Client… But please note to use the Wiresock VPN Client instead of the official Wireguard for Windows.

                      in reply to: Windows Packet Filter 3.2.32 fail to install on windows 7 #12032
                      Vadim Smirnov
                      Keymaster

                        I don’t have Windows 7 Enterprise X64 under hand, but I’ve tested 3.2.32 on Windows 7 x64 retail with all latest updates, and it works ok.

                        However, there is one key difference in driver signing between 3.2.7 and 3.2.32:

                        3.2.7 drivers for Windows 7 are signed using SHA-1 Code Signing certificate, while 3.2.32 with SHA-256 EV Code Signing certificate.

                        Please note, that SHA-1 code signing certificates are no more available for ordering and the latest Windows Packet Filter version signed with SHA-1 Code Signing certificate was 3.2.29. You can get this version using the links below:

                        Windows Packet Filter 3.2.29.1 x64.msi

                        Windows Packet Filter 3.2.29.1 x86.msi

                        Alternatively, you could install the required update from the list below to add SHA-256 support to your OS:

                        Vadim Smirnov
                        Keymaster

                          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.
                          Vadim

                          in reply to: Ping not passing through #12026
                          Vadim Smirnov
                          Keymaster

                            Hi 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

                            in reply to: _TRANSPORT_LAYER_FILTER #12015
                            Vadim Smirnov
                            Keymaster

                              Добавил, можете протестировать:

                              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.

                              in reply to: WinPacketFilter – determine packet owner app #12012
                              Vadim Smirnov
                              Keymaster

                                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).

                                Vadim Smirnov
                                Keymaster

                                  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.

                                Viewing 15 posts - 406 through 420 (of 1,496 total)