WiFi Calling and IPsec ESP on Openwrt 24.10.4

Installing and Using OpenWrt
1

Hi all,

I have two different routers that present the same issue. Android phones (don’t have iphones to test) do not have WiFi calling.

During testing, dns resolution works fine, but during a tcpdump I see that the init packets never receive a reply. This works on other routers.

Standard StrongSwan/IPsec2 connections work and receive full replies:

17:44:19.884799 IP MyPublicIP.42605 > 31.94.76.10.500: isakmp: parent_sa ikev2_init[I]
17:44:23.885607 IP MyPublicIP.42605 > 31.94.76.10.500: isakmp: parent_sa ikev2_init[I]
17:44:27.888562 IP MyPublicIP.52932 > 31.94.76.9.500: isakmp: parent_sa ikev2_init[I]
17:44:28.887843 IP MyPublicIP.52932 > 31.94.76.9.500: isakmp: parent_sa ikev2_init[I]

The same happens with the other sim as well (different target IP).

Any idea? I see that other routers have nf_conntrack_proto_esp, but this seems not available on mainline linux and openwrt. What am I missing here? Why do not I see reply packets, even with wan logging on?

I see other packets being dropped there:

Thu Jan 15 20:08:09 2026 kern.warn kernel: [ 7159.102578] reject wan in: IN=wan OUT= MAC=ec:fc:2f:7f:ef:e7:88:90:09:83:30:33:08:00 SRC=79.124.49.10 DST=MyPublicIP LEN=40 TOS=0x00 PREC=0x00 TTL=241 ID=43501 PROTO=TCP SPT=41761 DPT=9232 WINDOW=1200 RES=0x00 RST URGP=0
Thu Jan 15 20:08:15 2026 kern.warn kernel: [ 7164.664695] reject wan in: IN=wan OUT= MAC=ec:fc:2f:7f:ef:e7:88:90:09:83:30:33:08:00 SRC=79.124.49.10 DST=MyPublicIP LEN=40 TOS=0x00 PREC=0x00 TTL=241 ID=43500 PROTO=TCP SPT=41761 DPT=9232 WINDOW=1024 RES=0x00 SYN URGP=0
Thu Jan 15 20:08:15 2026 kern.warn kernel: [ 7164.737255] reject wan in: IN=wan OUT= MAC=ec:fc:2f:7f:ef:e7:88:90:09:83:30:33:08:00 SRC=79.124.49.10 DST=MyPublicIP LEN=40 TOS=0x00 PREC=0x00 TTL=241 ID=43501 PROTO=TCP SPT=41761 DPT=9232 WINDOW=1200 RES=0x00 RST URGP=0

But no packets with port 500/4500

root@OpenWrt:~# logread|grep "PT=500 "
root@OpenWrt:~# logread|grep "PT=4500 "
root@OpenWrt:~#
2

How that is related to wifi call? Traffic does not originate from LAN....

Try to run conntrack -E -s <your phones IP> while trying to call.... That will give some idea on what to actually capture.

3

I install kmod-nf-nathelper-extra to fix this and to make my work's pptp VPN work.

2 Likes
4

the packets being dropped are not related. It is to show that I don’t see packets from/to port 500/4500 being dropped.

root@OpenWrt:~# conntrack -E -s 192.168.0.232    [NEW] udp      17 60 src=192.168.0.232 dst=91.81.133.32 sport=51120 dport=500 [UNREPLIED] src=91.81.133.32 dst=87.192.96.14 sport=500 dport=51120     [NEW] udp      17 60 src=192.168.0.232 dst=31.94.76.2 sport=45515 dport=500 [UNREPLIED] src=31.94.76.2 dst=87.192.96.14 sport=500 dport=45515     [NEW] tcp      6 120 SYN_SENT src=192.168.0.232 dst=23.192.24.69 sport=35056 dport=80 [UNREPLIED] src=23.192.24.69 dst=87.192.96.14 sport=80 dport=35056  [UPDATE] tcp      6 60 SYN_RECV src=192.168.0.232 dst=23.192.24.69 sport=35056 dport=80 src=23.192.24.69 dst=87.192.96.14 sport=80 dport=35056  [UPDATE] tcp      6 7440 ESTABLISHED src=192.168.0.232 dst=23.192.24.69 sport=35056 dport=80 src=23.192.24.69 dst=87.192.96.14 sport=80 dport=35056 [ASSURED]

[…]

I’ve installed it and rebooted. Is there any configuration required? I don’t see any difference in tcpdump

5

setup

restart firewall or device

Pardon me who told you it is port 500 or 4500? My phone network uses 443/udp for ike

6

I was going with 500/4500 as that's the default for ike, and I see the phone is trying to initiate the connection to port 500 (see tcpdump).

I was also comparing with adb shell logcat|grep ims, but I can't see any reference to spexific ports, just to ikev2 connections failing because of no reply.

