RFC 5780 for STUN defines a Response-Origin attribute for STUN messages responses sent by the server back to the requesting client.
It describes it as:
The RESPONSE-ORIGIN attribute is inserted by the server and indicates the source IP address and port the response was sent from. It is useful for detecting double NAT configurations. It is only present in Binding Responses.
How does the client use the server's source IP and port to detect double NAT configurations? Couldn't the source address information be just as easily read from the UDP packet's source field, seeing as inbound NAT only re-writes the destination address and not the source address?
Server can tell two things:
i) What IP address it sees for you. If it does not match your ip address, you know there is a NAT between you and the server. You have been translated.
ii) What IP address it sees for the remote peer, and the IP address the remote peer communicated to the server. If they don't match, the remote peer is behind NAT too.
Hence, you can find whether you are dealing with a double-NAT situation.
Now this is not to be confused with situation where there are two NATs between you and the server for example. But in this case, you don't need to worry, because the server will work with the last NAT on your way from you to the server.
Related
How we can share any type of data over the two separate networks without violating security mechanisms using UDP ?
There are a few things you'll have to remember:
Every network has its firewall, and it depends on the firewall rules, whether to allow your traffic into the network or not. First, ask your client or receiver to make changes in the firewall so that it accepts your IP address and also remember most of the systems have an edge firewall too.
Be clear with the type of connection i.e., p2p (or) server & client. It's better if it is a client & server type connection.
UDP by definition is NOT a connection-oriented protocol, so there is no state to keep track of as far as OSI layers 2-4 are concerned. All incoming UDP connections are treated as "new" or the same.
Also, see that none of the systems is under NAT connection, as the router will remember the IP and port of the device just for a while. And if there is any delay in response from client-side then the system under NAT will not know the IP or the port of the device, where it is supposed to send the traffic.
I am currently implementing a (UDP) p2p application in C using the "hole punching" method. I found really illustrating previous posts by J. Selbie where he explains the basics
and proceeded accordingly (post1, post2) but probably i'm missing something and only one of the peers is receiving data while the other one is not.
Here are the steps i am taking:
Setup: One of the peers is connected to a 4G cellular dongle (NAT A) and the other one is connected to a router that goes to the ISP provider (NAT B).
These are the results reported for stunclient (stuntman client) for both NATs.
NAT A:
Binding test: success
Local address: X1:48383
Mapped address: Y1:28265
Behavior test: success
Nat behavior: Endpoint Independent Mapping
Filtering test: success
Nat filtering: Address and Port Dependent Filtering
NAT B:
Binding test: success
Local address: X2:49158
Mapped address: Y2:49158
Behavior test: success
Nat behavior: Endpoint Independent Mapping
Filtering test: success
Nat filtering: Address and Port Dependent Filtering
Now, according to these results, it is my understanding, that both NATs have a reasonable behavior and hole punching might succeed (note that NAT A does not do port preservation).
Hole punching attempt:
Both clients contact a public facing server (STUN/rendezvous) by means of UDP to discover/interchange ip:port pairs. When each of the clients receive the response from the server, they send a UDP datagram to the other peer (ip:port as seen by the contacted public server), and then proceed to send some more and receive and reply the message to the address from which it came.
I am sending the datagrams using the same socket that contacted the public server, only changing destination ip:port on the sendto function.
The thing is, that the host behind NAT A (hooked up to the 4G dongle) always receives the message, and in spite of replying to the correct ip and port of destination, the other one behind (NAT B) never gets the message. Any ideas what i am missing here ? or how to diagnose the problem ??
Thanks in Advance.
This is standard and general scenario where p2p(peer-to-peer) call between cellular and wifi(ISP) network is not possible. Now why?
Why?: All of the cellular network uses a cost effective method where no user can have a dedicated public IP or NAT. Meaning mobiles public IP may change after a few hour or so. As a result cellular network provider can use less number of public IP for huge number of user. This process is done generally by assigning new ip:port for every request, which is a feature of symmetric NAT. So in your case as the NAT B is Nat filtering: Address and Port Dependent Filtering that means if the data comes from NAT A has unique ip:port for every send/request then the NAT B will filter the data and the call will fail.
Solution: In general you need a relay server hosted on public IP which will receive the data from A and forward it to B and B will also do so without doing any filtering. This kind of server is called TURN server.
Now I am not sure why your stuntman test client is detecting PRC NAT(Nat filtering: Address and Port Dependent Filtering) for both A and B. For A it must be Symmatric NAT as it is on cellular network.
I have took a look to STUN Server settings in openfire, and this statement from there:
"In order to act as a STUN server, two different public IP addresses on the same machine are required, as well as two different port numbers for each IP."
I have researched on google, and generally stun servers need two public IPs, what is reason for that?
For attempting to establish P2P connectivity, the STUN binding request and response to/from the STUN service's primary address (IP and port) is all that really matters. The mapped address returned in the response body of this request is passed (via XMPP or other service) to the remote node that the local client is attempting to establish directly communication with.
The second IP and port that the STUN service listens on are useful for determining NAT port mapping behavior and NAT filtering behavior.
By making binding requests to the alternate IP:port on the service, a client can discover if his NAT has consistent mapping semantics for local ports. In the event he gets different port mapping values for each test, the client can conclude it is behind a "symmetric NAT" - which are the most difficult to traverse for P2P.
By sending up a bind request with a "change request" attribute that asks the service to respond from the other IP or port, a client can detect if his NAT just filters datagrams from remote hosts based on IP and port, or allows for datagrams from alternate ports on hosts it has sent outbound datagrams to.
The mapping behavior and filtering tests only provide limited information for subsequent P2P connections. In the case of determining a symmetric NAT is between the host and the Internet, some implementations may observe the NAT to have a consistent incremental value of the port value in each binding response. (e.g. the external port observed by the STUN service increases by one). As such, the client can offer an IP and guessed port number for the remote client to try to send to instead of the one mapped back from the first binding request. Or the client may use this behavior/filtering test for logging. Or to automatically allocate a relay in the event of symmetric NAT.
Because in some rare cases, the behavior of NAT translation is a function of the target IP address. Meaning, you must 'ping' two different IP addresses to find the precise behavior of the NAT (does it depend of the target IP address or not?)
If you 'pinged' twice the same server with two distinct ports, that would not cover this case properly (i.e., you would not be covering all your bases).
P.S.: The two IP addresses don't need be on the same server, it could be different servers.
I'm guessing that it is required to identify the type of NAT being performed - some NAT will use the same source IP address and encode the session id via the port number (I think it's called cone NAT but not sure), some NAT will use a combination of source IP and port to encode the session ID. The answer the STUN server needs to give the client is different based on NAT type.
Such as Skype/Team viewer/Logmein etc application, which send audio/video behind NAT (behind firewall). But when i make a small tiny application which send text to another NAT location it failed to do the same.
Example:
Sender:
-> Public ip: 91.1.2.3 My lan ip is: 192.168.1.2 with port 14446 udp
-------> Data format: RTP packets
Receiver:
<------- Data received: 0 packets
-> Public ip: 92.1.2.3 Friend lan ip is: 10.0.0.2 with port 14446 udp
* same in both way
How others does this? What is the way of doing peer 2 peer application development to overcome NAT issues? Always we have public ip's and mostly it has NAT issues.
But how does then Skype works in such cases too? Do we have a audio/video port range for UDP or always UDP is open from anything? But mine does not work above range ports for UDP i also tried. What is the secret? that is making me curious!!.
Note:
My goal is audio packets handling where i believe too much filtering or firewall cause latency and delay and other issues gets involved relatively too. So i would like to know very clearly for my application that some of the ports (which port ranges?) can be used for such purposes, where it really not blocking development stress.
There are a number of types of NATs, which vary in what traffic they'll allow in.
See the Wikipedia article on NATs
For most NATs, STUN will let you open ports AND find out what port you opened (may be different than the port you sent from). In SIP and RTSP you'd typically provide the external IP and port determined by STUN to the other end.
A fully-symmetric NAT means that STUN won't let you use a 3rd-party server to prop ports via STUN, so you'll have to use UPnP (if enabled) or map ports in the router (or set up triggers), or you'll have to play evil games to make both sides think they initiated the connection. (Not easy and not guaranteed.)
See the ICE & TURN specs (RFCs) from the IETF for detailed mechanisms to traverse NATs - though note that in some cases you must use an external proxy to forward packets.
One common solution is that the client program connects outward to the server and thus establishes a connection. Most firewalls allow outward connections - the assumption being that you are trusted and can always connect to the outside. When the server then wishes to send a message to you, it responds on the open connection.
I believe the port that you use is what is usually used to determine if it should be allowed or not. Certain ports are always let through. I'm not sure of the exact ports, but that will be different for all NATs and firewalls.
Imagine a user sitting at an Ethernet-connected PC. He has a browser open. He types "www.google.com" in the address bar and hits enter.
Now tell me what the first packet to appear on the Ethernet is.
I found this question here: Interview Questions on Socket Programming and Multi-Threading
As I'm not a networking expert, I'd like to hear the answer (I'd assume it is "It depends" ;) ).
With a tool like Wireshark, I can obviously check my own computers behaviour. I'd like to know whether the packets I see (e.g. ARP, DNS, VRRP) are the same in each ethernet configuration (is it dependent on the OS? the driver? the browser even :)?) and which are the conditions in which they appear. Being on the data-link layer, is it maybe even dependent on the physical network (connected to a hub/switch/router)?
The answers that talk about using ARP to find the DNS server are generally wrong.
In particular, IP address resolution for off-net IP addresses is never done using ARP, and it's not the router's responsibility to answer such an ARP query.
Off-net routing is done by the client machine knowing which IP addresses are on the local subnets to which it is connected. If the requested IP address is not local, then the client machine refers to its routing table to find out which gateway to send the packet to.
Hence in most circumstances the first packet sent out will be an ARP request to find the MAC address of the default gateway, if it's not already in the ARP cache.
Only then can it send the DNS query via the gateway. In this case the packet is sent with the DNS server's IP address in the IP destination field, but with the gateway's MAC address on the ethernet packet.
You can always download wireshark and take a look.
Though to spoil the fun.
Assuming, the IP address of the host is not cached, and the MAC address of the DNS server is not cached, the first thing that will be sent will be a broadcast ARP message trying to find out the MAC address of the DNS server (which the router will respond to with its own address).
Next, the host name will be resolved using DNS. Then the returned IP address will be resolved using ARP (again the router will respond with its own address), and finally, the HTTP message will actually be sent.
Actually, it depends on a variety of initial conditions you left unspecified.
Assuming the PC is running an operating system containing a local DNS caching resolver (mine does), the first thing that happens before any packets are sent is the cache is searched for an IP address. This is complicated, because "www.google.com" isn't a fully-qualified domain name, i.e. it's missing the trailing dot, so the DNS resolver will accept any records already in its cache that match its search domain list first. For example, if your search domain list is "example.com." followed by "yoyodyne.com." then cached resources matching the names "www.google.com.example.com." "www.google.com.yoyodyne.com." and finally "www.google.com." will be used if available. Also note: if the web browser is one of the more popular ones, and the PC is running a reasonably current operating system, and the host has at least one network interface with a global scope IPv6 address assigned (and the host is on a network where www.google.com has AAAA records in its DNS horizon), then the remote address of the server might be IPv6 not IPv4. This will be important later.
If the remote address of the Google web server was locally cached in DNS, and the ARP/ND6 cache contains an entry for the IPv4/IPv6 address (respectively) of a default router, then the first transmitted packet will be a TCP SYN packet sourced from the interface address attached to the router and destined for the cached remote IPv4/IPv6 address. Alternatively, the default router could be reachable over some kind of layer-2 or layer-3 tunnel, in which case, the SYN packet will be appropriately encapsulated.
If the remote address of the Google web server was not locally cached, then the host will first need to query for the A and/or AAAA records in the DNS domain search list in sequence until it gets a positive response. If the first DNS resolving server address in the resolver configuration is in one of the local IPv4 subnet ranges, or in a locally attached IPv6 prefix with the L=1 bit set in the router advertisement, and the ARP/ND6 cache already contains an entry for the address in question, then the first packet the host will send is a direct DNS query for either an A record or a AAAA record matching the first fully-qualified domain name in the domain search list. Alternatively, if the first DNS server is not addressable on-link, and a default router has an ARP/ND6 cache entry already, then the DNS query packet will be sent to the default router to forward to the DNS server.
In the event the local on-link DNS server or a default router (respectively, as the case above may be) has no entry in the ARP/ND6 cache, then the first packet the host will send is either an ARP request or an ICMP6 neighbor solicitation for the corresponding address.
Oh, but wait... it's even more horrible. There are tweaky weird edge cases where the first packet the host sends might be a LLMNR query, an IKE initiation, or... or... or... how much do you really care about all this, buckaroo?
It depends
Got that right. E.g. does the local DNS cache contain the address? If not then a DNS lookup is likely to be the first thing.
If the host name is not in DNS cache nor in hosts file, first packet will go to DNS.
Otherwise, the first packet will be HTTP GET.
Well, whatever you try to do, the first thing happening is some Ethernet protocol related data. Notably, Ethernet adapters have to decide whether the Ethernet bus is available (so there's some collision detection taking place here)
It's hard to answer your question because it depends a lot on the type of ethernet network you're using. More information on Ethernet transmission can be found here and here