letoams
commented
4 months ago Looks like UDP 4500 filter. The first IKE_SA_INIT packet goes over udp 500. The second IKE_AUTH packet goes over 4500.Hopefully Apple will soon release ESPinTCP support which might pass that isp firewall - at least for a little time.Sent using a virtual keyboard on a phoneOn Feb 18, 2024, at 04:15, windofny1 @.***> wrote: Hello! Working with ikev2 config. We found issue, when connecting from cellular networks (no matter what device is - try in iPhone, Windows). When we use WiFi network (another Internet provider) - its connects without problems, Here is config
config setup plutodebug=all conn ikev2-cp left=%defaultroute leftcert=maskedserverip leftsendcert=always leftsubnet=0.0.0.0/0 leftrsasigkey=%cert right=%any rightid=%fromcert rightaddresspool=192.168.43.10-192.168.43.250 rightca=%same rightrsasigkey=%cert narrowing=yes dpddelay=30 retransmit-timeout=300s dpdaction=clear auto=add ikev2=insist rekey=no pfs=no ike=aes_gcm_c_256-hmac_sha2_256-ecp_256,aes256-sha2,aes128-sha2,aes256-sha1,a> phase2alg=aes_gcm-null,aes128-sha1,aes256-sha1,aes128-sha2,aes256-sha2 ikelifetime=24h salifetime=24h encapsulation=yes leftid=maskedserverip modecfgdns="8.8.8.8 8.8.4.4" mobike=no
Here is server log, when client connecting: 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 @. @. @. @. 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 - IKE_AUTH packets with Initiator Request and Responder Response just go away, not blocked. Same issue on the server side with WireShark (server ip is hidden): image.png (view on web) So at this moment same behaviour on client side in Wireshark - packets with IKE_AUTH request sends and not get answer. Looks like cellular network provider (or something other) redirects some of udp packets to the wrong route and VPN server not get answer from client while trying to authenticate request (and in another direction - server send, but client not get). It's very strange - some packets came and some not, like for example - ESP packets blocking by hardware in providers network. Yes, I'am forgot mension about another case at another server builded on Strongswan - when we work at WiFi and switch it 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. Also it's not a firewall issue, nothing is blocked. Changing setting in rekey, pfs, ike, phase2alg,encapsulation. mobike,dpddelay, does not give us any effects. And one more thing - our another client in same cellular network provider - but in another part of country - can connect without problem! It's like something provider's hardware blocks packets and some of is not. 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 ? Or something that change way of sending udp packets with some mask for providers hardware.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
Hello! Working with ikev2 config. We found issue, when connecting from cellular networks (no matter what device is - try in iPhone, Windows). When we use WiFi network (another Internet provider) - its connects without problems,
Here is config
Here is server log, when client connecting: tail /var/log/auth.log | grep pluto
using ipsec status:
It's also reproduces on StrongSwan server. I connect my iPhone to Mac and look at WireShark, it always reproduced same behavior - IKE_AUTH packets with Initiator Request and Responder Response just go away, not blocked. Same issue on the server side with WireShark (server ip is hidden):
So at this moment same behaviour on client side in Wireshark - packets with IKE_AUTH request sends and not get answer.
Looks like cellular network provider (or something other) redirects some of udp packets to the wrong route and VPN server not get answer from client while trying to authenticate request (and in another direction - server send, but client not get).
It's very strange - some packets came and some not, like for example - ESP packets blocking by hardware in providers network.
Yes, I'am forgot mension about another case at another server builded on Strongswan - when we work at WiFi and switch it 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. Also it's not a firewall issue, nothing is blocked. Changing setting in rekey, pfs, ike, phase2alg,encapsulation. mobike,dpddelay, does not give us any effects. And one more thing - our another client in same cellular network provider - but in another part of country - can connect without problem! It's like something provider's hardware blocks packets and some of is not.
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 ? Or something that change way of sending udp packets with some mask for providers hardware.