7

Please get a bit more structured with your diagnostics, thank you.

8

No configuration is required, the helper just works with allowing the NAT registration back to the handset that established the WiFi call.

9

I’m confused. Which information have I not given?
Anyway, I have found those ports on various sources https://community.ee.co.uk/t5/Broadband-Landline/Firewall-Ip-addresses-and-Ports-for-Wifi-Calling/td-p/1017090

https://community.o2.co.uk/t5/Other-Products-and-Services/Wifi-Calling/td-p/1220417

https://www.t-mobile.com/support/coverage/wi-fi-calling-on-a-corporate-network

https://extreme-networks.my.site.com/ExtrArticleDetail?an=000099268

Unfortunately that didn’t do it… I have tried rebooting, restarting firewalls, disabling sqm and hardware/software offloading, but no difference. Those packets do not receive a reply

10

Are you able to log conntrack events?

11

So the issue is happening on both Asus routers?
Which mobile network and how strong is your mobile signal?

12

Here they are (filtered as otherwise there is a lot of junk):

root@OpenWrt:~# conntrack -E -s 192.168.0.232 |grep 500
    [NEW] udp      17 60 src=192.168.0.232 dst=91.81.133.33 sport=57560 dport=4500 [UNREPLIED] src=91.81.133.33 dst=MyPublicIP sport=4500 dport=57560
    [NEW] udp      17 60 src=192.168.0.232 dst=91.81.133.32 sport=34960 dport=500 [UNREPLIED] src=91.81.133.32 dst=MyPublicIP sport=500 dport=34960
    [NEW] udp      17 60 src=192.168.0.232 dst=31.94.76.9 sport=44751 dport=500 [UNREPLIED] src=31.94.76.9 dst=MyPublicIP sport=500 dport=44751
    [NEW] udp      17 60 src=192.168.0.232 dst=31.94.76.5 sport=54941 dport=500 [UNREPLIED] src=31.94.76.5 dst=MyPublicIP sport=500 dport=54941
    [NEW] udp      17 60 src=192.168.0.232 dst=31.94.76.10 sport=47732 dport=500 [UNREPLIED] src=31.94.76.10 dst=MyPublicIP sport=500 dport=47732
    [NEW] udp      17 60 src=192.168.0.232 dst=31.94.76.1 sport=55055 dport=500 [UNREPLIED] src=31.94.76.1 dst=MyPublicIP sport=500 dport=55055
    [NEW] udp      17 60 src=192.168.0.232 dst=31.94.76.2 sport=40053 dport=500 [UNREPLIED] src=31.94.76.2 dst=MyPublicIP sport=500 dport=40053
    [NEW] udp      17 60 src=192.168.0.232 dst=91.81.133.32 sport=47231 dport=500 [UNREPLIED] src=91.81.133.32 dst=MyPublicIP sport=500 dport=47231

tcpdump -i br-lan port 500 or port 4500 or proto 50 or port 143
17:09:10.739063 IP 192.168.0.232.55055 > 31.94.76.1.500: isakmp: parent_sa ikev2_init[I]
17:09:11.739827 IP 192.168.0.232.55055 > 31.94.76.1.500: isakmp: parent_sa ikev2_init[I]
17:09:13.739974 IP 192.168.0.232.55055 > 31.94.76.1.500: isakmp: parent_sa ikev2_init[I]
17:09:17.739028 IP 192.168.0.232.55055 > 31.94.76.1.500: isakmp: parent_sa ikev2_init[I]
17:09:20.853651 IP 192.168.0.232.40053 > 31.94.76.2.500: isakmp: parent_sa ikev2_init[I]
17:09:21.854377 IP 192.168.0.232.40053 > 31.94.76.2.500: isakmp: parent_sa ikev2_init[I]
17:09:23.859865 IP 192.168.0.232.40053 > 31.94.76.2.500: isakmp: parent_sa ikev2_init[I]
17:09:27.857572 IP 192.168.0.232.40053 > 31.94.76.2.500: isakmp: parent_sa ikev2_init[I]
17:09:44.829282 IP 192.168.0.232.47231 > 91.81.133.32.500: isakmp: parent_sa ikev2_init[I]
17:09:45.846765 IP 192.168.0.232.47231 > 91.81.133.32.500: isakmp: parent_sa ikev2_init[I]
17:09:47.848754 IP 192.168.0.232.47231 > 91.81.133.32.500: isakmp: parent_sa ikev2_init[I]
17:09:51.852256 IP 192.168.0.232.47231 > 91.81.133.32.500: isakmp: parent_sa ikev2_init[I]
17:09:54.997914 IP 192.168.0.232.55336 > 91.81.133.33.500: isakmp: parent_sa ikev2_init[I]
17:09:56.078160 IP 192.168.0.232.55336 > 91.81.133.33.500: isakmp: parent_sa ikev2_init[I]
17:09:58.007242 IP 192.168.0.232.55336 > 91.81.133.33.500: isakmp: parent_sa ikev2_init[I]
17:10:02.000928 IP 192.168.0.232.55336 > 91.81.133.33.500: isakmp: parent_sa ikev2_init[I]

