4

I have a router and a managed switch plus a couple of systems attached to those:

  • Router: 192.168.10.200
  • PC1: 192.168.10.1 (Some sort of embedded Linux)
  • PC2: 192.168.10.35 (OpenSuse)
  • PC3: 192.168.10.31 (Win 10 host)
  • PC4: 192.168.10.32 (Xubuntu 16.04 VM)

From all but PC1 (which I can only configure to a touch display and send the data) I can ping all other machines in the network.

PC1 sends UDP packets on port 47555 to PC2 only plus broadcasts ADwin Config packets (that is destination IP here is 192.168.10.255) through its port 4710. I can intercept all packets from PC1 with Wireshark on PC3 but for some reason even after using netsh (a tool I just found out about) I can still only get ADwin Config packets (on port 4710) but no UDP.

I ran

netsh interface portproxy add v4tov4 listenaddress=192.168.10.1 listenport=47555 connectaddress=192.168.10.32 connectport=47555

I'm not sure if its the arguments I've used or the fact that it's UDP we are talking about, or a combination of both.

Sadly I'm not allowed to change the iptables on PC2. Otherwise I would have just redirected incoming packets from there to the VM directly.

Any ideas how to fix this?

CC BY-SA 3.0
Improve this question
4
  • how are those all connected together? can it be that PC1 uses different ports for different Traffic eg. ADwin Config over 4710 and other Traffic over another Port
    – konqui
    Dec 6, 2017 at 12:20
  • Yes, PC1 uses 4710 for ADwin Config and 47555 for UDP packets. The PC2 accepts UDP packets on its 47555. I will add this to the question.
    – rbaleksandar
    Dec 6, 2017 at 12:51
  • So the goal is to intercept communication from PC1 to PC2 on PC3, and that doesn't work, you only get the broadcast packets? The reason likely is that the switch is "smart" and sends out unicast packets only on the port where he knows the destination MAC to be. Connect PC2 directly to PC3 if you want to intercept the connection reliable, or have PC3 impersonate PC2 by whatever means PC1 knows PC2, and then rewrite packets for PC2 (iptables in Linux, no idea how to do it in Windows 10).
    – dirkt
    Dec 6, 2017 at 15:28
  • Well, the switch is definitely a managed one so I don't know if that qualifies it as a smart one. :P As for your question - yes, I simply want to place PC3 between the two (without disrupting the communication between PC1 and PC2) and get some of the data. netsh is considered to be iptables for Windows. That is why I tried looking into it but am currently stuck. I can't change the host (Win10), can't change the config of the iptables on PC1 and PC2. So doing something on the Win host is my only option (as far as I can tell).
    – rbaleksandar
    Dec 6, 2017 at 16:00

1 Answer 1

Reset to default
1

UDP is not a supported protocol for the netsh portproxy config. The default protocol is TCP, so your command would be proxying TCP traffic on that port.

The lack of UDP support is discussed in a github issue in the WSL repo.

If UDP was supported, the command to run would look like this:

netsh interface portproxy add v4tov4 listenaddress=192.168.10.1 listenport=47555 connectaddress=192.168.10.32 connectport=47555 protocol=udp

Unfortunately, if you run that command, you'll get an error about an incorrect parameter:

PS C:\> netsh interface portproxy add v4tov4 listenaddress=192.168.10.1 listenport=47555 connectaddress=192.168.10.32 connectport=47555 protocol=udp
The parameter is incorrect.

And, if you change the last part to protocol=tcp, you'll see that the command successfully sets up a TCP tunnel.

You can also tell that the default value is TCP by running it without arguments:

PS C:\> netsh interface portproxy add v4tov4
One or more essential parameters were not entered.
Verify the required parameters, and reenter them.
The syntax supplied for this command is not valid. Check help for the correct syntax.

Usage: add v4tov4 [listenport=]<integer>|<servicename>
             [connectaddress=]<IPv4 address>|<hostname>
            [[connectport=]<integer>|<servicename>]
            [[listenaddress=]<IPv4 address>|<hostname>]
            [[protocol=]tcp]

Parameters:

       Tag              Value
       listenport     - IPv4 port on which to listen.
       connectaddress - IPv4 address to which to connect.
       connectport    - IPv4 port to which to connect.
       listenaddress  - IPv4 address on which to listen.
       protocol       - Protocol to use.  Currently only TCP is supported.

Remarks: Adds an entry to listen on for IPv4 and proxy connect to via IPv4.

(Notice the last line: [[protocol=]tcp].)

CC BY-SA 4.0
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.