0
VPN Strongswan -> Astaro Security Gateway (v7, con OpenSwan)

Solved 2 Respuestas 3 Views

Falla al conectar a una VPN, del otro lado hay un Astaro Security Gateway v7, que usa OpenSwan por abajo. Estoy usando Strongswan 5.1.2 de mi lado. Alguien sálveme <3

Según me dicen, estos son los ciphers:
IKE: Auth PSK / Enc AES_CBC_128 / Hash SHA / Lifetime 7800s / DPD
IPSec: Enc AES_256 / Hash HMAC_MD5 / Lifetime 3600s

El ipsec.conf:
conn %default
        ikelifetime=130m
        lifetime=1h
        keyexchange=ikev1

conn strands
        auto=start
        left=%any
        leftsubnet=%dynamic[17/1701]
        leftauth=psk
        right=bcn-vpn.mystrands.in
        rightid=%any
        rightsubnet=%dynamic[17/1701]
        rightauth=psk
        type=transport
        ike=aes128-sha1-modp2048
        esp=aes128-sha1!
        rekey=no
        modeconfig=pull
 

Log (mi lado, intenta re-levantar después del DELETE):
Jun 25 16:04:29 master01 charon: 14[IKE] initiating Main Mode IKE_SA strands[12] to 91.126.243.60
Jun 25 16:04:29 master01 charon: 14[ENC] generating ID_PROT request 0 [ SA V V V V ]
Jun 25 16:04:29 master01 charon: 14[NET] sending packet: from 107.170.162.234[500] to 91.126.243.60[500] (188 bytes)
Jun 25 16:04:29 master01 charon: 15[NET] received packet: from 91.126.243.60[500] to 107.170.162.234[500] (176 bytes)
Jun 25 16:04:29 master01 charon: 15[ENC] parsed ID_PROT response 0 [ SA V V V V V ]
Jun 25 16:04:29 master01 charon: 15[ENC] received unknown vendor ID: 2d:1f:40:61:18:fb:d5:d2:84:74:79:1f:fa:00:48:8a
Jun 25 16:04:29 master01 charon: 15[IKE] received Cisco Unity vendor ID
Jun 25 16:04:29 master01 charon: 15[IKE] received XAuth vendor ID
Jun 25 16:04:29 master01 charon: 15[IKE] received DPD vendor ID
Jun 25 16:04:29 master01 charon: 15[IKE] received NAT-T (RFC 3947) vendor ID
Jun 25 16:04:29 master01 charon: 15[ENC] generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
Jun 25 16:04:29 master01 charon: 15[NET] sending packet: from 107.170.162.234[500] to 91.126.243.60[500] (372 bytes)
Jun 25 16:04:29 master01 charon: 02[NET] received packet: from 91.126.243.60[500] to 107.170.162.234[500] (356 bytes)
Jun 25 16:04:29 master01 charon: 02[ENC] parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
Jun 25 16:04:29 master01 charon: 02[ENC] generating ID_PROT request 0 [ ID HASH ]
Jun 25 16:04:29 master01 charon: 02[NET] sending packet: from 107.170.162.234[500] to 91.126.243.60[500] (76 bytes)
Jun 25 16:04:29 master01 charon: 11[NET] received packet: from 91.126.243.60[500] to 107.170.162.234[500] (76 bytes)
Jun 25 16:04:29 master01 charon: 11[ENC] parsed ID_PROT response 0 [ ID HASH ]
Jun 25 16:04:29 master01 charon: 11[IKE] IKE_SA strands[12] established between 107.170.162.234[107.170.162.234]...91.126.243.60[91.126.243.60]
Jun 25 16:04:29 master01 charon: 11[ENC] generating QUICK_MODE request 2431782957 [ HASH SA No ID ID ]
Jun 25 16:04:29 master01 charon: 11[NET] sending packet: from 107.170.162.234[500] to 91.126.243.60[500] (172 bytes)
Jun 25 16:04:29 master01 charon: 12[NET] received packet: from 91.126.243.60[500] to 107.170.162.234[500] (92 bytes)
Jun 25 16:04:29 master01 charon: 12[ENC] parsed INFORMATIONAL_V1 request 424476849 [ HASH D ]
Jun 25 16:04:29 master01 charon: 12[IKE] received DELETE for IKE_SA strands[12]
Jun 25 16:04:29 master01 charon: 12[IKE] deleting IKE_SA strands[12] between 107.170.162.234[107.170.162.234]...91.126.243.60[91.126.243.60]
Jun 25 16:04:29 master01 charon: 12[IKE] initiating Main Mode IKE_SA strands[13] to 91.126.243.60
(aca loopea y vuelve a arrancar desde la primera línea)

