Suppose I am running a TURN server bound to a public IP (say 100.0.0.1). When the server creates a relay port for a create allocation request, is it ever the case that the server would send back an IP address that is different from whatever it is bound to (100.0.0.1 in this case) in the XOR-RELAYED-ADDRESS attribute? I'm not familiar enough with networking to know all possible scenarios, and the RFC 5766 doesn't really say anything specific (as far as I can tell).
Phrased another way, is the IP address in the XOR-RELAYED-ADDRESS redundant? In all cases I have considered, the client only needs to know the port allocated, and could completely ignore the IP of XOR-RELAYED-ADDRESS. As long as the client knows the relay port, it can always send relay data to the TURN server public IP (it already knows the IP since it had to connect initially...) at the relay port.
Any comments?
If you server is not behind a NAT (on the public internet with a public IP address assigned to it), then the IP address returned in XOR-RELAYED-ADDRESS will be the same. (It will always be the same as the IP address assigned to its NIC).
I assume the reason you are considering ignoring XOR-RELAYED-ADDRESS is related to you other question suggesting the TURN server will actually be behind a NAT/firewall. I think you'll find that the IP address is predictable. But the Firewall/NAT your server sits behind has the possibility of messing up the port allocations. Make sure you understand how the TURN server does port assignments, and that your firewall does port forwarding correctly.
One bit of nomenclature clarification. Your server isn't "bound" to a public or a private IP. Your server socket binds to an interface that has an IP address assigned and associated to it.
Actually, you guys both overlooked a situation when the relay IP address and different from listening IP address, on the TURN server. The TURN Server may be listening on, say, address 1.2.3.4, but it may be allocating the relayed endpoint on two other public addresses - like 2.3.4.5 and 3.4.5.6. The real relayed IP address is returned in XOR-RELAYED-ADDRESS and it may be very different from the listening address.
Related
Here is what I think.
When I make request to some website, router through modem makes the request to the internet, (website) and gets the response. (how does it get response?) , webserver knows the router's ip address. Then router knows my private ip address and gives me back what I requested.
The question is , I heard that there's a subnet mask and I know what It does. Why do I need NETWORK ID at all? I read somewhere that it's used so that response could find the network from where request was done, but in above scenario, there's no network needed as web server knows router's ip address and gives it response.
Why do I need(does router need) NetworkId and HostId to know specifically?
There seems to be a lot of confusion here. Your router does not need a network ID, and, in this context, I do not understand what you mean by a host ID.
When I make request to some website, router through modem makes the request to the internet, (website) and gets the response. (how does it get response?) , webserver knows the router's ip address. Then router knows my private ip address and gives me back what I requested.
Eh, no. That is not how it works. When your computer makes a request to a website your computer will first think about what to do with the request.
Is the target directly connected? That means, if I AND the ip address with the netmask, is it the same as my own ip address ANDed with the netmask?
Do I have a specific route for this ip address?
otherwise, send it to the default gateway.
BTW: my own ip address ANDed with the netmask is my network. So a router may store this if it does not want to perform the calculation every time.
Your router will forward the packet to the destination. It does not make a request to the Internet. In the case of a home-NAT-router, it will modify some fields in the protocol header, but it will not make a request of its own.
As per IANA standards, below is the range for private IP,
10.0.0.0 to 10.255.255.255
172.16.0.0 to 172.31.255.255
192.168.0.0 to 192.168.255.255
Can IP addresse outside the range(above) used as private IP to communicate packets within a specific network?
Basically, you can use ever IP-Address-Range you want in your private network. There is no reglementation against this.
But you have to take precautions to avoid routing-trouble when a machine with an IP-Address that actually belongs to a public range wants to access the internet. Here you have to have a Router or Firewall that is able to NAT your internal address bidirectionally.
Sure, there is nothing preventing you from setting your static IP to anything you want. It's up to the router to decide where packets are routed. On your internal network, since you own the router, you can decide to use an IP range normally used for public traffic if you are OK with those public servers being inaccessible to you.
Note that this may cause unusual side effects with DNS if your server is running on an IP address to which another domain name resolves. The server would appear to be running on that domain. Maybe this is what you want, although with SSL you would get a warning that the server fingerprint does not match.
I understand that if I tell my computer to send TCP packets from a fake ip address - say 128.5.32.3 - then my computer will happily send the packets out but not receive them in response.
But why is no response received? At which point in the chain is the return packet dropped?
Or, to give the same question asked another way - if my internet provider assigns me some arbitrary IP address, why can't my computer tell the internet provider to give me a different, arbitrary, IP address?
It's like sending a letter with a return address in it that is invalid. The mail will still get there, but if they send it back the postman (router) will at best be able to deliver it to a fake return address.
Your internet provider gives you an address on internet that isn't arbitrary rather one of it's internet addresses it has allocated. You can't 'move house' by wishing it.
If you do move house by getting another valid address you still need to receive a response using address supplied.
The postmen (routers) are incorruptible AFAIK :)
To start with your question about why no response is received, it is because the response goes to the person whose IP you spoofed. This can be abused, and an example if this is a "smurf attack". You would need to control the spoofed IP in order to receive the response, and there would be no point to spoofing if you had this control.
As for your question about why you cannot make your ISP assign you an IP is because, firstly, your ISP has control of a range of IPs and cannot assign IPs out of its permitted range. Secondly, most ISPs won't take into account the IP that your device wants. It has full control and will control your IP how it wants, so you cannot change your external IP at will.
There are many reasons why an ISP will not give an 'arbitrary' IP address. These include
They themselves only have a block of IP addresses they are allowed to allocate to users, if the IP address you want to use is not in this block there's nothing they can do (even if they want to, which they probably don't)
You are mostly likely being assigned an IP through DHCP (unless your provider is very generous or you are paying for a static IP). This also means that your IP is frequently changing.
The reason you receive no response is, as you put it, because the spoofed address is not your IP address. You are in essence telling the receiver of the TCP packets to respond to a different user (e.g., you send a packet, and they respond to some random stranger).
I have a static local IP Address: 10.8.4., and the public IP Address of my machine is: 72.43.135.. when the server(sitting on different network from my workstation) gets a request from my machine, it sees my IP address from
Context.Request.UserHostAddress
and got 10.20.102.*.
why it the server not getting the IP as: 72.43.135.*?
If you define public and local, you will get to know that these terms might refere to the same network under some conditions. This could be a demilitarized zone (DMZ) for example.
What IP the destination server sees, depends on the interface you send the packets through and the routers it crosses.
Is there masquerading (NAT) ? - Is the main question. You can be on totally different networks but the routers might still forward your local IP, now this also depends on the routing table. Can a packet find its way back to your host? Is there a reversed route from the host to your machine?
The destination host is propably having 2 interfaces, 1 with IP 72.43.. one with a 10.8.. maybe it recieves through the 72 but sends back through the 10.8 because it has a different route back. Networking can be real voodoo! Trace your packets, ask your sysadmins..
(not talking about proxies here, they deliver different custom headers with different IPs)
I am running a TURN server (http://tools.ietf.org/html/rfc5766) on a server that is behind a firewall. The machine has a public IP address where incoming and outgoing network packets are sent to/from the server's private IP address. Basically, the server cannot bind sockets to the public IP address, only the private IP address. Running ifconfig shows the network device having a private IP address.
When I run the TURN server, I have to bind to the private IP address (since the server doesn't think it is connected to the public Internet). All responses to allocation creations send back the XOR-RELAYED-ADDRESS with the private IP address. Clients receive the XOR-RELAYED-ADDRESS and send data to the server's private IP address, which clearly fails.
There are two options I am considering to overcome this:
Have my client code ignore the IP address of the XOR-RELAYED-ADDRESS and only use the port of XOR-RELAYED-ADDRESS. Clients will send all relayed messages to the TURN server's public IP (since the client already knows this value beforehand) and the XOR-RELAYED-ADDRESS port.
Alter my server to know about its public IP (even though it can't bind sockets to it), and always send back the public IP in XOR-RELAYED-ADDRESS responses.
I feel like the first method breaks the TURN RFC...even though I can't imaging a situation where the TURN server would send back the IP of XOR-RELAYED-ADDRESS as something other than the TURN server's public IP, the RFC says that the XOR-RELAYED-ADDRESS is what clients should be sending data to.
I feel like the second method breaks the RFC less...if that makes sense. Furthermore, this method doesn't force clients to do anything special, whereas the first method needs all clients to abide by the above.
What do you think about this? Has anyone experienced this, and/or have any opinion on which method breaks the RFC less, or if the RFC is even violated by either method?
I have nearly the same exact problem running my STUN server code on Amazon EC2. The origin address and the alternate address returned by the stun server to the client are NAT'd IP addresses.
Some solutions I have thought about:
Just assume clients are pre-configured to know the alternate IP address if they actually want to do the additional NAT type detection tests. This is not a bad assumption to make for STUN. After all, they are expected to know the primary IP address of the stun service.
Modify the server code to be passed it's mapped IP addresses from the command line or config file. This is equivalent to your second method described above. I could have the server self-discover it's own external IP address via a web request (or test another stun server) when it starts up to make this automatic.
Your first proposal - clients are aware of the IP mapping - is perfectly fine assuming you aren't trying to interop with other clients other than your own. But if you think you'll have a need to use someone else's client stack, then this option becomes less desirable. You could do a hybrid approach - invent a new custom attribute for TURN Allocate responses that your client understands to mean, "ignore relay IP, just assume the port is correct". This is OK, but not great.
Your second proposal is more in line with my #2 above. There's one other thing to think about. What happens if your clients are also behind the same firewall as your TURN server? Do you want the internal address or the external? Then again, if both your clients are behind the same firewall, they likely won't need TURN to communicate. The other issue is just the administration overhead of passing the right IP address to the server.
I like your second proposal.
You could consider posting a question to the BEHAVE IETF email discussion group. They are the open committee that drafted the STUN and TURN specs. I think they should be aware that servers in the cloud running behind NATs are becoming increasingly common. They may have some advice. I would be keenly interested in joint authoring this email with you. Or at least reading their response.