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.
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.
Through tcpdump in dhcp-server, it shows the server can receive the DHCPDISCOVER package and send the DHCPOFFER package, but can not receive the DHCPREQUEST package from the dhcp-client, so the client can not get IP address and always in send DHCPDISCOVER package.
But the dhcp-server which runs in VMWARE's instance can send DHCPACK to client and the same client will get the IP success. The dhcp-server using the same configure as in Openstack's instance.
And, if I configure the static IP address in the client instance, it will ping the dhcp-server's IP successful.
One more thing, the server and client are in the same vlan.
Is there any limit rule in Openstack's instance? How can I resolve this problem, THX.
The essential reason is that the traffic of port is limited by the security groups in openstack.
By default, all security groups contain a series of basic (sanity) and anti-spoofing rules that perform the following actions:
Deny egress DHCP and DHCPv6 responses to prevent instances from acting as DHCP(v6) servers.
Resolution:
disable security groups (no recommend)
set dhcp-relay to the dhcp server in router (recommend)
security groups limited the traffic by hypervisor's iptables which will drop the packets which's src port is 67 and dst port is 68.
DHCPOFFER packets will send to router by src and dst port 67, and it will works to all vlans.
For DHCP relay and DHCP proxy, packets sent to the DHCP server from the router have both the source and destination UDP ports set to 67. The DHCP server responds using the same ports.
Maybe there are some methods but I can't find out until now ?
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?
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 have a system that is running on windows.
I have in that system a process that waits for another process on the same machine for a udp message. The message itself is not important (garbage), but the important thing is that I got the event of the message itself.
The problem is that it seems that I get from another local program a UDP message and I don't know from where. I added information about the sender in the recieved UDP message. I see that I get message from valid local port but also from the addres 0.0.0.0 .
I can't understand the 0.0.0.0 . Does anyone has an idea ?
A computer without an assigned IP address could send such packet, even across the network - see e.g. a similar mechanism in DHCP, where the DHCP discovery packet is sent with source address of 0.0.0.0
On a local computer, could this be that the packet is sent (and received) on an interface that is up but without an IP address?
Also, this can mean "broadcast" - if this article on e2 is correct, it is a deprecated method of making a broadcast packet, but apparently it was never removed.
Because it is a udp message and using async type, when reading messages that arrive from the other program I can't know when stop reading, when I get reading the message and I get 0.0.0.0 it means I read everything from the UDP buffer from OS.