Log (del otro lado):

2015:06:25-19:27:42 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13282] 190.245.38.63 #67173: Peer ID is ID_IPV4_ADDR: '190.245.38.63'
2015:06:25-19:27:42 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13282] 190.245.38.63 #67173: sent MR3, ISAKMP SA established
2015:06:25-19:27:42 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13282] 190.245.38.63 #67173: ISAKMP SA expired (--dontrekey)
2015:06:25-19:27:42 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13282] 190.245.38.63: deleting connection "S_REF_VvpqdfzxJp" instance with peer 190.245.38.63 {isakmp=#0/ipsec=#0}
2015:06:25-19:27:43 bcn-fw pluto[3672]: packet from 190.245.38.63:500: Quick Mode message is for a non-existent (expired?) ISAKMP SA
2015:06:25-19:27:43 bcn-fw pluto[3672]: packet from 190.245.38.63:500: received Vendor ID payload [XAUTH]
2015:06:25-19:27:43 bcn-fw pluto[3672]: packet from 190.245.38.63:500: received Vendor ID payload [Dead Peer Detection]
2015:06:25-19:27:43 bcn-fw pluto[3672]: packet from 190.245.38.63:500: received Vendor ID payload [RFC 3947]
2015:06:25-19:27:43 bcn-fw pluto[3672]: packet from 190.245.38.63:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2015:06:25-19:27:43 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13283] 190.245.38.63 #67174: responding to Main Mode from unknown peer 190.245.38.63
2015:06:25-19:27:43 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13283] 190.245.38.63 #67174: NAT-Traversal: Result using RFC 3947: no NAT detected
2015:06:25-19:27:44 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13283] 190.245.38.63 #67174: Peer ID is ID_IPV4_ADDR: '190.245.38.63'
2015:06:25-19:27:44 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13283] 190.245.38.63 #67174: sent MR3, ISAKMP SA established
2015:06:25-19:27:44 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13283] 190.245.38.63 #67174: ISAKMP SA expired (--dontrekey)
2015:06:25-19:27:44 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13283] 190.245.38.63: deleting connection "S_REF_VvpqdfzxJp" instance with peer 190.245.38.63 {isakmp=#0/ipsec=#0}
2015:06:25-19:27:44 bcn-fw pluto[3672]: packet from 190.245.38.63:500: Quick Mode message is for a non-existent (expired?) ISAKMP SA
2015:06:25-19:27:44 bcn-fw pluto[3672]: packet from 190.245.38.63:500: received Vendor ID payload [XAUTH]
2015:06:25-19:27:44 bcn-fw pluto[3672]: packet from 190.245.38.63:500: received Vendor ID payload [Dead Peer Detection]
2015:06:25-19:27:44 bcn-fw pluto[3672]: packet from 190.245.38.63:500: received Vendor ID payload [RFC 3947]
2015:06:25-19:27:44 bcn-fw pluto[3672]: packet from 190.245.38.63:500: ignoring Vendor ID payload [draft-ietf-ipsec-nat-t-ike-02_n]
2015:06:25-19:27:44 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13284] 190.245.38.63 #67175: responding to Main Mode from unknown peer 190.245.38.63
2015:06:25-19:27:45 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13284] 190.245.38.63 #67175: NAT-Traversal: Result using RFC 3947: no NAT detected
2015:06:25-19:27:46 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13284] 190.245.38.63 #67175: Peer ID is ID_IPV4_ADDR: '190.245.38.63'
2015:06:25-19:27:46 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13284] 190.245.38.63 #67175: sent MR3, ISAKMP SA established
2015:06:25-19:27:46 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13284] 190.245.38.63 #67175: ISAKMP SA expired (--dontrekey)
2015:06:25-19:27:46 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13284] 190.245.38.63: deleting connection "S_REF_VvpqdfzxJp" instance with peer 190.245.38.63 {isakmp=#0/ipsec=#0}
2015:06:25-19:27:46 bcn-fw pluto[3672]: packet from 190.245.38.63:500: Quick Mode message is for a non-existent (expired?) ISAKMP SA

2 Respuestas

1
Mejor respuesta

1) Del otro lado tenes un cisco unity:

