Important note about SSL VPN compatibility for 20.0 MR1 with EoL SFOS versions and UTM9 OS. Learn more in the release notes.

Thread Info
  • State Suggested Answer
  • Replies 7 replies
  • Answers 1 answer
  • Subscribers 41 subscribers
  • Views 2390 views
  • Users 0 members are here
Options
Suggested

Probleme mit Sophos XGS IPsec-VPN (iPadOS) und Deutsche Telekom

Dome96

Sehr geehrte Community,

ich habe ein Problem mit iPadOS und der IPsec-VPN-Verbindung in Zusammenhang mit der Telekom.

Beim Versuch, einen VPN-Tunnel von meinem iPad aufzubauen, gelingt dies nur unregelmäßig. Lediglich (geschätzt) 2 von 10 Verbindungsversuchen sind erfolgreich. Das iPad zeigt dabei immer die Fehlermeldung: "Kommunikation mit VPN-Server fehlgeschlagen".

Interessanterweise funktioniert die Verbindung von Windows-Clients und iPhones (iOS) reibungslos. Sobald das iPad mit einem WLAN verbunden ist oder ich einen Hotspot über das iPhone (ebenfalls Telekom LTE) nutze, stellt es die Verbindung ebenfalls zuverlässig her.

Ein weiterer Außendienst Mitarbeiter ist aktuell in Italien und nutzt Telekom IT. Dieser hat keinerlei Probleme mit der Verbindung.

Hier meine Konfiguration:



Added V20.0 MR2 TAG
[edited by: Erick Jan at 12:39 AM (GMT -7) on 1 Oct 2024]
  • 0

    EDIT: Wir haben die ganze Konfiguration bei einem anderen Kunden mit gleicher Hardware getestet. Dort haben wir das gleiche Szenario.

    IPsec-Verbindung über iPadOS und SIM der Telekom DE = funktioniert nicht oder nur kurzzeitig - nicht reproduzierbar

    IPsec-Verbindung über iPadOS und WLAN = funktioniert

    IPsec-Verbindung über iPadOS und Hotspot von iPhone (Telekom DE) = funktioniert

  • 0 in reply to Dome96

    Hi   - Could you help us to get the /log/charon.log from the device and also the logs from the Ipad in the failure case. Also the tcpdump for port 500 and 4500 on the SFOS will help.

  • 0 in reply to Giridhar Katti

    Hi,

    ich hab grade auch ähnliche Probleme, Sophos Support ist der Ansicht, die Telekom hat Routing Probleme.
    Zumindest bei mir werden VPN Tunnel nicht korrekt geroutet.

    Hatte gestern auch mit der Telekom telefoniert (Support für Company Connect IP Strecken).
    Von den Zweigstellen und im Head Office gibt es da Probleme.

    Von einem VDSL Zugang der Telekom läufts wiederum.

  • 0 in reply to Giridhar Katti

    Hi   - Here is the output of the file "/log/charon.log". Unfortunately, the tcpdump did not work as expected. I may have made a mistake in the process.

    XGS2300_RL01_SFOS 20.0.2 MR-2-Build378 HA-Primary# tail -f /log/charon.log
