Vadim Smirnov

Forum Replies Created

Viewing 15 posts - 481 through 495 (of 1,486 total)
  • Author
    Posts
  • in reply to: Redirect packets thru another network adapter #11523
    Vadim Smirnov
    Keymaster

      Then there must be something wrong with your modified SYN packet. Enable checksum verification in Wireshark and check if packet checksums are good.

      in reply to: Redirect packets thru another network adapter #11520
      Vadim Smirnov
      Keymaster

        From what I can see there is no SYN-ACK packet from your HTTP server. So,

        • Does your HTTP server listen on port 153?
        • Check if HTTP server if firewall protected and disable Windows Defender firewall if the server is Windows.
        in reply to: Redirect packets thru another network adapter #11518
        Vadim Smirnov
        Keymaster

          First I would check if packet are delivered to the destination. You could setup the HTTP server in the LAN and try to connect to it while capturing traffic using tcpdump/wireshark (on the server). For the TCP connection you must see the incoming TSP SYN and if the SYN is OK then also the outgoing SYN_ACK.

          in reply to: Redirect packets thru another network adapter #11516
          Vadim Smirnov
          Keymaster

            The approach looks good in general. I hope you remember to recalculate IP/TCP checksum and adjust MAC addresses accordingly.

            in reply to: Redirect packets thru another network adapter #11514
            Vadim Smirnov
            Keymaster

              Yes, it is possible to do using Windows Packet Filter, however:

              1. this is not trivial, as you need to write the code to select and re-route network packets
              2. implementation may depend on VPN you are using, so I would recommend to start with something simple, e.g. routing ICMP PING or DNS
              in reply to: WindowsPacketFilter/Tools/ebridge not working #11512
              Vadim Smirnov
              Keymaster

                From what I can see ebridge can see both TB connections, so lets keep the ‘listadapters’ aside.

                As I can see both TB adapters on the central host have auto-configured IP addresses and pinging by name does not work. Could you assign all TB adapters some fixed IPv4 addresses and try to ping over the bridge? E.g.

                PC1-TB [10.0.0.1/24] <–> [10.0.0.2/24]TB1-PC2-TB2[10.0.0.3/24] <–> [10.0.0.4] TB-PC3

                Then try to ping 10.0.0.4 from 10.0.0.1 and vice versa while running the ebridge. If bridge works then you should be able to, if not then send me captures to look what is going wrong.

                in reply to: WindowsPacketFilter/Tools/ebridge not working #11510
                Vadim Smirnov
                Keymaster

                  Does ebridge displays your TB adapters at all or they are just ignored by software? If it does not then probably I do need to add TB medium support first. Could you please run ‘listadapters’ from the standard tools and share its output?

                  You can share Google driver to my gmail.com account ‘gmkernel’.

                  in reply to: WindowsPacketFilter/Tools/ebridge not working #11505
                  Vadim Smirnov
                  Keymaster

                    I don’t have the hardware to test with on my side, so let’s try to look at what is going on the network layer. Here is the Debug build of Ethernet Bridge which saves packets capture from all bridged adapters. Try to test it with Thunderbolt (e.g. send pings from the one host connected to the bridge to another one) and send me PCAP files and ‘ipconfig /all’ output.

                    in reply to: WindowsPacketFilter/Tools/ebridge not working #11503
                    Vadim Smirnov
                    Keymaster

                      I have tested Ethernet Bridge sample only over Ethernet and WiFi adapters and if you look through this paper then bridging WiFi was a tricky task (required MAC level address translation). I have never tested Ethernet Bridge over Thunderbolt, but I suspect that it has its own specifics which should taken into account.

                      in reply to: WindowsPacketFilter/Tools/ebridge not working #11501
                      Vadim Smirnov
                      Keymaster

                        Ebridge implements the transparent bridge and thus it does not affect ipconfig output.

                        in reply to: ebridge x64 exist? #11493
                        Vadim Smirnov
                        Keymaster

                          I think the problem is that TB3 adapters are not persistent and in order to provide the reliability Ethernet Bridge have to reconfigure dynamically, e.g detect when TB3 adapters added/removed to/from the system.

                          You could use https://www.ntkernel.com/docs/windows-packet-filter-documentation/c-api/setadapterlistchangeevent/ to monitor network adapter changes and reconfigure the bridging accordingly.

                          in reply to: ebridge x64 exist? #11491
                          Vadim Smirnov
                          Keymaster

                            If you ask about x64 build of this tool then regretfully no, it does not exist for x64. However, user-mode implementation of Ethernet Bridge is available for both x86 and x64.

                            Source code:
                            https://github.com/wiresock/ndisapi/tree/master/examples/cpp/ethernet_bridge

                            Binaries:
                            https://github.com/wiresock/ndisapi/releases/tag/v3.2.28.1

                            Implementation details:

                            Bridging Networks with Windows Packet Filter

                            in reply to: about gateway #11488
                            Vadim Smirnov
                            Keymaster

                              OK, if you need to SOCKSify the traffic from 10.0.0.0/24 then the NAT is a wrong proposal. Instead you can redirect TCP/UDP traffic from the 10.0.0.0/24 to the local (running on the gateway) transparent TCP/UDP proxies which will handle the authentication with SOCKS5 server and forward traffic through it. I have mentioned the SOCKSIFY sample above which does this for the locally originated traffic, but the same can be easily done for the LAN traffic too.

                              Another component you may need here is DHCP server to assign IP addresses to the PS4 and XBOX, it can be a part of your software or external service.

                              You can use support(at)ntkernel.com if you prefer the direct communication.

                              in reply to: about gateway #11486
                              Vadim Smirnov
                              Keymaster

                                OK, let’s assume you have a PC with two network adapters: first network adapter having an address 10.0.0.1 is connected to the LAN segment with PS4 and XBOX, second network adapter with an address 192.168.1.25 is connected to the Internet via your home router and you would like to pass TCP/UDP traffic from the PS4 and XBOX through the remote SOCKS5 server (GPN server) to optimize the latency on the route. Is that correct so far?

                                in reply to: about gateway #11484
                                Vadim Smirnov
                                Keymaster

                                  If you need to ‘socksify’ the traffic then this sample could be more useful:

                                  https://github.com/wiresock/ndisapi/tree/master/examples/cpp/socksify

                                  It is a little bit limited, e.g. it intercepts only locally originated traffic and passes it through the SOCKS proxy. The same can be done with non-local traffic either. However I need more details…

                                Viewing 15 posts - 481 through 495 (of 1,486 total)