Gtp5g module incorrectly delivering packets to userspace process when src IP is not within 60.60.0/24

Q/A
,
#1

Dear support team,

I am working with a modified version of the N3IWF test where I want to route packets from behind the UE to the data network behind the UPF, i.e. the UE is acting as a router.

The following image describes the setup I am working with:

image
image1141×650 50.9 KB

In this setup I can successfully ping between the UE namespaces and the data network, e.g. between 60.60.0.1 and 60.60.0.101. However, ping fails when I do it from 10.0.1.2. What happens is that the packet is correctly routed by the UE into the N3IWF tunnel, and the N3IWF correctly binds the packet into a GTP tunnel towards the UPF. In the UPF namespace I can see the packet on veth1 but it is not delivered to upfgtp0.

What is happening is that the gtp5g kernel module does not match on the packets coming from 10.0.1.2 with destination 60.60.0.101, and instead delivers the packets to the free5GC UPF process, which fails because this process cannot handle GTP transport PDUs (header type 255).

I attach an image from a pcap captured between the N3IWF and the UPF, where you see the ICMP echo request from 10.0.1.2 towards 60.60.0.101.

image
image1483×594 111 KB

And here I attach the full pcap.
test.pcap (1.0 KB)

This is the upfcfg.yaml file that I use in the test:

info:
  version: 1.0.0
  description: UPF configuration

configuration:
  debugLevel: info

  pfcp:
    - addr: 10.200.200.101

  gtpu:
    - addr: 10.200.200.102

  apn_list:
    - apn: internet
      cidr: 60.60.0.0/24

This is the SMF configuration file that I am using. As you can see I specify 10.0.0.0/16 as ue_subnet.

info:
  version: 1.0.0
  description: AMF initial local configuration

configuration:
  smfName: SMF
  sbi:
    scheme: https
    ipv4Addr: 127.0.0.1
    port: 29502
    tls:
      key: free5gc/support/TLS/smf.key
      pem: free5gc/support/TLS/smf.pem
  serviceNameList:
    - nsmf-pdusession
    - nsmf-event-exposure
    - nsmf-oam
  snssai_info:
    - sNssai:
        sst: 1
        sd: 010203
      dnnSmfInfoList:
        - dnn: internet
    - sNssai:
        sst: 1
        sd: 112233
      dnnSmfInfoList:
        - dnn: internet
  pfcp:
    addr: 10.200.200.1
  userplane_information:
    up_nodes:
      gNB1:
        type: AN
        an_ip: 192.188.2.3
      UPF:
        type: UPF
        node_id: 10.200.200.101
        up_resource_ip: 192.188.2.2
    links:
      - A: gNB1
        B: UPF
  ue_subnet: 10.0.0.0/16
  nrfUri: https://localhost:29510

If instead of the smfcfg pasted above I use the default one with ue_subnet: 60.60.0.0/16, then I can ping from the UE namespaces, i.e. from 60.60.0.1 to 60.60.0.101, but I cannot ping from 10.0.0.0/16, which is what I really want to do.

My questions are:

  • Is it possible to configure the SMF so the UPF will route packets from 10.0.0.0/16 towards the data network 60.60.0.0?

  • If not possible in the current implementation. I imagine the UPF implementation can be modified in order to program a rule that enables this configuration in the gtp5g module. Could you provide some guidance on to how to do that?

  • Finally, is there any command line tool I can use to dump the rules installed in the gtp5g kernel module?

Thanks for you support

BR

Daniel

#3

Hi,

Can you provide the whole pcap file including pfcp message so that we can check the n4 message set from SMF?

Thanks

#4

Hi,

I attach the following pcaps:

1- PFCP captured when ue_subnet: 10.0.0.0/16 in smfcfg. Here we can see that the SMF establishes sessions with UE IPs 10.0.0.1 and 10.0.0.2, which do not correspond to the actual UE IPs configured in my setup and this is why routing is not working.

pfcp_ue_subnet_10_slash_16_displayed.pcap (1.5 KB)

2- PFCP with ue_subnet: 60.60.0.0/16 in smfcfg. Here we see how SMF correctly establishes sessions for UE IPs 60.60.0.1 and 60.60.0.2 which correspond to the IPs configured in the UE namespace, and this is why I can ping from there.

pfcp_ue_subnet_60_slash_16_displayed.pcap (1.5 KB)

3- PFCP with ue_subnet: 10.0.1.0/24, where the SMF established session with UE IP 10.0.1.1, which this time I configure in the MPTCP namespace (not so in my original diagram where I had configured 10.0.1.2 in this namespace). In this case, after adding route 10.0.1.0/24 in the UPF namespace through upfgtp0, I can see that ping from 10.0.1.1 to 60.60.0.101 works correctly.

pfcp_ue_subnet_10_slash_24_displayed.pcap (1.5 KB)

Looking at this behavior I understand that SMF is hardcoded to setup rules for each UE that connects simply computing the UE IP by adding 1 to the IP of the last session established starting from the ue_subnet parameter in the smfcfg file. Is this correct?

My question would be if there is anyway to make this behavior more flexible. For example specifying in the smfcfg a UE IP linked to a particular SUPI, and then the SMF will configure explicitly rules for those IPs?

I am assuming that in the setup that I am using there is no way for the SMF to discover dynamically the IPs of the UEs, since basically I am assigning those by hand.

BR

Daniel

#5

First, I think your cidr should change to 10.x.x.x/x. This might influence the route set by upf.

#8

I believe apn is correct because the data network is indeed 60.60.0.0/16. However, what I want to do is to access this data network from a subnet (10.0.1/24 and 10.0.2/24) located behind the UE. For this I need to provide UPF rules related to these IPs.

#10

The UPF will create a route to set this cidr ip range to go to upfgtp0.

You can use ip route to check there will be a new route add to your OS.

This is what shown if I modify the cidr to 10.10.0.0/16

10.10.0.0/16 dev upfgtp0 proto static

I think this will solve the problem you have observe that the packet does not deliver to upfgtp0.

In the UPF namespace I can see the packet on veth1 but it is not delivered to upfgtp0.

#6

I check your smfcfg.conf with ue_subnet: 10.0.0.0/16. I think for 1-PFCP, the smf assigned UE IP 10.0.0.1 and 2 is correctly in the ue ip range?

#9

Here you can see how the SMF assigns the IPs that you mention:
pfcp_ue_subnet_10_slash_16_displayed.pcap (1.5 KB)

However this is not the correct range, note that in my diagram I have 10.0.1/24 and 10.0.2/24. Modifying ue_subnet: 10.0.1.0/24, then I get the SMF to provision IPs 10.0.1.1 and 10.0.1.2. This partially works for me if I assign this IPs in the MPTCP namespace. I will have to modify routing there to enable to interfaces with IPs in the same subnet. You can see the PFCP traces here:
pfcp_ue_subnet_10_slash_24_displayed.pcap (1.5 KB)

It would be great though if free5gc can provide a more flexible mechanism to program rules into the UPF. For example per SUPI in the smfcfg, or simply list the UE IPs and the APN they need to connect to in the smfcfg.

#11

@dcamps What UE did you use to communicate to the n3iwf?

#12

Hi,

As far as we know, currently there is no commercial UE supporting N3IWF; we just test the functionality by simulating.

#13
#7

Yes, that’s right.

For the recent free5GC, we do not provide this feature. But we’ll discuss and check whether should we work on this feature in the future.

I’m not sure for this behavior. In mobile network, UE’s IP must be assigned by core network right?