VPN not working on Iphone while using Cellular Data
nikich700 opened this issue · 18 comments
I have tested my VPN on 4 phones:
2 Android phones (one on ISP-a, other on ISP-b).
2 Iphones (one on ISP-a, other on ISP-b).
Both Android phones connect to VPN flawlessly no matter connection type (WiFi or Cellular).
Both Iphones are able to connect to VPN only through WiFi. Trying to connect using Cellular on both ISP-a and ISP-b fails. It just says "connecting..." and after several seconds message pops up: "VPN Connection. The VPN server did not respond."
Checking logs I have seen:
Feb 6 23:36:06 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #1: sent IKE_SA_INIT reply {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
Feb 6 23:36:06 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #1: processing decrypted IKE_AUTH request: SK{IDi,CERT,N(INITIAL_CONTACT),IDr,AUTH,CP,N(ESP_TFC_PADDING_NOT_SUPPORTED),N(NON_FIRST_FRAGMENTS_ALSO),SA,TSi,TSr,N(MOBIKE_SUPPORTED)}
Feb 6 23:36:06 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #1: reloaded private key matching left certificate '91.149.232.132'
Feb 6 23:36:06 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #1: responder established IKE SA; authenticated peer '3072-bit PKCS#1 1.5 RSA with SHA1' signature using peer certificate 'CN=DashaPhone, O=IKEv2 VPN' issued by CA 'CN=IKEv2 VPN CA, O=IKEv2 VPN'
Feb 6 23:36:06 vm776134 pluto[47312]: | pool 192.168.43.10-192.168.43.250: growing address pool from 0 to 1
Feb 6 23:36:07 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #2: proposal 4:ESP=AES_CBC_128-HMAC_SHA1_96-DISABLED SPI=003fe01c chosen from remote proposals 1:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED[first-match] 2:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED 3:ESP:ENCR=AES_CBC_256;INTEG=HMAC_SHA2_256_128;ESN=DISABLED 4:ESP:ENCR=AES_CBC_128;INTEG=HMAC_SHA1_96;ESN=DISABLED[better-match] 5:ESP:ENCR=3DES;INTEG=HMAC_SHA1_96;ESN=DISABLED
Feb 6 23:36:07 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #2: responder established Child SA using #1; IPsec tunnel [0.0.0.0-255.255.255.255:0-65535 0] -> [192.168.43.10-192.168.43.10:0-65535 0] {ESPinUDP=>0x003fe01c <0x27cc2449 xfrm=AES_CBC_128-HMAC_SHA1_96 NATD=5.18.245.31:1459 DPD=active}
Feb 6 23:37:07 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 0.5 seconds for response
Feb 6 23:37:08 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 1 seconds for response
Feb 6 23:37:09 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 2 seconds for response
Feb 6 23:37:11 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 4 seconds for response
Feb 6 23:37:15 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 8 seconds for response
Feb 6 23:37:23 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 16 seconds for response
Feb 6 23:37:39 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 32 seconds for response
Feb 6 23:38:11 vm776134 pluto[47312]: "ikev2-cp"[1] [My IP here] #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 64 seconds for response
Considering that VPN works fine on Android phones on ISP-a and ISP-b, I figured it must be not them blocking traffic but rather something else.
Any suggestions on what I can do to fix this issue?
Thank you in advance.
@nikich700 Hello! The "retransmission" related errors in the logs, which can be seen in your description, is typical for the cases where traffic is blocked by e.g. the GFW. If you see those errors in the logs, I would suggest that you try alternative solutions other than IPsec VPN, such as Shadowsocks.
@hwdsl2 But how is it possible that Android phones on very same Mobile data providers connect to my VPN server just fine while Iphones fail? Wouldn't ISP-side traffic blocking affect all phones, no matter the manufacturer?
Hi! I found similar issue, when connecting from iPhone in cellular networks. When I use WiFi network - its connects without problems, There are also same logs using
tail /var/log/auth.log | grep pluto
Feb 16 10:39:10 ubuntu-US-Miami-1gb-0 pluto[9206]: "ikev2-cp"[1] 95.153.162.12 #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 0.5 seconds for response Feb 16 10:39:10 ubuntu-US-Miami-1gb-0 pluto[9206]: "ikev2-cp"[1] 95.153.162.12 #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 1 seconds for response Feb 16 10:39:10 ubuntu-US-Miami-1gb-0 pluto[9206]: "ikev2-cp"[1] 95.153.162.12 #3: proposal 1:IKE=AES_GCM_C_256-HMAC_SHA2_256-ECP_256 chosen from remote proposals 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_256;DH=ECP_256[first-match] Feb 16 10:39:10 ubuntu-US-Miami-1gb-0 pluto[9206]: "ikev2-cp"[1] 95.153.162.12 #3: sent IKE_SA_INIT reply {cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_256 group=DH19} Feb 16 10:39:11 ubuntu-US-Miami-1gb-0 pluto[9206]: "ikev2-cp"[1] 95.153.162.12 #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 2 seconds for response
using ipsec status:
000 Total IPsec connections: loaded 4, active 1 000 000 State Information: DDoS cookies not required, Accepting new IKE connections 000 IKE SAs: total(2), half-open(1), open(0), authenticated(1), anonymous(0) 000 IPsec SAs: total(1), authenticated(1), anonymous(0) 000 000 #1: "ikev2-cp"[1] 95.153.162.12:28472 STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); RETRANSMIT in 29s; EXPIRE in 86335s; newest; idle; 000 #2: "ikev2-cp"[1] 95.153.162.12:28472 STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); LIVENESS in 25s; EXPIRE in 86335s; newest; eroute owner; IKE SA #1; idle; 000 #2: "ikev2-cp"[1] 95.153.162.12 esp.7f11bc2@95.153.162.12 esp.119d33@MASKEDSERVERIP tun.0@95.153.162.12 tun.0@MASKEDSERVERIP Traffic: ESPin=0B ESPout=0B ESPmax=2^63B 000 #3: "ikev2-cp"[1] 95.153.162.12:58188 STATE_V2_PARENT_R1 (sent IKE_SA_INIT reply); DISCARD in 166s; idle; 000 000 Bare Shunt list: 000
It's also reproduces on StrongSwan server. I connect my iPhone to Mac and look at WireShark, it always reproduced same behavior (for the StronSwan) - IKE_AUTH packets with Initiator Request and Responder Response just go away, not blocked.
Same issue on the server side with WireShark (if need, i can log it and attach).
Looks like cellular network provider (or something other) redirects udp packets to the wrong route and VPN server not get answer from client (and in another direction - server send, but client not get).
Maybe there are exists something additional things, that can say to VPN server or routes - ok, we lost some packets, let's forget and resend again.
P.s.: also try to make iPhone as router and connect laptop to iPhone's cellular network - same issue Windows 11 also with same behaviour like iPhone - same logs on server side.
Hi! I found similar issue, when connecting from iPhone in cellular networks. When I use WiFi network - its connects without problems, There are also same logs using tail /var/log/auth.log | grep pluto
Feb 16 10:39:10 ubuntu-US-Miami-1gb-0 pluto[9206]: "ikev2-cp"[1] 95.153.162.12 #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 0.5 seconds for response Feb 16 10:39:10 ubuntu-US-Miami-1gb-0 pluto[9206]: "ikev2-cp"[1] 95.153.162.12 #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 1 seconds for response Feb 16 10:39:10 ubuntu-US-Miami-1gb-0 pluto[9206]: "ikev2-cp"[1] 95.153.162.12 #3: proposal 1:IKE=AES_GCM_C_256-HMAC_SHA2_256-ECP_256 chosen from remote proposals 1:IKE:ENCR=AES_GCM_C_256;PRF=HMAC_SHA2_256;DH=ECP_256[first-match] Feb 16 10:39:10 ubuntu-US-Miami-1gb-0 pluto[9206]: "ikev2-cp"[1] 95.153.162.12 #3: sent IKE_SA_INIT reply {cipher=AES_GCM_16_256 integ=n/a prf=HMAC_SHA2_256 group=DH19} Feb 16 10:39:11 ubuntu-US-Miami-1gb-0 pluto[9206]: "ikev2-cp"[1] 95.153.162.12 #1: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 2 seconds for responseusing ipsec status:
000 Total IPsec connections: loaded 4, active 1 000 000 State Information: DDoS cookies not required, Accepting new IKE connections 000 IKE SAs: total(2), half-open(1), open(0), authenticated(1), anonymous(0) 000 IPsec SAs: total(1), authenticated(1), anonymous(0) 000 000 #1: "ikev2-cp"[1] 95.153.162.12:28472 STATE_V2_ESTABLISHED_IKE_SA (established IKE SA); RETRANSMIT in 29s; EXPIRE in 86335s; newest; idle; 000 #2: "ikev2-cp"[1] 95.153.162.12:28472 STATE_V2_ESTABLISHED_CHILD_SA (established Child SA); LIVENESS in 25s; EXPIRE in 86335s; newest; eroute owner; IKE SA #1; idle; 000 #2: "ikev2-cp"[1] 95.153.162.12 esp.7f11bc2@95.153.162.12 esp.119d33@MASKEDSERVERIP tun.0@95.153.162.12 tun.0@MASKEDSERVERIP Traffic: ESPin=0B ESPout=0B ESPmax=2^63B 000 #3: "ikev2-cp"[1] 95.153.162.12:58188 STATE_V2_PARENT_R1 (sent IKE_SA_INIT reply); DISCARD in 166s; idle; 000 000 Bare Shunt list: 000It's also reproduces on StrongSwan server. I connect my iPhone to Mac and look at WireShark, it always reproduced same behavior (for the StronSwan) - IKE_AUTH packets with Initiator Request and Responder Response just go away, not blocked. Same issue on the server side with WireShark (if need, i can log it and attach).Looks like cellular network provider (or something other) redirects udp packets to the wrong route and VPN server not get answer from client (and in another direction - server send, but client not get).
Maybe there are exists something additional things, that can say to VPN server or routes - ok, we lost some packets, let's forget and resend again.
P.s.: also try to make iPhone as router and connect laptop to iPhone's cellular network - same issue Windows 11 also with same behaviour like iPhone - same logs on server side.
Here it is - WireShark log on server when connect from iPhone in cellular network:
Only one something strange thing is - ICMP packet goes to strange ip address, not from any server/client subnet, but I think it's doesn't matter in this case
Are the server IP ranges or dns server ip received conflicting with the outer network ?
I don't think so, we try to build VPN server on another VPS server with another Server IP and local subnet - same behaviour.
It's very strange for us too - some packets came and some not. Yes, I'am forgot mension about another case at another server builded on Strongswan - when we work at WiFi and switch it off to LTE - VPN connection still works. So the problem is in ike auth stage, it's just breaks and we don't know why.
Also we try to change MTU size - it's also not helping, just change fragmentation size at all
I am experiencing the same issue too. The weird thing is that it works sometimes and then it will stop working and after a while it will start working again...
On Tue, 20 Feb 2024, Jiasong Huang wrote: I am experiencing the same issue too. The weird thing is that it works sometimes and then it will stop working and after a while it will start working again...
Be aware that some suppressive regimes do not block things, but make it annoyingly bad but sort of working a little, so that you don't try ohter solutions but just give up and blame bad technology. I am not saying that is happening here, but it is a possibility. Another item could be that NAT or CGNAT are timing things out or are just broken. Paul
I live in the U.S. and am using AT&T as my mobile provider. So I don't think it is a suppressive regime lol(hopefully)
@hwdsl2 Hi. I've been using your solution for a long time and after recently changing my VPS server I started deploying the image again and ran into the same problems as in this thread. Previously (Nov 2023 minimum) everything worked fine on both wifi and Cellular. I checked on other servers with l2tp (I don't have access to them) and ios connects without problems. the problem is this particular image
Is this going to be fixed? It seems to be massively failing
@maffinca69 Hello! It looks like you are using the Docker image. What is your Docker host's Linux version? You may try the version from August 2023 using the following steps:
# Clone the repository
git clone https://github.com/hwdsl2/docker-ipsec-vpn-server
cd docker-ipsec-vpn-server
# Go back to the state on Aug. 15, 2023
git checkout 4c8bfa2
# To build Alpine-based image (note the dot "." at the end)
docker build -t hwdsl2/ipsec-vpn-server .
# Or, to build Debian-based image
docker build -f Dockerfile.debian -t hwdsl2/ipsec-vpn-server:debian .
After that, re-create the Docker container using instructions from the last paragraph of Update Docker image. When finished, enable Libreswan logs, then try the connection again. If the issue persists, it may not be caused by the image itself.
There's a chance that this was caused by upgrading the base image from Alpine Linux 3.18 to 3.19, which uses nftables by default. Note that the image already uses legacy IPTables for compatibility. If the manually built older image (based on Alpine 3.18) works for you, let us know.
@hwdsl2 Hi. Thanks for the quick reply :)
Yes, I am using docker image (alpine). Following your recommendation, I switched to the August 2023 commit and rebuilt the image (based on alpine 3.18)
Result: it worked, iPhone connected immediately, here are the logs of successful connection:
2024-04-08T04:16:39.673740+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[1] 172.18.0.1 #4: proposal 1:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048 chosen from remote proposals 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048[first-match]
2024-04-08T04:16:39.677950+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[1] 172.18.0.1 #4: sent IKE_SA_INIT reply {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
2024-04-08T04:16:39.859850+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[1] 172.18.0.1 #4: processing decrypted IKE_AUTH request: SK{IDi,CERT,N(INITIAL_CONTACT),IDr,AUTH,CP,N(ESP_TFC_PADDING_NOT_SUPPORTED),N(NON_FIRST_FRAGMENTS_ALSO),SA,TSi,TSr,N(MOBIKE_SUPPORTED)}
2024-04-08T04:16:39.871955+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[1] 172.18.0.1 #4: reloaded private key matching left certificate '46.17.105.3'
2024-04-08T04:16:39.872400+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[1] 172.18.0.1 #4: responder established IKE SA; authenticated peer '3072-bit PKCS#1 1.5 RSA with SHA1' signature using peer certificate 'CN=maffinca-ios, O=IKEv2 VPN' issued by CA 'CN=IKEv2 VPN CA, O=IKEv2 VPN'
2024-04-08T04:16:39.889132+00:00 ipsec-vpn-server pluto[996]: | pool 192.168.43.10-192.168.43.250: growing address pool from 1 to 2
2024-04-08T04:16:39.889163+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[1] 172.18.0.1 #5: proposal 1:ESP=AES_GCM_C_128-DISABLED SPI=0ce70145 chosen from remote proposals 1:ESP:ENCR=AES_GCM_C_128;ESN=DISABLED[first-match]
2024-04-08T04:16:39.912339+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[1] 172.18.0.1 #5: responder established Child SA using #4; IPsec tunnel [0.0.0.0-255.255.255.255:0-65535 0] -> [192.168.43.11-192.168.43.11:0-65535 0] {ESPinUDP=>0x0ce70145 <0x9551bcce xfrm=AES_GCM_16_128-NONE NATD=172.18.0.1:60290 DPD=active}
BUT. I disconnected from the VPN and connected again, and now the iPhone takes a very long time to connect. It takes about 1 minute, instead of 1s at normal time
Here are the logs of the long connection
UPD: It's okay. Apparently it's a problem on the side of my ISP and the signal strength of my mobile network
Anyway, solved the problem for me by switching to alpine 3.18 and the August 2023 commit
2024-04-08T04:21:00.807187+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #12: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 16 seconds for response
2024-04-08T04:21:03.901540+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[1] 172.18.0.1 #7: deleting incomplete state after 200 seconds
2024-04-08T04:21:03.901570+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[1] 172.18.0.1 #7: deleting state (STATE_V2_PARENT_R1) aged 200.00442s and NOT sending notification
2024-04-08T04:21:06.624137+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #14: proposal 1:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048 chosen from remote proposals 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048[first-match]
2024-04-08T04:21:06.626757+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #14: sent IKE_SA_INIT reply {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
2024-04-08T04:21:16.807766+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #12: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 32 seconds for response
2024-04-08T04:21:23.569541+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #8: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 128 seconds for response
2024-04-08T04:21:38.047554+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #15: proposal 1:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048 chosen from remote proposals 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048[first-match]
2024-04-08T04:21:38.049990+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #15: sent IKE_SA_INIT reply {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
2024-04-08T04:21:48.809593+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #12: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 64 seconds for response
2024-04-08T04:21:55.917575+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[1] 172.18.0.1 #4: STATE_V2_ESTABLISHED_IKE_SA: retransmission; will wait 256 seconds for response
2024-04-08T04:22:01.665543+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #10: deleting incomplete state after 200 seconds
2024-04-08T04:22:01.665568+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #10: deleting state (STATE_V2_PARENT_R1) aged 200.000002s and NOT sending notification
2024-04-08T04:22:09.459981+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #16: proposal 1:IKE=AES_CBC_256-HMAC_SHA2_256-HMAC_SHA2_256_128-MODP2048 chosen from remote proposals 1:IKE:ENCR=AES_CBC_256;PRF=HMAC_SHA2_256;INTEG=HMAC_SHA2_256_128;DH=MODP2048[first-match]
2024-04-08T04:22:09.462561+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #16: sent IKE_SA_INIT reply {cipher=AES_CBC_256 integ=HMAC_SHA2_256_128 prf=HMAC_SHA2_256 group=MODP2048}
2024-04-08T04:22:09.624409+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #16: processing decrypted IKE_AUTH request: SK{IDi,CERT,N(INITIAL_CONTACT),IDr,AUTH,CP,N(ESP_TFC_PADDING_NOT_SUPPORTED),N(NON_FIRST_FRAGMENTS_ALSO),SA,TSi,TSr,N(MOBIKE_SUPPORTED)}
2024-04-08T04:22:09.626376+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #16: responder established IKE SA; authenticated peer '3072-bit PKCS#1 1.5 RSA with SHA1' signature using peer certificate '@maffinca-ios' issued by CA 'CN=IKEv2 VPN CA, O=IKEv2 VPN'
2024-04-08T04:22:09.635289+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #17: proposal 1:ESP=AES_GCM_C_128-DISABLED SPI=03f9800c chosen from remote proposals 1:ESP:ENCR=AES_GCM_C_128;ESN=DISABLED[first-match]
2024-04-08T04:22:09.635708+00:00 ipsec-vpn-server pluto[996]: "ikev2-cp"[2] 172.18.0.1 #17: responder established Child SA using #16; IPsec tunnel [0.0.0.0-255.255.255.255:0-65535 0] -> [192.168.43.13-192.168.43.13:0-65535 0] {ESPinUDP=>0x03f9800c <0x7d3181fb xfrm=AES_GCM_16_128-NONE NATD=172.18.0.1:54159 DPD=active}
@maffinca69 Thanks for the update. What is your Docker host's Linux distribution and version (e.g. Ubuntu 22.04)?
@hwdsl2
OS: Debian GNU/Linux 11 (bullseye) x86_64
Kernel: 5.10.0-28-amd64
Shell: bash 5.1.4
@hwdsl2 any update?
@maffinca69 I tested using the latest Docker image and Debian 11 as the Docker host, but was unable to reproduce this issue. Connecting to IKEv2 from both Wi-Fi and cellular worked fine in my tests from an iPhone. Could the issue be caused by weak mobile network signal in your case? If you have additional logs related to this issue (reference) please share.
@maffinca69 hwdsl2/docker-ipsec-vpn-server#424 may be a similar issue. So far, I haven't been able to reproduce this issue.
@hwdsl2 Hi. Unfortunately, this bug does not reproduce for me personally (connects but nothing loads), but it does for my friends who connect to the same server from the same phones and ios versions. I looked at the logs but couldn't find anything suspicious
I think after rolling back to the August 2023 commit, only the hosting provider or the country's regulators are under suspicion