IPSEC/L2TP thru GL-X3000 not working on 5G NSR carrier

Since a few day i struggle to establish an Ipsec/L2TP vpn connection thru my GL X3000 modem connect via 5G NSA.

Cannot connect an IPSEC/L2TP VPN initiated on my laptop to the VPN server using the GL X3000 5G NSA Orange(provider) connexion.
But i can connect the IPSEC/L2TP VPN on my laptop (Apple MBP M2) to VPN server using my old Iphone 7 connected in tethering to the GL X3000 (same sim).

It seems that the 5G NSA don't provide the same capabilty as my 4G LTE cnx on my iphone7.
(I notice that in 4G my iphone receive an ipv6 but i could not stop any ipv6 on 5G NSA...)

Internet is working fine, and port UDP 500, 4500, 1701 was open with luci.
I also try to reduce the MTU to 1280 as IPSEC/L2TP is working via udp encapsulation.
But cannot find any solution to connect this VPN Thru my GL X3000 with a 5G NSA carrier.

Anyway as far as my VPN is workig thru the GL X3000 with my Iphone 4G LTE via tethering, i guess that the limitation i hit is not comming from a wrong firewall configuration in my router !

Maybe i should try to connect the GL X3000 to a 4G LTE ?
(But unfortunately, i don't understand how i can enforce a 4G cnx with AT commands; the quectel AT command manual. looks crytic to me)

Could someone can help me understand what is going wrong there ?

First of all, let's correct few things:

  • the IPsec tunnel has nothing to do with 4G vs 5G

  • Opening ports in the firewall (such as the ones shown below) has nothing to do with the IPsec - ALL outbound traffic is allowed by default UNLESS you have changed the configurations of the firewall:

  • I am connected to IPsec VPN using strongSwan IPsec Client (Linux) and Ethernet cable through the X3000 modem. I have also a laptop that is establish a connection to an IPsec VPN server on the Internet through the X3000's WiFi.

You can disable IPv6 as follow:

Please share the IPsec client you're using along with the configs and logs to investigate further.

I prefer that you connect to the x3000 using an Ethernet till you get it to work. Then switch to the WiFi.

1 Like

Thank you for your reply SpitzAX3000

I no that IPsec tunnel has nothing to do with cellular so i cannot explain this odd behavior !
To be more clear (i think i'm not a fluent english) , here is the test i done connecting the IPSec/L2TP tunnel thur GL X3000.

Laptop connected via wifi on GL X3000
Laptop connected via ethernet local LAN on GL X3000

VPN tunnel is working well via Ethernet WAN (ADSL) and Iphone7 4G tethering.
VPN cannot be established via Cellular 5G NSA even with the same nano SIM card used in my iphone for tethering. (quite surprising for me)

My VPN client is a native VPN client on my OSX darwin kernel (Sonoma 14.5).
Here is the ppp.log of a non working tunnel connection, and working tunnel connexion

Not Working:

here is ppp log of non working L2TP tunnel Thru Cellular 5G on GL X3000
---
Mon Aug 19 12:21:36 2024 : l2tp_get_router_address
Mon Aug 19 12:21:36 2024 : l2tp_get_router_address 192.168.1.1 from dict 1
Mon Aug 19 12:21:36 2024 : L2TP connecting to server '185.XXX.XXX.XXX' (185.XXX.XXX.XXX)...
Mon Aug 19 12:21:36 2024 : IPSec connection started
Mon Aug 19 12:21:36 2024 : IPSec phase 1 client started
Mon Aug 19 12:21:36 2024 : IPSec phase 1 server replied
Mon Aug 19 12:21:37 2024 : IPSec phase 2 started
Mon Aug 19 12:21:37 2024 : IPSec phase 2 established
Mon Aug 19 12:21:37 2024 : IPSec connection established
Mon Aug 19 12:21:37 2024 : L2TP sent SCCRQ
Mon Aug 19 12:21:57 2024 : L2TP cannot connect to the server

:( CNX Timeout

I could not receive L2TP SCCRP message :frowning:

Working:

here is ppp logs of working L2TP tunnel thru tethering on iphone7 4G or adsl eth1 WAN thru GL X3000
---
Mon Aug 19 12:20:30 2024 : l2tp_get_router_address
Mon Aug 19 12:20:30 2024 : l2tp_get_router_address 192.168.1.1 from dict 1
Mon Aug 19 12:20:30 2024 : L2TP connecting to server '185.XXX.XXX.XXX' (185.XXX.XXX.XXX)...
Mon Aug 19 12:20:30 2024 : IPSec connection started
Mon Aug 19 12:20:30 2024 : IPSec phase 1 client started
Mon Aug 19 12:20:30 2024 : IPSec phase 1 server replied
Mon Aug 19 12:20:31 2024 : IPSec phase 2 started
Mon Aug 19 12:20:31 2024 : IPSec phase 2 established
Mon Aug 19 12:20:31 2024 : IPSec connection established
Mon Aug 19 12:20:31 2024 : L2TP sent SCCRQ
Mon Aug 19 12:20:32 2024 : L2TP received SCCRP
Mon Aug 19 12:20:32 2024 : L2TP sent SCCCN
Mon Aug 19 12:20:32 2024 : L2TP sent ICRQ
Mon Aug 19 12:20:32 2024 : L2TP received ICRP
Mon Aug 19 12:20:32 2024 : L2TP sent ICCN
Mon Aug 19 12:20:32 2024 : L2TP connection established.
Mon Aug 19 12:20:32 2024 : L2TP set port-mapping for en10, interface: 25, protocol: 0, privatePort: 0
Mon Aug 19 12:20:32 2024 : using link 0
Mon Aug 19 12:20:32 2024 : Using interface ppp0
Mon Aug 19 12:20:32 2024 : Connect: ppp0 <--> socket[34:18]
Mon Aug 19 12:20:32 2024 : sent [LCP ConfReq id=0x1 <asyncmap 0x0> <magic 0x343fa56d> <pcomp> <accomp>]
Mon Aug 19 12:20:32 2024 : rcvd [LCP ConfReq id=0x1 <auth chap MS-v2> <mru 1450> <magic 0x23f92544>]
Mon Aug 19 12:20:32 2024 : lcp_reqci: returning CONFACK.
Mon Aug 19 12:20:32 2024 : sent [LCP ConfAck id=0x1 <auth chap MS-v2> <mru 1450> <magic 0x23f92544>]
Mon Aug 19 12:20:32 2024 : rcvd [LCP ConfRej id=0x1 <asyncmap 0x0> <pcomp> <accomp>]
Mon Aug 19 12:20:32 2024 : sent [LCP ConfReq id=0x2 <magic 0x343fa56d>]
Mon Aug 19 12:20:32 2024 : rcvd [LCP ConfAck id=0x2 <magic 0x343fa56d>]
Mon Aug 19 12:20:32 2024 : sent [LCP EchoReq id=0x0 magic=0x343fa56d]
Mon Aug 19 12:20:32 2024 : rcvd [CHAP Challenge id=0x1 <dec60fd96e2491ff1be81ba5ceaed02a>, name = "MikroTik"]
Mon Aug 19 12:20:32 2024 : sent [CHAP Response id=0x1 <e361f5c40143204dc92d590b36996b97000000000000000013227f01ad6efdf8e9db57e0379f190aa6975f8568e5320e00>, name = "XXXX.ZZZZ"]
Mon Aug 19 12:20:32 2024 : rcvd [LCP EchoRep id=0x0 magic=0x23f92544]
Mon Aug 19 12:20:32 2024 : rcvd [CHAP Success id=0x1 "S=FE0C02F1A59FC90CB767BED9AE396E1EFBB4FFC2"]
Mon Aug 19 12:20:32 2024 : sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>]
Mon Aug 19 12:20:32 2024 : sent [IPV6CP ConfReq id=0x1 <addr fe80::6e7e:67ff:feb8:cd05>]
Mon Aug 19 12:20:32 2024 : sent [ACSCP ConfReq id=0x1 <route vers 16777216> <domain vers 16777216>]
Mon Aug 19 12:20:32 2024 : rcvd [IPCP ConfReq id=0x1 <addr 192.168.145.1>]
Mon Aug 19 12:20:32 2024 : ipcp: returning Configure-ACK
Mon Aug 19 12:20:32 2024 : sent [IPCP ConfAck id=0x1 <addr 192.168.145.1>]
Mon Aug 19 12:20:32 2024 : rcvd [IPCP ConfNak id=0x1 <addr 172.XXX.XXX.231> <ms-dns1 8.8.8.8> <ms-dns3 8.8.4.4>]
Mon Aug 19 12:20:32 2024 : sent [IPCP ConfReq id=0x2 <addr 172.XXX.XXX.231> <ms-dns1 8.8.8.8> <ms-dns3 8.8.4.4>]
Mon Aug 19 12:20:32 2024 : rcvd [LCP ProtRej id=0x2 80 57 01 01 00 0e 01 0a 6e 7e 67 ff fe b8 cd 05]
Mon Aug 19 12:20:32 2024 : rcvd [LCP ProtRej id=0x3 82 35 01 01 00 10 01 06 00 00 00 01 02 06 00 00 00 01]
Mon Aug 19 12:20:32 2024 : rcvd [IPCP ConfAck id=0x2 <addr 172.XXX.XXX.231> <ms-dns1 8.8.8.8> <ms-dns3 8.8.4.4>]
Mon Aug 19 12:20:32 2024 : ipcp: up
Mon Aug 19 12:20:32 2024 : local  IP address 172.XXX.XXX.231
Mon Aug 19 12:20:32 2024 : remote IP address 192.168.145.1
Mon Aug 19 12:20:32 2024 : primary   DNS address 8.8.8.8
Mon Aug 19 12:20:32 2024 : secondary DNS address 8.8.4.4
Mon Aug 19 12:20:32 2024 : Received protocol dictionaries
Mon Aug 19 12:20:32 2024 : sent [IP data <src addr 172.XXX.XXX.231> <dst addr 255.255.255.255> <BOOTP Request> <type INFORM> <client id 0x08000000010000> <parameters = 0x6 0x2c 0x2b 0x1 0xf9 0xf>]
Mon Aug 19 12:20:32 2024 : Received acsp/dhcp dictionaries
Mon Aug 19 12:20:32 2024 : Received acsp/dhcp dictionaries
Mon Aug 19 12:20:32 2024 : l2tp_wait_input: Address added. previous interface setting (name: en10, address: 192.168.1.160), current interface setting (name: ppp0, family: PPP, address: 172.XXX.XXX.231, subnet: 255.255.0.0, destination: 192.168.145.1).
Mon Aug 19 12:20:32 2024 : Committed PPP store on install command
Mon Aug 19 12:20:35 2024 : sent [IP data <src addr 172.XXX.XXX.231> <dst addr 255.255.255.255> <BOOTP Request> <type INFORM> <client id 0x08000000010000> <parameters = 0x6 0x2c 0x2b 0x1 0xf9 0xf>]
Mon Aug 19 12:20:35 2024 : L2TP port-mapping for en10, interfaceIndex: 0, Protocol: None, Private Port: 0, Public Address: 0, Public Port: 0, TTL: 0.
Mon Aug 19 12:20:35 2024 : L2TP port-mapping for en10 inconsistent. is Connected: 1, Previous interface: 25, Current interface 0
Mon Aug 19 12:20:36 2024 : Committed PPP store on install command
---
\o/ L2TP tunnel connected and working

About IPv6 i thing i misspelled that i cannot spot (not stop!) any ipv6 on 5G NSA.
So i think i have no need to disable IPv6 on my GL X3000 router.
But just noticed that i receive an IPV6 on my iphone on 4G which doesnt on cellular 5G on the GL X3000 (but i think this is an other story)

Which is weird is that the same Sim Card has a different behavior in my iphone7 4G (VPN working) versus in my GL X3000 Cellular 5G NSA (VPN not working)

Could it be your ISP blocking IPsec traffic?!

A quick Google search show that there might be some discrepancies between openwrt and Apple. Try to modify the settings on your macOS and retest.

Can you try Apple Configurator ?

Check out this:
https://discussions.apple.com/thread/255281282

Your link refer to an old version of sonoma 4.1.X

I'm in 14.5 and did not face any IPsec problem with my macOS configuration
Connecting to my Strongswan VPN at work and others IPSec L2TP

If Sonoma is the problem, i have other machines that i can use to make the test.
I will make the test ASAP to dissipate this doubt :wink:

Could the ISP (same sim card) authorize IPSEC VPN via 4G but not via 5G (seems weird) ?
How can i enforce a CNX of the GL X3000 to a 4G carrier ( With some of your guru AT command incantation :wink: ) ?

Ok @SpitzAX3000
just tested with another client OS BigSur 11.7.10

Same problem

Mon Aug 19 17:59:02 2024 : l2tp_get_router_address 192.168.1.1 from dict 1
Mon Aug 19 17:59:03 2024 : L2TP connecting to server '185.XXX.XXX.XXX' (185.XXX.XXX.XXX)...
Mon Aug 19 17:59:03 2024 : IPSec connection started
Mon Aug 19 17:59:03 2024 : IPSec phase 1 client started
Mon Aug 19 17:59:03 2024 : IPSec phase 1 server replied
Mon Aug 19 17:59:04 2024 : IPSec phase 2 started
Mon Aug 19 17:59:04 2024 : IPSec phase 2 established
Mon Aug 19 17:59:04 2024 : IPSec connection established
Mon Aug 19 17:59:04 2024 : L2TP sent SCCRQ
Mon Aug 19 17:59:24 2024 : L2TP cannot connect to the server

If you look closely IPSec connection is established, but i did not receive L2TP SCCRP
which is usually on port UDP 1701.

That why, i previously opened Inbound CNX from Wan to LAN on this UDP port via Luci
But i did not make any difference.

Here is the 2 rules i've added just in case

For your information, the problem is L2TP specific.
I can connect an IPSEC/IkeV2 tunnel thru the GL X3000 to a Strongswan VPN server.

Why do you have port 5500? I believe it should be 4500:

/etc/config/firewall

config 'rule'
option 'target' 'ACCEPT'
option 'src' 'wan'
option '_name' 'ip_50_ESP'
option 'proto' '50'

config 'rule'
option 'target' 'ACCEPT'
option '_name' 'IP_51_AH'
option 'src' 'wan'
option 'proto' '51'

config 'rule'
option 'target' 'ACCEPT'
option '_name' 'IKE'
option 'src' 'wan'
option 'proto' 'udp'
option 'dest_port' '500'

config 'rule'
option 'target' 'ACCEPT'
option '_name' 'ipsec_NAT-T'
option 'src' 'wan'
option 'proto' 'udp'
option 'dest_port' '4500'

You don’t need AT commands; just update the modem firmware to the latest and then you can do it through GLinet web interface band white listing

Yes for sure i have the Port 4500 as this is the default UDP-Encap for ESP

Firmware is up-to-date
V 4.0 / 0409release3
OpenWrt 21.02-SNAPSHOT r15812+880-46b6ee7ffc
Kernel 5.4.211

I'm not sure how i can do band white listing.
Did you mean something in the 'lock tower' feature ?

for now i get this via the interface

But I see 5500 on your screenshot only ?

No. It’s called band masking… like this:

About the UDP Port 4500 the rule is above my screenshot (sorry)
Added with IKE in a precedent rule.
Thank you for pointing out this unused rule, now deleted :slight_smile:

Unfortunately it seems that i do not have the feature to do band white listing
SIM

Or i m looking at the wrong place...

My rational is that the problem don't came from a firewall misconfiguration as far as the VPN work with ethernet and tethering (WAN). Only Cellular doesnt work properly.

But anyway, here is the related firewall rules.

ESP definition is slightly different than yours but this should work as esp definition is correct in /etc/protocols :
esp 50 IPSEC-ESP # Encap Security Payload [RFC2046]

config rule
	option name 'Allow-IPSec-ESP'
	option src 'wan'
	option dest 'lan'
	option proto 'esp'
	option target 'ACCEPT'

config rule
	option name 'Allow-ISAKMP'
	option src 'wan'
	option dest 'lan'
	option dest_port '500'
	option proto 'udp'
	option target 'ACCEPT'

config rule
	option dest_port '1701'
	option src 'wan'
	option name 'Allow-L2TP'
	option dest 'lan'
	option target 'ACCEPT'
	list proto 'udp'

config rule
	option src 'wan'
	option name 'Allow-IPSEC NAT-T'
	option dest 'lan'
	option target 'ACCEPT'
	list proto 'udp'
	option dest_port '4500'
1 Like

Found the band white listing in the manual configuration of the sim.
Thank you for pointing me in the right direction @SpitzAX3000

I will try to lock the cellular to 4G and establish the vpn tunnel in 4G LTE if i can.

And make some tcpdump also on the router to try determine where the packet is lost.
But for now i suspect that the ipsec tunnel is not holding well and prevent the L2TP negociation inside the tunnel. I guess also that i don't need the port 1701 as this communication is encapsulated.

Ok i was pretty sure that the result would be the same in 4G.
indeed ! The tunnel is not working in 4G LTE.

Let's recap (head scratching):
the tunnel is working with ADSL Wan and Iphone 4G tethering via the GL X3000
but it fails on the Cellular interface.
Just to be sure i have lowered the MTU to 1200 as L2TP tend to encapsulate a lot.

I did some tcpdump to get some insight and notice some communication from the LNS (VPN Server) isakmp-nat-keep-alive; 2 times before the timeout of the ipsec tunnel.

It seems that something cut the communication from the VPN Server on port 4500 on the cellular interface but it's not the case with the ethernet interface or tethering interface.

Not Working tcpdump taken on laptop when initiating the VPN CNX via the Cellular interface on GL X3000:

shupo:~ hugh$ cat cnx_trace_notworking
22:45:01.394661 IP 192.168.1.123.500 > 185.XXX.XXX.XXX.500: isakmp: phase 1 I ident
22:45:01.505930 IP 185.XXX.XXX.XXX.500 > 192.168.1.123.500: isakmp: phase 1 R ident
22:45:01.508387 IP 192.168.1.123.500 > 185.XXX.XXX.XXX.500: isakmp: phase 1 I ident
22:45:01.606746 IP 185.XXX.XXX.XXX.500 > 192.168.1.123.500: isakmp: phase 1 R ident
22:45:01.631179 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: NONESP-encap: isakmp: phase 1 I ident[E]
22:45:01.715804 IP 185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: NONESP-encap: isakmp: phase 1 R ident[E]
22:45:02.451962 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
22:45:02.560936 IP 185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: NONESP-encap: isakmp: phase 2/others R oakley-quick[E]
22:45:02.561593 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
22:45:02.562701 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x0393ca18,seq=0x1), length 116
22:45:03.098957 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x0393ca18,seq=0x2), length 116
22:45:05.102448 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x0393ca18,seq=0x3), length 116
22:45:06.210449 IP 185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: isakmp-nat-keep-alive
22:45:09.110598 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x0393ca18,seq=0x4), length 116
22:45:13.118021 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x0393ca18,seq=0x5), length 116
22:45:17.126207 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x0393ca18,seq=0x6), length 116
22:45:21.134023 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x0393ca18,seq=0x7), length 116
22:45:22.360676 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: isakmp-nat-keep-alive
22:45:22.575494 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: NONESP-encap: isakmp: phase 2/others I inf[E]
22:45:22.575616 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: NONESP-encap: isakmp: phase 2/others I inf[E]

