I'm in a hurry at the moment.
My Question is, is there a way to forward UDP to TCP port?
I need this for hosting a game server for my friends, I want to
host Counter-Strike server for example, but it uses UDP (User Datagram Protocol) for server port, but NGROK only supports TCP (Transmission Control Protocl) & HTTP (HyperText Transfer Protocol).
I tried this while ago..
ngrok tcp 127.0.0.1:27015
and as usually it will start :
ngrok by #inconshreveable (Ctrl+C to quit)
Session Status online
Account Soricy Infinitive (Plan: Free)
Version 2.2.8
Region United States (us)
Web Interface http://127.0.0.1:4040
Forwarding tcp://0.tcp.ngrok.io:18833 -> 127.0.0.1:27015
Connections ttl opn rt1 rt5 p50 p90
0 0 0.00 0.00 0.00 0.00
But fails to connect to 0.tcp.ngrok.io:18833 in the game, and displays that there is no UDP configured on the server side.
Is there any way I could do this differently? UDP=>TCP?
Checkout DatagramTunnneler (on github). It is an open-source c++ program which simply listens to UDP traffic and forwards it to a TCP endpoint of your choice. On that TCP endpoint another instance of the DatagramTunneler publishes the UDP data back onto a UDP channel.
Disclaimer: I wrote that tool.
One way is to copy the "raw" udp Payload and create a new TCP packet with the raw payload. But you need to set the same data of the other layer except the udp layer. Also: You need a clean configuration of the tcp layer.
Related
I'm using GCP like in the following schema:
TCP balancer -> backend-service -> MIG(my app) with auto scaling.
"My app" accepts commands on a TCP port (A) and sends notifications on another TCP port(B) for subscriber.
I'm running my tests against TCP LB's IP - my tests connect to port B on a startup(i.e. one of instances of "my app") and also my tests make a connection to port A for each test.
i.e. I've faced with a case when port A and port B are terminated/connected to different hosts.
I am not sure how to circumvent this case.
I have mitigated the issue using --session-affinity=CLIENT_IP for backend-services configuration, I.e. all connections from one IP are directed to the same target.
I have installed the TURN server everything in the server code is working fine. no error in the log file. only a warning stating
0: WARNING: I cannot support STUN CHANGE_REQUEST functionality because only one IP address is provided
but the TURN server running on the server.
here is what shows when I check lsof -i :3478
turnserve 999 root 15u IPv4 446811411 0t0 TCP domain.com:stun (LISTEN)
turnserve 999 root 23u IPv4 446811417 0t0 TCP domain:stun (LISTEN)
turnserve 999 root 24u IPv4 446810998 0t0 UDP domain.com:stun
turnserve 999 root 25u IPv4 446810999 0t0 UDP domain.com:stun
when I check STUN in Trickle ICE it throws an errors
The server stun:xxx.xxx.xxx.xxx:3478 returned an error with code=701:
STUN server address is incompatible.
The server stun:xxx.xxx.xxx.xxx:3478 returned an error with code=701:
STUN allocate request timed out.
what's going wrong in this.
Thank you
I think that 701 error is a more generic connectivity error that Trickle ICE uses to indicate it didn't get a binding response back. Run stunclient your.stun.ip.address with the command line tools at www.stunprotocol.org to see if your STUN service is accessible from the outside world.
STUN technically requires being hosted on a device with two IP addresses and two ports. It's typically a command line parameter to specify which IP addresses the server should listen on. But most server implementations can operate on a host with a single IP address.
The second IP address and port on the server is used for STUN client filtering tests to detect what type of NAT is in effect. The client sends a binding request on the server's primary ip and port, but with a change request attribute to have the server respond from the alternate IP address or port. More often than not, this binding request with a change-request attribute fails since NATs will not forward traffic from the other IP/port.
The filtering test is useful for logging what type of NAT the client is on. So that failed connections can be debugged and that success/failure metrics can be correlated to NAT type.
Since most ICE implementations will exchange all available address candidates (local, mapped, and relay), the filtering test isn't very or useful to connectivity establishment.
I'm surprised Trickle ICE is giving you an error. I didn't think WebRTC ever used the changer-request attribute. I just did a Wireshark trace of a Trickle ICE session to stunserver.stunprotocol.org. I don't see the webrtc client setting the change-request attribute in either of the two binding requests it makes.
More details in RFC 5780 Section 3.2
In macOS, I just do so:
> brew install stuntman
when it done
> stunclient stunserver.stunprotocol.org
Binding test: success
Local address: 198.18.0.1:54898
Mapped address: 210.0.158.130:56750
To specify port, just like this:
> stunclient stunserver.stunprotocol.org 3478
Binding test: success
Local address: 198.18.0.1:63061
Mapped address: 210.0.158.130:37126
Have fun!
Lets assume Host X has a UDP Socket running on Port 1337.
Now Host Y and Z both send a UDP Packet to port 1337 of Host X.
Are the packets going to be de-muxed?
UDP is a transfer protocol with no guarantees of delivery and doesn't have much of an implementation.
When both host Y an Z send a UDP packet to port 1337, and assuming both packets arrive, the application listening on port 1337 decides what happens with those packages. The application can choose which packet to demux, to demux both or to demux neither.
Hope this clears things up
I am trying to monitor a remote IP port for outgoing data.
At the minute I have a TCP port connected which is stuck in a deliberate (almost) infinite loop.
This works, until the tcp connection is broken for any reason.
It just feels better to monitor the remote port for outgoing data, but all the classes/functions I find are for receiving data on a particular port.
Any ideas?
I'm tunneling all of my internet traffic through a remote computer hosting Debian using sshd. But my internet connection becomes so slow (something around 5 to 10 kbps!). Can be anything wrong with the default configuration to cause this problem?
Thanks in advance,
Tunneling TCP within another TCP stream can sometimes work -- but when things go wrong, they go wrong very quickly.
Consider what happens when the "real world" loses one of your TCP packets: after a certain amount of not getting an ACK packet back in response to new data packets, the sending side realizes a packet has gone missing and re-sends the data.
If that packet happens to be a TCP packet whose payload is another TCP packet, then you have two TCP stacks that are upset about their missing packet. The tunneled TCP layer will re-send packets and the outer TCP layer will also resend packets. This causes a giant pileup of duplicate packets that will eventually be delivered and must be dropped on the floor -- because the outer TCP reliably delivered the packet, eventually.
I believe you would be much better served by a more dedicated tunneling method such as GRE tunnels or IPSec.
Yes, tunelling traffic over tcp connection is not a good idea. See http://sites.inka.de/bigred/devel/tcp-tcp.html