Jun 25 16:04:29 master01 charon: 15[IKE] received Cisco Unity vendor ID

2) CREO que, al menos, uno de los problemas es que estas usando quickmode (Aggressive) y la implementacion del lado de cisco no lo acepta correctamente, no esta el log completo, no te puedo decir el motivo concreto, pero tiene que ver con el dontrekey que estas usando:

2015:06:25-19:27:42 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13282] 190.245.38.63 #67173: ISAKMP SA expired (--dontrekey)
2015:06:25-19:27:42 bcn-fw pluto[3672]: "S_REF_VvpqdfzxJp"[13282] 190.245.38.63: deleting connection "S_REF_VvpqdfzxJp" instance with peer 190.245.38.63 {isakmp=#0/ipsec=#0}


Usa rekey en yes de los dos lados, y modo MAIN de los dos lados (modo main es el modo no-quick/agressive), si te falla subi los logs de los dos lados devuelta y vemos.
respondido por qlixed (10,610 puntos) Jun 26, 2015
seleccionada por TaiSHi Jun 28, 2015
2Comentarios
comentado por TaiSHi (1,400 puntos) Jun 26, 2015
agressive defaultea a 'no', probé con yes y falla.
No tengo manera de manejar del otro lado (que es donde setearon el --donotrekey). Cisco Unity es VoIP/messaging, no tiene nada que ver en esto (ya investigué).
Del otro lado hay un openswan/libreswan/strongswan viejo por lo que pude determinar (pluto es el daemon de ikev1).
Estoy super limitado de la info que me dan del otro lado, desde Windorch probé y me anduvo de primera después de un poco de tweaking.
Les pedí todas las configs a los que manejan el router pero uno renuncia mañana y el otro está de vacaciones :P
comentado por TaiSHi (1,400 puntos) Jun 28, 2015
Te vuelvo a responder, porque no había probado con rekey=yes DESPUES de jugar con los cipher suites. Aparte me venían diciendo que no rotundamente en el canal de strongswan. Jugando y jugando, terminé probando con el rekey=yes y un par de retoques mas y anduvo.
Gracias qlicho
0
Del otro lado en el log dice que recibe el paquete de 190.245.38.63, pero en tu log dice que sale de la 107.170.162.234.
Estas detras de un firewall?
respondido por zingaya (3,410 puntos) Jun 25, 2015
3Comentarios
comentado por TaiSHi (1,400 puntos) Jun 25, 2015
Perdón Zinga, son pruebas desde 2 lugares diferentes (casa y un server), pero los errores son los mismos
comentado por zingaya (3,410 puntos) Jun 25, 2015
Ok.
Quiza es tonta la respuesta, pero probaste con rekey=yes
comentado por TaiSHi (1,400 puntos) Jun 25, 2015
Yo pensé exactamente lo mismo pero el --donotrekey es del lado del server. Probé igual y es peor
...