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?
Related
Edit:
I think based on the below answer here, it seems the answer is "client and server basically only communicate on one port, 3478 (or equivalent")
rfc 5766 : Issue when Both devices support TURN
==========================.
I have been reading several sources on TURN, including RFC.
I get the whole premise:
Client creates allocation on TURN server
Client sends data to Peer through TURN that relays via the relayed transport address
Same way around from peer --> Server --> client
Most resources focus on setting up the server and what ports need to be configured.
The point that I am unclear is on the client side:
After the allocation is done and the client can start sending data, do they send that data to the relayed transport address that the Server allocated? Or do they send it to the standard TURN port e.g. 3478, and then the server takes care of looking up the allocation for this client and send it through the relayed address to the peer?
Example:
Client address 192.6.12.123:45677 (let's assume it's the NAT)
TURN server listens on 34.45.34.123:3478
TURN server has done an allocation for client on 34.45.34.123:50678
So when the client wants to send to a peer application data, do they send on port 3478 or port 50678?
My assumption (based also on some wireshark captures I tried) is that the client always send everything on port 3478 and the server takes care to send via the relayed address.
My assumption (based also on some wireshark captures I tried) is that the client always send everything on port 3478
The client will pick a random local port (e.g 45677), but traffic sent from this port goes to the server's port 3478 (or 5349 if using TLS) on the server. The server will forward it through its allocated port (50678) to whatever remote port the other client established during ICE negotiation.
When I connect to SSH I use port 22 as destination, but when the reply comes back, does it come in on port 22 as well? Or is the client source port randomly assigned as in other TCP communication?
If set up a firewall allowing outbound traffic to port 22 - Do I also need to allow incoming traffic on port 22?
The client SSH port is randomly assigned, as in most client/server systems over TCP/IP.
Were the client port fixed, you would not be able to open multiple SSH connections from the same client IP address, as the connections would be indistinguishable on an IP protocol level. The client port number is the only piece that makes the connection unique (client IP, server IP and server port being the same).
You do not need to allow the incoming traffic though. There is only one outgoing connection in SSH (the responses from the server come over an existing connection).
Currently i have facing one problem in portrestrictedcone nattype.When my udp client hit the server with test1.dns.com (to sepcific IP 111.111.111.111 and this ip is bind with DNS test1.dns.com) where i am getting response from different IP and not with 111.111.111.111, however the same scenario is working for fullcone nattype. If the server response from the same above ip i am able to get the response.
Currently there are two services running on the server on UDP, one is which is working in portrestrictedcone and send response on same IP as a result i am getting the response, however second service is not behaving in same was as first service works.
i am running both the services on same DNS as i have describe above.
Can i get the help what i need to change on the server or client side to get this resolve?
I think your problem is that you are not sending the packet to the port you received it from (Allocated by NAT). When you receive a packet, check the port that was used to send it then send your response to that port and not to a predefined port because the NAT might change it.
Right now I have a client-server program that works over LAN. I have managed to ensure that traffic sent to my server gets past the firewall of my company. However, problems occur when the client is communicating from within a LAN - how can I make sure that traffic gets past the firewall/router of the client and to the machine?
Once the client has sent a packet of data the server analyzes this and is meant to send a response; however the server program seems to freeze after the following lines
Dim ip As String = (IPAddress.Parse(CType(ClientToManage.Client.RemoteEndPoint, IPEndPoint).Address.ToString())).ToString SendResponse = New TcpClient(ip, 8000)
Possible issues are:
- The server's firewall is blocking outgoing TCP traffic at port 8000.
- The client's firewall is blocking incoming TCP traffic at port 8000.
Adjusting your client's and/or server's firewall settings to allow incoming, respectively outgoing TCP traffic at port 8000 might fix the issue.
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