2024-09-19 10:11:56Z 11[IKE] <XXX_IPsec-1|943> sending DPD request
2024-09-19 10:11:56Z 11[ENC] <XXX_IPsec-1|943> generating INFORMATIONAL_V1 request 164127833 [ HASH N(DPD) ]
2024-09-19 10:11:56Z 11[NET] <XXX_IPsec-1|943> sending packet: from 62.225.XXX.XXX[4500] to 93.208.XXX.XXX[58400] (108 bytes)
2024-09-19 10:11:56Z 21[NET] <XXX_IPsec-1|943> received packet: from 93.208.XXX.XXX[58400] to 62.225.XXX.XXX[4500] (108 bytes)
2024-09-19 10:11:56Z 21[ENC] <XXX_IPsec-1|943> parsed INFORMATIONAL_V1 request 2634358332 [ HASH N(DPD_ACK) ]
2024-09-19 10:12:56Z 29[IKE] <XXX_IPsec-1|943> sending DPD request
2024-09-19 10:12:56Z 29[ENC] <XXX_IPsec-1|943> generating INFORMATIONAL_V1 request 4276033986 [ HASH N(DPD) ]
2024-09-19 10:12:56Z 29[NET] <XXX_IPsec-1|943> sending packet: from 62.225.XXX.XXX[4500] to 93.208.XXX.XXX[58400] (108 bytes)
2024-09-19 10:12:56Z 28[NET] <XXX_IPsec-1|943> received packet: from 93.208.XXX.XXX[58400] to 62.225.XXX.XXX[4500] (108 bytes)
2024-09-19 10:12:56Z 28[ENC] <XXX_IPsec-1|943> parsed INFORMATIONAL_V1 request 1119372875 [ HASH N(DPD_ACK) ]
2024-09-19 10:13:43Z 19[NET] <945> received packet: from 80.187..XXX.XXX[500] to 62.225.XXX.XXX[500] (848 bytes)
2024-09-19 10:13:43Z 19[ENC] <945> parsed ID_PROT request 0 [ SA V V V V V V V V V V V V V V ]
2024-09-19 10:13:43Z 19[IKE] <945> received NAT-T (RFC 3947) vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> received draft-ietf-ipsec-nat-t-ike vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> received draft-ietf-ipsec-nat-t-ike-08 vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> received draft-ietf-ipsec-nat-t-ike-07 vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> received draft-ietf-ipsec-nat-t-ike-06 vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> received draft-ietf-ipsec-nat-t-ike-05 vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> received draft-ietf-ipsec-nat-t-ike-04 vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> received draft-ietf-ipsec-nat-t-ike-03 vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> received draft-ietf-ipsec-nat-t-ike-02 vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> received draft-ietf-ipsec-nat-t-ike-02\n vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> received XAuth vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> received Cisco Unity vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> received FRAGMENTATION vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> received DPD vendor ID
2024-09-19 10:13:43Z 19[IKE] <945> 80.187..XXX.XXX is initiating a Main Mode IKE_SA
2024-09-19 10:13:43Z 19[CFG] <945> selected proposal: IKE:AES_CBC_256/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048
2024-09-19 10:13:43Z 19[ENC] <945> generating ID_PROT response 0 [ SA V V V V V ]
2024-09-19 10:13:43Z 19[NET] <945> sending packet: from 62.225.XXX.XXX[500] to 80.187..XXX.XXX[500] (180 bytes)
2024-09-19 10:13:43Z 13[NET] <945> received packet: from 80.187..XXX.XXX[500] to 62.225.XXX.XXX[500] (380 bytes)
2024-09-19 10:13:43Z 13[ENC] <945> parsed ID_PROT request 0 [ KE No NAT-D NAT-D ]
2024-09-19 10:13:43Z 13[IKE] <945> local host is behind NAT, sending keep alives
2024-09-19 10:13:43Z 13[IKE] <945> remote host is behind NAT
2024-09-19 10:13:43Z 13[ENC] <945> generating ID_PROT response 0 [ KE No NAT-D NAT-D ]
2024-09-19 10:13:43Z 13[NET] <945> sending packet: from 62.225.XXX.XXX[500] to 80.187..XXX.XXX[500] (396 bytes)
2024-09-19 10:13:43Z 22[NET] <945> received packet: from 80.187..XXX.XXX[20355] to 62.225.XXX.XXX[4500] (108 bytes)
2024-09-19 10:13:43Z 22[ENC] <945> parsed ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
2024-09-19 10:13:43Z 22[CFG] <945> looking for XAuthInitPSK peer configs matching 62.225.XXX.XXX...80.187..XXX.XXX[0.0.0.0]
2024-09-19 10:13:43Z 22[CFG] <945> selected peer config "XXX_IPsec-1"
2024-09-19 10:13:43Z 22[ENC] <XXX_IPsec-1|945> generating ID_PROT response 0 [ ID HASH ]
2024-09-19 10:13:43Z 22[NET] <XXX_IPsec-1|945> sending packet: from 62.225.XXX.XXX[4500] to 80.187..XXX.XXX[20355] (92 bytes)
2024-09-19 10:13:43Z 22[APP] <XXX_IPsec-1|945> [XAUTH] (initiate_server) initiate XAuth request - server: '62.225.XXX.XXX' peer: '0.0.0.0'
2024-09-19 10:13:43Z 22[ENC] <XXX_IPsec-1|945> generating TRANSACTION request 4247552187 [ HASH CPRQ(X_USER X_PWD) ]
2024-09-19 10:13:43Z 22[NET] <XXX_IPsec-1|945> sending packet: from 62.225.XXX.XXX[4500] to 80.187..XXX.XXX[20355] (92 bytes)
2024-09-19 10:13:47Z 31[IKE] <XXX_IPsec-1|945> sending retransmit 1 of request message ID 4247552187, seq 1
2024-09-19 10:13:47Z 31[NET] <XXX_IPsec-1|945> sending packet: from 62.225.XXX.XXX[4500] to 80.187..XXX.XXX[20355] (92 bytes)
2024-09-19 10:13:55Z 17[IKE] <XXX_IPsec-1|945> sending retransmit 2 of request message ID 4247552187, seq 1
2024-09-19 10:13:55Z 17[NET] <XXX_IPsec-1|945> sending packet: from 62.225.XXX.XXX[4500] to 80.187..XXX.XXX[20355] (92 bytes)
2024-09-19 10:13:56Z 21[IKE] <XXX_IPsec-1|943> sending DPD request
2024-09-19 10:13:56Z 21[ENC] <XXX_IPsec-1|943> generating INFORMATIONAL_V1 request 2498468231 [ HASH N(DPD) ]
2024-09-19 10:13:56Z 21[NET] <XXX_IPsec-1|943> sending packet: from 62.225.XXX.XXX[4500] to 93.208.XXX.XXX[58400] (108 bytes)
2024-09-19 10:13:56Z 12[NET] <XXX_IPsec-1|943> received packet: from 93.208.XXX.XXX[58400] to 62.225.XXX.XXX[4500] (108 bytes)
2024-09-19 10:13:56Z 12[ENC] <XXX_IPsec-1|943> parsed INFORMATIONAL_V1 request 15213305 [ HASH N(DPD_ACK) ]
2024-09-19 10:14:08Z 28[IKE] <XXX_IPsec-1|945> sending retransmit 3 of request message ID 4247552187, seq 1
2024-09-19 10:14:08Z 28[NET] <XXX_IPsec-1|945> sending packet: from 62.225.XXX.XXX[4500] to 80.187..XXX.XXX[20355] (92 bytes)
2024-09-19 10:14:09Z 24[NET] <XXX_IPsec-1|945> received packet: from 80.187..XXX.XXX[20355] to 62.225.XXX.XXX[4500] (124 bytes)
2024-09-19 10:14:09Z 24[ENC] <XXX_IPsec-1|945> parsed TRANSACTION response 4247552187 [ HASH CPRP(X_USER X_PWD) ]
2024-09-19 10:14:09Z 24[APP] <XXX_IPsec-1|945> [XAUTH] (process_server) process XAuth request - server: '62.225.XXX.XXX' peer: '0.0.0.0'
2024-09-19 10:14:09Z 24[APP] <XXX_IPsec-1|945> [XAUTH][TLV] (auth_user_pass_verify) Send request(7) - user: USER@XXX.local pass: <HIDDEN> ip: 80.187..XXX.XXX port: 20355 conn_name: XXX_IPsec-1
2024-09-19 10:14:09Z 24[APP] <XXX_IPsec-1|945> [XAUTH][TLV] (auth_user_pass_verify) response from Authentication server (rcode: 2 resp_code: 2)
2024-09-19 10:14:09Z 24[APP] <XXX_IPsec-1|945> [XAUTH][TLV] (auth_user_pass_verify) response: ACK --> SUCCESS
2024-09-19 10:14:09Z 24[APP] <XXX_IPsec-1|945> [XAUTH] (get_identity) get_identity: 'USER@XXX.local'
2024-09-19 10:14:09Z 24[IKE] <XXX_IPsec-1|945> XAuth authentication of 'USER@XXX.local' successful
2024-09-19 10:14:09Z 24[ENC] <XXX_IPsec-1|945> generating TRANSACTION request 3128193993 [ HASH CPS(X_STATUS) ]
2024-09-19 10:14:09Z 24[NET] <XXX_IPsec-1|945> sending packet: from 62.225.XXX.XXX[4500] to 80.187..XXX.XXX[20355] (92 bytes)
2024-09-19 10:14:09Z 18[NET] <XXX_IPsec-1|945> received packet: from 80.187..XXX.XXX[20355] to 62.225.XXX.XXX[4500] (92 bytes)
2024-09-19 10:14:09Z 18[ENC] <XXX_IPsec-1|945> parsed TRANSACTION response 3128193993 [ HASH CPA(X_STATUS) ]
2024-09-19 10:14:09Z 18[IKE] <XXX_IPsec-1|945> IKE_SA XXX_IPsec-1[945] established between 62.225.XXX.XXX[62.225.XXX.XXX]...80.187..XXX.XXX[0.0.0.0]
2024-09-19 10:14:09Z 18[IKE] <XXX_IPsec-1|945> scheduling reauthentication in 17292s
2024-09-19 10:14:09Z 18[IKE] <XXX_IPsec-1|945> maximum IKE_SA lifetime 17652s
2024-09-19 10:14:29Z 24[IKE] <XXX_IPsec-1|945> sending keep alive to 80.187..XXX.XXX[20355]
2024-09-19 10:14:49Z 29[IKE] <XXX_IPsec-1|945> sending keep alive to 80.187..XXX.XXX[20355]
2024-09-19 10:14:56Z 17[IKE] <XXX_IPsec-1|943> sending DPD request
2024-09-19 10:14:56Z 17[ENC] <XXX_IPsec-1|943> generating INFORMATIONAL_V1 request 3382112069 [ HASH N(DPD) ]
2024-09-19 10:14:56Z 17[NET] <XXX_IPsec-1|943> sending packet: from 62.225.XXX.XXX[4500] to 93.208.XXX.XXX[58400] (108 bytes)
2024-09-19 10:14:56Z 25[NET] <XXX_IPsec-1|943> received packet: from 93.208.XXX.XXX[58400] to 62.225.XXX.XXX[4500] (108 bytes)
2024-09-19 10:14:56Z 25[ENC] <XXX_IPsec-1|943> parsed INFORMATIONAL_V1 request 1380321226 [ HASH N(DPD_ACK) ]

    XGS2300_RL01_SFOS 20.0.2 MR-2-Build378 HA-Primary# tcpdump 'port 500 and port 4500' -v