Working taken on laptop when initiating the VPN CNX via the ethernet ADSL interface on GL X3000

shupo:~ hugh$ cat cnx_trace_working_lan
23:08:42.789714 IP 192.168.1.123.500 > 185.XXX.XXX.XXX.500: isakmp: phase 1 I ident
23:08:42.846569 IP 185.XXX.XXX.XXX.500 > 192.168.1.123.500: isakmp: phase 1 R ident
23:08:42.849892 IP 192.168.1.123.500 > 185.XXX.XXX.XXX.500: isakmp: phase 1 I ident
23:08:42.926962 IP 185.XXX.XXX.XXX.500 > 192.168.1.123.500: isakmp: phase 1 R ident
23:08:42.952430 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: NONESP-encap: isakmp: phase 1 I ident[E]
23:08:43.004557 IP 185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: NONESP-encap: isakmp: phase 1 R ident[E]
23:08:43.856467 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
23:08:43.914228 IP 185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: NONESP-encap: isakmp: phase 2/others R oakley-quick[E]
23:08:43.914828 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: NONESP-encap: isakmp: phase 2/others I oakley-quick[E]
23:08:43.915734 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x04a6e7fc,seq=0x1), length 116
23:08:43.968425 IP 185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: UDP-encap: ESP(spi=0x0797f2fc,seq=0x1), length 140
23:08:43.969201 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x04a6e7fc,seq=0x2), length 60
23:08:43.969336 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x04a6e7fc,seq=0x3), length 76
23:08:44.024388 IP 185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: UDP-encap: ESP(spi=0x0797f2fc,seq=0x2), length 52
23:08:44.024391 IP 185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: UDP-encap: ESP(spi=0x0797f2fc,seq=0x3), length 68
23:08:44.025022 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x04a6e7fc,seq=0x4), length 84
23:08:44.031808 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x04a6e7fc,seq=0x5), length 76
23:08:44.076677 IP 185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: UDP-encap: ESP(spi=0x0797f2fc,seq=0x4), length 52
23:08:44.086115 IP 185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: UDP-encap: ESP(spi=0x0797f2fc,seq=0x5), length 68
23:08:44.086118 IP 185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: UDP-encap: ESP(spi=0x0797f2fc,seq=0x6), length 68
23:08:44.086886 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x04a6e7fc,seq=0x6), length 76
23:08:44.086892 IP 192.168.1.123.4500 > 185.XXX.XXX.XXX.4500: UDP-encap: ESP(spi=0x04a6e7fc,seq=0x7), length 60
23:08:44.138721 IP 185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: UDP-encap: ESP(spi=0x0797f2fc,seq=0x7), length 60
23:08:44.138724 IP 185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: UDP-encap: ESP(spi=0x0797f2fc,seq=0x8), length 84

It's seems we miss something somewhere in the luci interface configuration ?

hum...

Maybe i spot something on luci which maybe explain why the inbound for UDP 4500 did not apply to the cellular interface, but i'm not sure how to fix it effectively ?

The modem_0001_4 interface is not zone assigned
is this normal ?
I was expecting WAN there.

The inbound UDP 4500 rule is configured to accept cnx.

but on the cellular interface i never see
185.XXX.XXX.XXX.4500 > 192.168.1.123.4500: UDP-encap
traffic coming from the vpn server and wonder why ?

Yes it’s normal.

Can you explain more ? What did you spot and how did you know it’s not being applied at the cellular interface ?

I think you have changed too many settings. Is it possible to reset the modem to default then capture tcpdump while connecting?