L2TP / IPSec a cessé de fonctionner après la mise à niveau de openssl

5

Les connexions VPN de mes appareils MacBook / iOS à un serveur Debian sous openswan / xl2tp fonctionnaient parfaitement jusqu’à ce que j’utilise apt-get pour tout mettre à niveau en raison d’une annonce openssl heartbleed.

Maintenant, la connexion VPN a cessé de fonctionner avec les éléments suivants dans le fichier auth.log du serveur: 

Apr 11 10:32:50 linode pluto[7868]: packet from x.x.x.x:500: received Vendor ID payload [RFC 3947] method set to=109
Apr 11 10:32:50 linode pluto[7868]: packet from x.x.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike] method set to=110
Apr 11 10:32:50 linode pluto[7868]: packet from x.x.x.x:500: ignoring unknown Vendor ID payload [8f8d83826d246b6fc7a8a6a428c11de8]
Apr 11 10:32:50 linode pluto[7868]: packet from x.x.x.x:500: ignoring unknown Vendor ID payload [439b59f8ba676c4c7737ae22eab8f582]
Apr 11 10:32:50 linode pluto[7868]: packet from x.x.x.x:500: ignoring unknown Vendor ID payload [4d1e0e136deafa34c4f3ea9f02ec7285]
Apr 11 10:32:50 linode pluto[7868]: packet from x.x.x.x:500: ignoring unknown Vendor ID payload [80d0bb3def54565ee84645d4c85ce3ee]
Apr 11 10:32:50 linode pluto[7868]: packet from x.x.x.x:500: ignoring unknown Vendor ID payload [9909b64eed937c6573de52ace952fa6b]
Apr 11 10:32:50 linode pluto[7868]: packet from x.x.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-03] meth=108, but already using method 110
Apr 11 10:32:50 linode pluto[7868]: packet from x.x.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02] meth=107, but already using method 110
Apr 11 10:32:50 linode pluto[7868]: packet from x.x.x.x:500: received Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n] meth=106, but already using method 110
Apr 11 10:32:50 linode pluto[7868]: packet from x.x.x.x:500: ignoring Vendor ID payload [FRAGMENTATION 80000000]
Apr 11 10:32:50 linode pluto[7868]: packet from x.x.x.x:500: received Vendor ID payload [Dead Peer Detection]
Apr 11 10:32:50 linode pluto[7868]: "L2TP-PSK-NAT"[1] x.x.x.x #1: responding to Main Mode from unknown peer x.x.x.x
Apr 11 10:32:50 linode pluto[7868]: "L2TP-PSK-NAT"[1] x.x.x.x #1: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Apr 11 10:32:50 linode pluto[7868]: "L2TP-PSK-NAT"[1] x.x.x.x #1: STATE_MAIN_R1: sent MR1, expecting MI2
Apr 11 10:32:50 linode pluto[7868]: "L2TP-PSK-NAT"[1] x.x.x.x #1: message ignored because it contains an unknown or unexpected payload type (ISAKMP_NEXT_SAK) at the outermost level
Apr 11 10:32:50 linode pluto[7868]: "L2TP-PSK-NAT"[1] x.x.x.x #1: sending notification INVALID_PAYLOAD_TYPE to x.x.x.x:500
Apr 11 10:32:53 linode pluto[7868]: "L2TP-PSK-NAT"[1] x.x.x.x #1: message ignored because it contains an unknown or unexpected payload type (ISAKMP_NEXT_SAK) at the outermost level
Apr 11 10:32:53 linode pluto[7868]: "L2TP-PSK-NAT"[1] x.x.x.x #1: sending notification INVALID_PAYLOAD_TYPE to x.x.x.x:500
Apr 11 10:32:56 linode pluto[7868]: "L2TP-PSK-NAT"[1] x.x.x.x #1: message ignored because it contains an unknown or unexpected payload type (ISAKMP_NEXT_SAK) at the outermost level

et puis la connexion est rompue.

Même type de connexion utilisé pour générer cela dans les journaux il y a seulement 10 jours: 