tcpdump: listening on any, link-type LINUX_SLL (Linux cooked v1), capture size 262144 bytes

  • 0 in reply to juergenb52

    Hi   - Hast du noch immer die Probleme? Komischerweise besteht das Problem nur bei iPads, die über LTE der Telekom DE versuchen den IPsec-VPN aufzubauen. iPhone und Windows funktionieren einwandfrei .. 

    VielenDank 

  • 0 in reply to Dome96

    Hi,

    nein,

    meine Problem sind nach einem Reboot des XGS2100 HA Clusters und eines CISCO Switches (vor der Firewall) verschwunden.
    Der Reboot der Telekom Router hatte keinen Einfluss.

    Aber es gibt einen VPN/IKeV2 Bug im SFOS.

    Reduzier mal die Anzahl der DH Gruppen auf < 4, die SFOS läuft da in einen Bug (finde den KB Artikel grade nicht).

  • 0 in reply to juergenb52

      

    The log you posted - is it in the successful tunnel establishment case or failure case? the log is incomplete, it only says IKEv1 session is up, no logs to indicate if RA client (iPad) gets virtual ip or not and there is no log related to Child SA establishment.

    And your point related to "Reduce the number of DH groups to < 4, the SFOS runs into a bug (can't find the KB article right now)." - did you try this (reducing the no. of DH groups in your IPsec profile by cloning the DefaultRemoteaccess) while connecting your iPad with SFOS using IPsec RA and you ran into some issue? what is the issue you are running into?

    This KB note mentions about reducing the number of DH group - https://support.sophos.com/support/s/article/KBA-000009744?language=en_US; this is a workaround for now, it will be fixed in v21.5 release and this is applicable to IKEv2; IPsec RA uses IKEv1. 

Unfiltered HTML