Verifying UE Data Bearer and IP Traffic Flow

1. Understanding the Data Path

The attach procedure you completed established a signaling connection. To transport user data (like web browsing or video streaming), the network sets up a dedicated logical channel called an EPS Bearer. This bearer acts as a tunnel for IP packets, stretching from the UE all the way to the Packet Gateway (PGW) in the core network.

When srsUE successfully establishes a default bearer, your Linux system creates a corresponding virtual network interface, typically named tun_srsue. This interface is the UE's gateway to the cellular network. All IP traffic originating from the UE will be sent through this interface.

You can verify that the interface was created and has the IP address assigned by the core network using the ip command:

# In a new terminal, run this command while srsUE is attached
ip addr show tun_srsue

You should see an output similar to this, confirming the interface is up and has an IP address in the 10.45.0.0/16 range:

8: tun_srsue: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1400 qdisc fq_codel state UNKNOWN group default qlen 500
    link/none 
    inet 10.45.0.2/24 scope global tun_srsue
       valid_lft forever preferred_lft forever

This is a key indicator that the bearer was established successfully.

The diagram below illustrates the path our test traffic will take: from the UE, through the srsRAN base station, into the Open5GS core, and finally out to the internet. Our goal is to verify this entire path.

2. Configuring the Host for Internet Access

Your UE now has an IP address, but it lives in a private network (10.45.0.0/16). To allow it to reach the internet through your host machine, two standard networking configurations are required on the host running Open5GS.

Enabling IP Forwarding

First, you must configure the Linux kernel on your host machine to forward IP packets between its network interfaces. This effectively turns your host into a simple router.

As the document shows, you can enable forwarding with the following command on your host machine:

sudo sysctl -w net.ipv4.ip_forward=1

Setting up Network Address Translation (NAT)

Next, you need to "hide" the UE's private IP address behind your host's public-facing IP address. This is done using Network Address Translation (NAT), a concept you're likely familiar with from your work in web security and general IP networking. We will add an iptables rule to handle this.

The following video explains this NAT rule in the context of an Open5GS setup.

To implement this, first identify your host's primary network interface name (e.g., eth0, ens33) using the ip addr command. Then, execute the following iptables command on your host, replacing [HOST_INTERFACE] with your actual interface name:

sudo iptables -t nat -A POSTROUTING -s 10.45.0.0/16 -o [HOST_INTERFACE] -j MASQUERADE

This rule tells the system to masquerade any traffic from the 10.45.0.0/16 subnet that is leaving via your main network interface.

3. Verifying IP Traffic Flow

With the configuration complete, it's time to perform the final verification. We will send ICMP packets (ping) from the UE to a public server and watch them traverse our network.

This requires running commands in the context of the srsUE, which operates in its own network namespace. The srsRAN ZeroMQ setup creates a namespace called ue1.

The following guide demonstrates exactly how to perform this test, including how to capture the traffic on the core network side.

Now, let's put this into practice. You will need three terminal windows on your host machine.

1. Terminal 1: Start the Network

   • Ensure Open5GS and srsenb are running.
   • Start srsue and wait for it to attach and get an IP address.

2. Terminal 2: Monitor the User Plane

   • Once the UE is attached, run tcpdump on the Open5GS host to monitor the user plane interface for ICMP traffic. This will show us the packets as they exit the core network tunnel.

   sudo tcpdump -i ogstun -n icmp
   

3. Terminal 3: Send Traffic from the UE

   • Using the ip netns exec command, send a ping from the UE's namespace to a public DNS server like Google's 8.8.8.8.

   sudo ip netns exec ue1 ping -I tun_srsue 8.8.8.8
   

Expected Outcome:

• In Terminal 3, you should see successful ping replies.
• In Terminal 2, you should see the corresponding ICMP echo requests and replies being captured by tcpdump, confirming the traffic is flowing through the ogstun interface.

If you see both, you have successfully verified end-to-end data connectivity!

Conclusion

Congratulations! Your private 4G test lab is now fully operational and verified. You have not only established a connection but have confirmed that user data can flow from a software UE, across a software-defined radio access network, through a complete core network, and out to the public internet.

Key Takeaways:

• A successful UE attach results in the creation of an EPS Bearer for user data, which manifests as a tun_srsue virtual network interface on the UE's host system.
• For the UE to access the internet, the host machine running the core network must have IP forwarding enabled and a NAT rule (iptables MASQUERADE) to translate the UE's private IP.
• Verification involves using tools like ping or curl from within the UE's network namespace (ip netns exec ue1 ...) and explicitly specifying the tun_srsue interface.
• Simultaneously running tcpdump on the core network's ogstun interface provides definitive proof that the traffic is passing through the user plane.

Preview of the Next Lesson:

Your lab is working perfectly, but in security research, understanding failure is as important as achieving success. In the next lesson, we will focus on diagnostics, covering the learning outcome: Use logs from srsRAN and Open5GS to diagnose a common connectivity failure. This will equip you with the troubleshooting skills necessary to quickly identify issues as we move into more complex attack scenarios.