N3iwf ipsec tunnel establishment using strongswan but packets are routing through regular socket instead of ipsec tunnel

Q/A
#1

During the ipsec tunnel establishment between the free5gc and strongswan, n3iwf is using ip address 192.168.127.1 to exchange packets, and also free5gc is creating 10.0.0.1 with virtual ip, ipsec0, to connect with the client’s subnet 10.0.0.x (random). After the establishment of ipsec tunnel, free5gc is sending registration accept and the client is sending the registration complete message from 10.0.0.1 to 10.0.0.x but it is not going through the ipsec tunnel, instead it is going through like a regular socket. Please give us some guidance where should we look into or which configuration to change.
10.0.0.x – 192.168.86.33 =========== 192.168.86.34 – 10.0.0.1
l-----------------------------===========---------------------------l it should be like this but
l---------------------------------------------------------------------------l

Thank you in advance.

#2

Hi @joseph1267

Strongswan doesn’t implement the authentication methods for 5G like EAP-5G, 5G-AKA, etc…
It leads that the IKEv2 only establishes the IKE SA (likes the control plane of IKE), but there is no IPSec SA (Child SA) used to 3GPP CP/UP. This half-complete IPSec cannot transfer UP data.You can check this with ip xfrm state. Are there 2 IPSec tunnels ?

Perhaps, You implement the authentication methods for 5G with the strongswan plugin and make IPsec complete. Does the strongswan configure a vti with mark or routing rules for the IPSec traffic?

#3

Thank you for your reply @yt8956gh
Strongswan does not implements the authentication methods for 5G but I added hard coded eap messages so that it can do the authentication using 5G-AKA. And I was able to check the ip xfrm state in strongswan side and it was created as expected with proper spi, hmac and other parameters.
Before starting the strongswan I start out by adding some shell commends that will add vti for the ipsec traffic, and even though I do not create the vti, strongswan will create its own ipsec0 interface with vti type.
and when I ping from 10.0.0.8 (UE vti0) to 10.0.0.1 (free5gc vti), it goes through the tunnel as ESP, and it reaches the 192.168.86.34 interface but it will not go all the way to the 10.0.0.1 interface… what is the problem here?

#14

Hi joseph1267! I am currently looking for a way to adapt Strongswan code to perform 5G AKA authentication against N3IWF node (as defined in 3GPP R15). Would you be kind enough to share at what level you have inserted hard coded EAP payload ?
Thanks !

#15

@gdeb-gh
Hi gdeb-gh, I have inserted in the level of strongswan code itself. So, when I run the strongswan, it will only send the eap payload with the exact payloads, which means there won’t be able to configure to any other authentication key. It is inserted the parameters in the eap payload parameter when it was suppose to send the created eap parameter.

1 Like
#16

Thank you joseph1267 ! (my first name is Joseph too :slightly_smiling_face:)
I have been working on Strongswan suite code (various adaptations to interwork with 3GPP ePDG nodes) for a couple of years now and I know it’s pretty vast!
So, I was wondering if you you could be more specific on where (i.e. which module) you have successfully inserted the static EAP payload.
I’m currently working on the developpement of a N3IWF capable UE simulator, which I’m using currently against a 5G SA solution (including N3IWF containerized NF) from a main network vendor. Your help would be much appreciated and any valuable result shared with the community !

#19

@gdeb-gh
Hi gdeb-gh, I have just started learning about the 5G-AKA, EAP, Ipsec, and ikev2 about 3 month, so I do not have much knowledge as you do. But the place I changed was the source code of the strongswan, eap_payload.c. I am not sure about the modules about the strongswan…

#5

@joseph1267
Are the key of vti on the N3IWF side and the IPSecInterfaceMark in n3iwfcfg.yaml the same?
The SA used to decrypt ESP packets has the key, also be called a mark, like an index in Linux kernel. And Linux kernel will make the inner packet go to the interface with the same key.
Otherwise, the inner packet is not be decrypted properly and dropped by kernel.

#6

@yt8956gh
Thank you for the reply yt8956gh
I added commend line in run.sh with
“sudo ip tunnel add ipsec0 mode vti local 192.168.86.34 remote 192.168.86.33 key 5”
“sudo ip addr add 10.0.0.1/32 dev ipsec0”
“sudo ip link set ipsec0 up”

and in my n3iwfcfg.yaml,
IPSecInterfaceMark is set to 5

Thank you

#8