tcpdump -i wan port 500 or port 4500 or proto 50 or port 143
17:08:53.444118 IP MyPublicIP.54941 > 31.94.76.5.500: isakmp: parent_sa ikev2_init[I]
17:08:57.440326 IP MyPublicIP.54941 > 31.94.76.5.500: isakmp: parent_sa ikev2_init[I]
17:09:00.587513 IP MyPublicIP.47732 > 31.94.76.10.500: isakmp: parent_sa ikev2_init[I]
17:09:01.158809 IP sh-chi-us-gp6-wk124b.internet-census.org.34859 > MyPublicIP.143: Flags [S], seq 1336773668, win 1024, length 0
17:09:01.178926 IP MyPublicIP.143 > sh-chi-us-gp6-wk124b.internet-census.org.34859: Flags [R.], seq 0, ack 1336773669, win 0, length 0
17:09:01.280225 IP sh-chi-us-gp6-wk124b.internet-census.org.34859 > MyPublicIP.143: Flags [R], seq 1336773669, win 1200, length 0
17:09:01.584879 IP MyPublicIP.47732 > 31.94.76.10.500: isakmp: parent_sa ikev2_init[I]
17:09:03.587088 IP MyPublicIP.47732 > 31.94.76.10.500: isakmp: parent_sa ikev2_init[I]
17:09:07.592070 IP MyPublicIP.47732 > 31.94.76.10.500: isakmp: parent_sa ikev2_init[I]
17:09:10.739213 IP MyPublicIP.55055 > 31.94.76.1.500: isakmp: parent_sa ikev2_init[I]
17:09:11.739958 IP MyPublicIP.55055 > 31.94.76.1.500: isakmp: parent_sa ikev2_init[I]
17:09:13.740095 IP MyPublicIP.55055 > 31.94.76.1.500: isakmp: parent_sa ikev2_init[I]
17:09:17.739105 IP MyPublicIP.55055 > 31.94.76.1.500: isakmp: parent_sa ikev2_init[I]
17:09:20.853824 IP MyPublicIP.40053 > 31.94.76.2.500: isakmp: parent_sa ikev2_init[I]
17:09:21.854499 IP MyPublicIP.40053 > 31.94.76.2.500: isakmp: parent_sa ikev2_init[I]
17:09:23.859989 IP MyPublicIP.40053 > 31.94.76.2.500: isakmp: parent_sa ikev2_init[I]
17:09:27.857685 IP MyPublicIP.40053 > 31.94.76.2.500: isakmp: parent_sa ikev2_init[I]
17:09:44.829407 IP MyPublicIP.47231 > 91.81.133.32.500: isakmp: parent_sa ikev2_init[I]
17:09:45.846878 IP MyPublicIP.47231 > 91.81.133.32.500: isakmp: parent_sa ikev2_init[I]
17:09:47.848859 IP MyPublicIP.47231 > 91.81.133.32.500: isakmp: parent_sa ikev2_init[I]
17:09:51.852362 IP MyPublicIP.47231 > 91.81.133.32.500: isakmp: parent_sa ikev2_init[I]
17:09:54.998083 IP MyPublicIP.55336 > 91.81.133.33.500: isakmp: parent_sa ikev2_init[I]
17:09:56.078279 IP MyPublicIP.55336 > 91.81.133.33.500: isakmp: parent_sa ikev2_init[I]
17:09:58.007301 IP MyPublicIP.55336 > 91.81.133.33.500: isakmp: parent_sa ikev2_init[I]
17:10:02.001052 IP MyPublicIP.55336 > 91.81.133.33.500: isakmp: parent_sa ikev2_init[I]

The internet-census.org are connection after I use censys.com, the network whois/analysis tool

I hope this is clear enough

Cheers

1 Like
13

So it is restricted to "standard" plain IPSEC without NAT-T)src 500 dst 500), that is works only on operators own mobile network without nat. Or using ipv6

1 Like
14

Oh, nice to know. How should I sort this out then? Any suggestion?

I also have ipv6 on the router, but the phone wifi calling stack doesn't seem to be using it

15

I’m not sure that’s case? It seems that its not getting a response to the initial IKE init and so isnt even getting as far as establishing whether NAT-T is supported. From the tcpcump of the wan interface , theres no response from the remote end to the ikev2-init

@effeffe you say it works with another router ? is that on your internet connection or a different one ?

Android Wifi calling works fine via my Openwrt router, although it is 24.10.2 but I wouldnt expect that to make a difference.

