top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

How IP packet flows from internet world to lte network ?

+4 votes
1,518 views

I have an query regarding flow of IP packets from internet world to lte network(till PGW) . As during attach procedure, UE gets an IP addres. when an Ue want to access a website it sends a packet to external world and it reaches till PGW and PGW sent out to internet world over SGi interface. when website server in internet world receives a request from UE it sends reply back to UE. How reply packet will flow through IP network till PGW ? Is there any change happen in ip header of packet during flow?

posted Aug 15, 2013 by Vimal Kumar Mishra

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button
check NATing

2 Answers

+1 vote
 
Best answer

The catchwords are QoS, NAT,TFT

Depending on whether the QoS requirements of the data(and the application the belongs to), the data will be allocated to the respective dedicated bearer/default bearer.
During the bearer setup, the PGW sends the TFT(Traffic flow templates), basically these are packet filters that get installed both on the PGW(for DL data) and the UE(for UL data). These TFTs are setup with either RSVP or VSNCP(not sure how), basically application endpoint IP/port numbers are mapped to the QCI(and therefore the bearer) and the IP DSCP markings .
For UL data the UE figures out the bearer (based on the dest IP/port number)and assigns relevant(as mapped from the QCI) IP DSCP markings and ToS to the IP packet, the data gets encapsulated in the PDCP frames, eNB decapsulates, recapsulates it in the GTP-u(S1) header (preserving the DSCP and ToS), all the way to the PGW(via S5/S8). The PGW extracts the original UE pkt and routes it to the next hop in the internet.

For DL data, the Internet Gateways would have a route to the UE IP pool to go via the (respective)PGW.
When the PGW sees the dest IP as one of the UEs IP, it tries to find a TFT relevant to source IP/port and thus sends the packet on the mapped def bearer. If none exist it sends on the def bearer (of that PDN connection).
To answer your question the original IP packet will not change except for the above said encapsulations and decapsulations. But normally the operator would have a NAT installed on his PGW, then ofcourse the headers will obviously change just as any network would.

answer Aug 15, 2013 by Chandra Javalkar
+1 vote

IP assigned by the PGW/GGSN is internal to the network, let me explain step by step one by one.

  1. PGW is configured (along with the router in IP network) to pull all traffic for say 10.x.x.x to itself.
  2. PGW can assign the IP addresses say 221.x.x.x to UEs.
  3. Now assume UE assigns the IP address 221.10.10.1 to a UE A.
  4. Whenever this traffic is send out beyond the telecom network it is NATed to 10.10.10.1 so whenever a response come to the UE it is pulled to the PGw as it is configured to pull the all traffic 10.x.x.x
  5. Now at PGW/entry point is is converted back to 221.10.10.1 (reverse NAT) and system deliver it to UE.

Hope this solves the mystery.

answer Aug 15, 2013 by Deepak Dasgupta
Similar Questions
+1 vote

I know that packet traverses through the Net Filter hooks but how to practically realize that, any suggestions...

0 votes

I have a setup* in which I have a server with multiple virtual network interfaces (vif1 .. vifX) that are connected (bridged) to one virtual machine each (vm1 .. vmX) which all have the same IP and MAC (let's say 192.168.1.100 resp. 00:11:22:33:44:55). In addition to that my server also has one regular network interface (eth0) connected to the rest of my network (10.0.0.0/16).

Now I would like to be able to provide NAT-like capabilities such that every packet coming from vm1 reaches the regular network as coming from 10.0.1.1, every packet coming from vm2 as 10.0.1.2 and so on. Of course, packets coming from the network destined towards 10.0.1.x should also be correctly translated by the server such that vmX will receive them.

From what I understand I could use ebtables with the snat-target to rewrite the MAC addresses for the vifX bridges, such that the remaining network would see at least a different MAC address per VM. However, I cannot see an easy solution to rewrite the IP. Using iptables nat-table and the snat-target will not work, since I would need to also filter on the source-mac or incoming device, but the snat-target is only available on the POSTROUTING chain.

One possible to solution would be to write a small program that listens on a rawsocket on every interface, rewrites packets and re-sends them on the correct interface, but I'd rather avoid that and use standard tools instead.

I would be very grateful for ideas/tips,

+1 vote

I'm looking at a strange phenomenon that occurs on an iptables firewall. There is a DNAT rule configured that maps a public IP to a private one where a web serve is listening. Normal request operate as expected that is the destination ip is modified to the private one when the request arrives at the firewall and on the response packet the private ip is mapped back to the public one.
What I noticed though is that for some response packets the source ip is *not* mapped back to the public ip and instead tcpdump shows that the packets are sent out with the private source ip. The thing all these packets have in common is that they have the RST flag set.

What could be the reason for this? Is there some particular iptables behavior that could explain this?

...