How does NAT in 3G works

Question

1) In a Android mobile, when I connect to 3G , I get a public address as 1.39.1.85 which I checked from google and the local ip for my Mobile is 10.145.15.50 which I got programatically. 2) How are these two addresses Assigned? by the BTS? NAT? 3) Is it possible for two mobile nodes can have same public IP address? 4) I know about NAT and Firewalls.

I tried UDP hole punching: A) Using Mobile A, I sent a UDP packet to a UDP server java program which captures its public ip and port. b) Using Mobile B, I sent a UDP packet to a UDP server java program which captures its public ip and port. c) For each time I receive a Packet in server I reply with a UDP packet and I am able to receive the reply in Mobile. d) But when I try to exchange the IP and Port of each mobile and send data. I cant able to receive any data on either mobile.

What could be the exact problem here?

Please explain this in as technical as possible.

Answer 1

In 4), you say you know about NAT and firewall's. Then you should also be aware of the IPv4 shortage.

So, on your provider, mobile node's get a private IP address (from the DHCP server of the G3 provider, and the public address is just an address the provides has aquired from it's internet provider.

The whole point of NAT is that several devices share the same public IP address, so YES 2 mobile devices can have the same public IP address, specially if they are on the same provider en possibly in the same area (connect to the same mast/antenna).

The whole point of NAT is to get as much devices behing one public IP address as possible. You probabely will have gotten a DNS server within this private IP range, and most likely, traffic like HTTP is ran through a transparant proxy. You don't know, but a lot of your connections never even reach the internet, if content in the proxy is fresh enough (but that is another story)

Now, what if two (or more) devices behind a NAT router (ca and cb) access two different websites (sa and sb). The router CAN choose to use the same port on its public IP address for sending the request to the server, for an answer back to the router on this public IP address/port combination is easily distinguishable: traffic from sa has to be forwarded to ca, and an answer from sb to cb.

This way, a port-translation created by a client, can ONLY be used by the server the client accessed in the first place.

Small home routers, with mayby 10 devices behing it (my small home network has 30 on last count) are very different beings than the big unit's used by the big telecom providers. Our home router does not have to be very economical with it's 65.000+ available public IP ports. This is another story for the big telecom providers. So while port translations on home routers can be very predictable, this is not the case for big telecom providers.

Google a bit on "how teamviewer works". There you will find dat teamviewer relies heavily on predictability of port-translations by routers.

In 10% (or more) of the connections, a direct connection is not possible, and the whole session is run through the server. The server has 2-way communication with each client (just like receiving a website after a request), and server-side, information from one connections is forwarded to the other and back.

Does this answer your question?

Answer 2

I didn't know the terms full cone, address restricted and port restricted. So I learn too.

Nice explenation

What happens is this:

The routers starts with a blanc sheet of scrap paper (read-port-translation memory). It is just like a table in memory. When a connection is initiated from the local lan to the public IP space, a record is created in this table: , TCP/UDP, from-IP, from-port, translated-port, dest-IP, dest-port

This table is used for 2 things: - when a new connection is initiated, the router needs to know if the translated-port, dest-ip, dest-port combination is still free (otherwise it cannot distinguise incoming traffic - when traffic comes back from the internet, "from" and "destination" are of cause reversed, so the incoming packet destination-ip, from-ip, from-port should match a translated-port, dest-ip, dest-port record from the currect translation table. The router can then reverse the magic on the packet, replace the dest-ip (=public IP router) with the original from-ip, and dito with the port.

For TCP connections, this translation record can be deleted as soon as the connection is closed. TCP uses sys/sys-ack/ack to initiate a connection, and there is also a clear way to say good-bey.

For UDP, things are a bit trickier. UDP is connection-less. So the router will have to keep the translation-record open for some time.

It probaply update's the time-stamp, everytime the rule is used, incoming or out.

It would be best, to do this also for TCP connections. If a TCP connections is not used for too long, it should also delete the translation-record.

So, just good old record keeping by the router. (give's you some respect for these things.)