who is your ISP ? is there any chance they may be blocking some ports ?

16

Yes, remote endpoint drops the packet, expecting "transport" ipsec where ike sources from port 500.
What keeps local port 500 busy? Default should map original source port 500 to public IP.

17

Running conntrack -E -s 192.168.5.189 | grep 500, this

    [NEW] udp      17 60 src=192.168.5.189 dst=88.82.11.221 sport=48506 dport=500 [UNREPLIED] src=88.82.11.221 dst=<my public ip> sport=500 dport=48506
 [UPDATE] udp      17 86400 src=192.168.5.189 dst=88.82.11.221 sport=48506 dport=500 src=88.82.11.221 dst=<my public ip> sport=500 dport=48506 [OFFLOAD]
    [NEW] udp      17 60 src=192.168.5.189 dst=88.82.11.221 sport=60749 dport=4500 [UNREPLIED] src=88.82.11.221 dst=<my public ip> sport=4500 dport=60749
 [UPDATE] udp      17 86400 src=192.168.5.189 dst=88.82.11.221 sport=60749 dport=4500 src=88.82.11.221 dst=<my public ip> sport=4500 dport=60749 [OFFLOAD]
    [NEW] udp      17 60 src=192.168.5.189 dst=87.194.8.8 sport=54752 dport=500 [UNREPLIED] src=87.194.8.8 dst=<my public ip> sport=500 dport=54752
 [UPDATE] udp      17 86400 src=192.168.5.189 dst=87.194.8.8 sport=54752 dport=500 src=87.194.8.8 dst=<my public ip> sport=500 dport=54752 [OFFLOAD]
    [NEW] udp      17 60 src=192.168.5.189 dst=87.194.8.8 sport=44167 dport=4500 [UNREPLIED] src=87.194.8.8 dst=<my public ip> sport=4500 dport=44167
 [UPDATE] udp      17 86400 src=192.168.5.189 dst=87.194.8.8 sport=44167 dport=4500 src=87.194.8.8 dst=<my public ip> sport=4500 dport=44167 [OFFLOAD]
    [NEW] udp      17 60 src=192.168.5.189 dst=148.252.188.96 sport=39146 dport=500 [UNREPLIED] src=148.252.188.96 dst=<my public ip> sport=500 dport=39146
 [UPDATE] udp      17 86400 src=192.168.5.189 dst=148.252.188.96 sport=39146 dport=500 src=148.252.188.96 dst=<my public ip> sport=500 dport=39146 [OFFLOAD]
    [NEW] udp      17 60 src=192.168.5.189 dst=148.252.188.96 sport=47682 dport=4500 [UNREPLIED] src=148.252.188.96 dst=<my public ip> sport=4500 dport=47682
 [UPDATE] udp      17 86400 src=192.168.5.189 dst=148.252.188.96 sport=47682 dport=4500 src=148.252.188.96 dst=<my public ip> sport=4500 dport=47682 [OFFLOAD]
...
[DESTROY] udp      17 src=192.168.5.189 dst=88.82.11.221 sport=48506 dport=500 packets=1 bytes=364 src=88.82.11.221 dst=<my public ip> sport=500 dport=48506 packets=1 bytes=513
[DESTROY] udp      17 src=192.168.5.189 dst=148.252.188.96 sport=39146 dport=500 packets=1 bytes=364 src=148.252.188.96 dst=<my public ip> sport=500 dport=39146 packets=1 bytes=361
[DESTROY] udp      17 src=192.168.5.189 dst=87.194.8.8 sport=54752 dport=500 packets=1 bytes=572 src=87.194.8.8 dst=<my public ip> sport=500 dport=54752 packets=1 bytes=630
[DESTROY] udp      17 src=192.168.5.189 dst=87.194.8.8 sport=44167 dport=4500 packets=35 bytes=22116 src=87.194.8.8 dst=<my public ip> sport=4500 dport=44167 packets=41 bytes=17396
[DESTROY] udp      17 src=192.168.5.189 dst=88.82.11.221 sport=60749 dport=4500 packets=4 bytes=736 src=88.82.11.221 dst=<my public ip> sport=4500 dport=60749 packets=5 bytes=848
[DESTROY] udp      17 src=192.168.5.189 dst=148.252.188.96 sport=47682 dport=4500 packets=17 bytes=7864 src=148.252.188.96 dst=<my public ip> sport=4500 dport=47682 packets=16 bytes=4496

is what I see for a succesfull wifi calling establishment by temporarily switching to airplane mode ( with wifi enabled )

18

Yeah, that is ipsec nat-t where ike and esp are wrapped in udp packets .

19

but isnt the initilal communication done via port 500 to establish that NAT-T is required which then switches the comms to 4500 with ike & esp encapsulated

20

Some go away reply probably.

Btw offload incorrectly counts packets, should be two at least given previous log lines...