[Vadim Smirnov]

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

[Vadim Smirnov]

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.

[Vadim Smirnov]

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.

[Vadim Smirnov]

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

[Vadim Smirnov]

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

[Vadim Smirnov]

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.

[Vadim Smirnov]

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

[Vadim Smirnov]

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.

[Vadim Smirnov]

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.

[Vadim Smirnov]

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

[Vadim Smirnov]

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.

[Vadim Smirnov]

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

[Vadim Smirnov]

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.

[Vadim Smirnov]

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?

[Vadim Smirnov]

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…

[Author]

Posts