@joseph1267
Well… It’s weird that the packet stops at 192.168.86.34.
Is there a routing rule for 10.0.0.1 on the N3IWF side?

Can you supply the config and pcap files of the N3IWF and UE sides?
Please attach stongswan 5G-AKA patch also if it’s convenient.

#9

free5gc_side.pcap (2.1 MB) strongswan_ue_side.pcap (23.6 KB)

@yt8956gh
Thank you again for the reply,
I have enclosed the pcap for both side,
Topology: 10.0.0.8–192.168.86.38 ==== 192.168.86.39 --10.0.0.10
I did not add any other additional routing rules to the n3iwf side.

I also learned that strongswan only does the espinudp xfrm state and policy. And free5gc uses tcp, do you think that will also matter for this issue?

Thank you

#10

@joseph1267
It looks like IKE stops at IKE_AUTH. But I have no keys to decrypt the IKE packets for more details. Did you save the keys for decryption? They are printed when the N3IWF log level is trace.

And I’m not familiar with the espinudp you said. I guess it’s ESP encapsulated in UDP for NAT-T. Unfortunately, N3IWF only using ESP as L4 protocol in IPSec has not supported the NAT-T yet.

Maybe your problem is resulted by that ESP without UDP is unable to go through NAT.

#11

@yt8956gh
Thank you yt8956gh for your help.
“N3IWF only use ESP as L4 protocol” means that it is using espintcp, (TCP encapsulation)? or does it mean something else?
I checked the N3IWF source code and it was checking for NAT-T with the configuration payload and if the other side wants to use NAT-T, free5gc changes the xfrm state and poilcy to use espinudp.

image
image899×211 31.7 KB

image

But, free5gc is not supporting NAT-T yet right? then will free5gc support NAT-T in the future?

Thank you again for your help.

#12

@joseph1267
I remember it’s the ESP in IP rather than ESP in TCP like the figure following. :thinking:
image

We implemented a partial NAT-T function in IKE but did not test this function thoroughly. Maybe it will go with failure. It’s in the plan for the future indeed, but I cannot guarantee anything.

#13

@yt8956gh
Thank you yt8956gh,
I see.Free5gc may implement the NAT-T function in the future. Ok then, I have worked around this ipsec issue, and just sent the registration complete message to the free5gc using the tcp socket and not through the ipsec tunnel, this way, even though the packets are not encrypted or decrypted with esp but will be able to reach the free5gc just by the sockets. And I could see that free5gc was processing accordingly. And I also sent a PDU session establishment request message and was able to receive the Create child SA request message from the N3IWF core. But in the free5gc it was sending the request message as a initiator, and not as responder. During the first IKE SA INIT message Strongswan sends the IKE message as the initiator, so, I thought free5gc should send the Create Child SA message as a responder perspective. Am I thinking correctly?
I also found a bug in free5gc that when it sends the configuration payload with configuration attributes, the ip address and the Mask, the ip address is sent in 16 bytes not 4 bytes through the ike message. As a result it gives an length error in the strongswan. I believe that is because golang library uses byte stream in the same manner between the ipv4 message and ipv6 message.
Thank you.

#17

@joseph1267
The role of the initiator or responder depends on who initiates the request in the exchange. It’s not fixed. In RFC 7296 Section 1.3. The CREATE_CHILD_SA Exchange

Either endpoint may initiate a CREATE_CHILD_SA exchange, so in this
section the term initiator refers to the endpoint initiating this exchange.

Therefore, the role could change after CREATE_CHILD_SA.

Move back to 3GPP spec. The N3IWF sends the CREATE_CHILD_SA request at TS 23.502 4.12.5. Although, the role changing is not said obviously. In my opinion, the request sent from N3IWF makes it an initiator.

I will check the configuration payload bug you said. THX.

#18

@yt8956gh
Thank you for the reply yt8956gh,
I can see that Child SA can be sent from both side either the initiator or the responder can start the CREATE_CHILD_SA exchange, but as far as I know, the the Original Initiator should be the same until the IKE SA is expires.

image
image533×501 8.27 KB

But, in the free5gc, while sending a CREATE_CHILD_SA, it sends the SPI with switched order, which gives a strongswan error.
image
image820×313 47.1 KB

As you can see in the picture, free5gc creates the IKE header with the LocalSPI (free5gc side SPI) the initiator instead of the RemoteSPI (strongswan side SPI). Is this some kind of bug? or am I mistaking it?
image

Thank you again

#20