Apr  1 04:16:04 linode pluto[3093]: "L2TP-PSK-NAT"[37] y.y.y.y #43: responding to Main Mode from unknown peer y.y.y.y
Apr  1 04:16:04 linode pluto[3093]: "L2TP-PSK-NAT"[37] y.y.y.y #43: transition from state STATE_MAIN_R0 to state STATE_MAIN_R1
Apr  1 04:16:04 linode pluto[3093]: "L2TP-PSK-NAT"[37] y.y.y.y #43: STATE_MAIN_R1: sent MR1, expecting MI2
Apr  1 04:16:04 linode pluto[3093]: "L2TP-PSK-NAT"[37] y.y.y.y #43: NAT-Traversal: Result using draft-ietf-ipsec-nat-t-ike (MacOS X): peer is NATed
Apr  1 04:16:04 linode pluto[3093]: "L2TP-PSK-NAT"[37] y.y.y.y #43: transition from state STATE_MAIN_R1 to state STATE_MAIN_R2
Apr  1 04:16:04 linode pluto[3093]: "L2TP-PSK-NAT"[37] y.y.y.y #43: STATE_MAIN_R2: sent MR2, expecting MI3
Apr  1 04:16:04 linode pluto[3093]: "L2TP-PSK-NAT"[37] y.y.y.y #43: ignoring informational payload, type IPSEC_INITIAL_CONTACT msgid=00000000
Apr  1 04:16:04 linode pluto[3093]: "L2TP-PSK-NAT"[37] y.y.y.y #43: Main mode peer ID is ID_IPV4_ADDR: '192.168.2.101'
Apr  1 04:16:04 linode pluto[3093]: "L2TP-PSK-NAT"[37] y.y.y.y #43: switched from "L2TP-PSK-NAT" to "L2TP-PSK-NAT"
Apr  1 04:16:04 linode pluto[3093]: "L2TP-PSK-NAT"[38] y.y.y.y #43: deleting connection "L2TP-PSK-NAT" instance with peer y.y.y.y {isakmp=#0/ipsec=#0}
Apr  1 04:16:04 linode pluto[3093]: "L2TP-PSK-NAT"[38] y.y.y.y #43: transition from state STATE_MAIN_R2 to state STATE_MAIN_R3

etc.

Mes questions sont:

  1. Quelle est la signification la plus apparente de l'erreur INVALID_PAYLOAD_TYPE?
  2. Outre la rétrogradation de openswan, quelles sont mes meilleures options pour étudier et résoudre ce problème?
networking debian vpn ipsec l2tp Dennis Kreminsky
la source
il semble que ce ne soit pas possible; t de négocier une méthode IKE (Internetwork Key Exchange) et, malgré l’essai de plusieurs méthodes, il n’est toujours pas possible de s’accorder sur l’une des deux pairs.
Frank Thomas
Je suppose que les IKE doivent être configurables quelque part?
Dennis Kreminsky
Nope, ressemble à un mécanisme de secours de la négociation automatique. probablement défini par les normes internationales. Je pense que c’est parce que vous avez un décalage entre les capacités des composants logiciels des homologues. assurez-vous que les deux côtés de la connexion ont été mis à niveau.
Frank Thomas
côté client, c’est mac os x / ios, je ne peux donc pas faire grand-chose à vrai dire. Ce qui me laisse perplexe, c’est que cela fonctionnait très bien, et googler ne donne que les utilisateurs de framboise qui ont des problèmes similaires et qui rétrogradent pour le réparer.
Dennis Kreminsky

Réponses:

6

Je viens de rencontrer le même problème aujourd'hui et il semble que cela soit causé par la dernière mise à jour de sécurité de debian Wheezy pour openswan. Quand tu fais un dpkg -l | grep openswan Je suppose que vous avez 1:2.6.37-3+deb7u1 installée.

Pour que cela fonctionne à nouveau avec votre iPad / IPhone, vous devez rétrograder openswan sur votre serveur avec apt-get install openswan=1:2.6.37-3.

Bien sûr, il ne s’agit que d’une solution de contournement moche et je ne suis pas sûr qu’il s’agisse d’un bogue dans le dernier OpenScan ou IOS, mais espérons qu’il sera corrigé dès que possible.

gucki
la source
Merci beaucoup pour votre réponse, cela résout le problème et je suppose que nous devrons vivre avec cela pour le moment.
Dennis Kreminsky
J'ai installé le deb patché à partir d'ici et cela fonctionne: bugs.debian.org/cgi-bin/bugreport.cgi?bug=744717
Halfgaar
Cela corrigea le problème pour moi aussi. Pour ceux qui cherchent openswan 1: 2.6.37-3 pour le framboise pi, il est disponible ici: capture instantanée.raspbian.org/201403301125/raspbian/pool/main/o/…
KernelSanders
Mieux encore, passez à strongswan si possible. Openswan va être retiré de la prochaine version de Debian, autant que je sache.
gucki