UDP Forwarding - Nonsensical Ports

[jasonmerc]

When port forwarding or reverse forwarding UDP, the port number specified isn't the port number it forwards, it's that PLUS 65536. This is only for UDP, TCP works just fine.

Example: ssf -V 10000:localhost:10000 in the log files shows it forwarding to server port 75536 (which is 65536 + 10000, the port number I specified). Not only is this not the port number specified, it's an impossible port number.

I cannot find a workaround for this. Putting in a negative number, like -55536 to try and make it 10000, doesn't work.

[dcowan-london]

To anyone coming later - @jasonmerc has attempted to fix this bug in a fork, at jasonmerc@9873933

[jasonmerc]

To anyone coming later - @jasonmerc has attempted to fix this bug in a fork, at jasonmerc@9873933

I think I fixed it, but building the actual program requires libraries that are very old, so I was never able to actually compile anything.

[raventeller]

I am not really sure this is a functional issue. Sure it does forward to a "fiber" port that is [specified port]+65536
my server was started with this:
"ssfd -p 2022 -g -S"

When I use the following connection string on the client (this was all done on the same machine to different ports, but the concept is the same, there is just a lot of localhost references):
"/ssf -g -p 2022 -S -V 2700:localhost:2701 localhost"

When connected the server the log says:
"forward UDP datagrams from <127.0.0.1:2700> to fiber port 68236"

and the client side log says:
"forward fiber datagrams from fiber port 68236 to localhost:2701"

This connection works if I use netcat listener:
nc -u -l -p 2701

and netcat to:
nc -u localhost 2700

I never worked with fiber ports, but from what I can tell this create a working UDP port forwarding mechanism. I am going to do a more thorough check on this, because I actually need this functionality, so hopefully I'll remember to report back here on my findings.

[raventeller]

ok so I can UDP port forward with no issues
set up is three boxes I call them

1. TFTP server (IP addr 192.168.50.215)
   2.SSF client (IP addr 10.0.5.2)
   3.SSF server( IP addr 172.16.0.137)

on the SSF server I can tftp to one of its local ports and get a file on the TFTP server through the use of UDP port forwarding on from the SSF client.

TFTP server has open port 69 on my local network
SSF Server is a cloud instance
SSF client is my laptop on a subnet in my house

SSF server start command
sudo ./ssfd -p 2022 -g -S

SSF client start command
ssf -g -p 2022 -S -V 172.16.0.137:1869:192.168.50.215:69 172.16.0.137

then on SFF server execute the following to connect to it's IP

tftp
tftp> connect 172.16.0.137 1869
tftp> get [file name]
Received 5109 bytes in 1.1 seconds

the forwarded ports indicated on the SSF server ssf log:
[info] [microservice] [datagram_listener]: forward UDP datagrams from <172.16.0.137:1869> to fiber port 67405

the forwarded ports indicated on the SSF client ssf log:
[info] [microservice] [datagram_forwarder]: forward fiber datagrams from fiber port 67405 to <192.168.50.215:69>

all that being said. SSF only worked this way on Linux, and I did not test windows, I only have so much hair left.

[DeekyJay]

Fwiw, this isn't a real issue. That fabric port is not the actual port being forwarded. After doing the port forwarding, you can validate yourself that the port you're requesting is actually being used, and not the fabric port.