[strongSwan] GMP/dh-group issue

[Mohammadreza Ataei]

Hi,

I am quite new to stongswan, and I was able to bring up IKEv1 tunnels with
version 5.0.1 using a linux box running CentOS (2.6.32-358).

When I did the exact same things (running the same binary from network, and
the same config files), on a different linux machine (running CentOS
3.10.0-229) I saw:

negotiated DH group not supported

which I believe is because I don't have any dh-group algorithms known to
strongswan:

("ipsec listalgs" shows dh-group algorithms on the linux working fine, but
it is empty on the linux not working)

I installed "gmp-devel" on the linux box, and yet I see nothing in dh-group
algs.

Would you please tell me how I can tell strongswan to use the installed
gmp? Or do I have to install another package? Is there any specific gmp
package that I have to install?

I am confused and stuck! Please help.

Thanks,
Reza
___
Users mailing list
Users@lists.strongswan.org
https://lists.strongswan.org/mailman/listinfo/users

[strongSwan] Issue establishing a connection with strongswan

[Joe O]

I am having this issue when trying to connect over IPSec. I am just wondering 
if anyone knows what this might be off the top of their head or be able to 
point me in the right direction to resolve it.

Thanks in advance!


^[[CSep 16 17:42:13 vmi82861 charon: 04[ENC] parsed ID_PROT request 0 [ SA V V 
V V V V V V V V V V V V ]
Sep 16 17:42:13 vmi82861 charon: 04[CFG] looking for an ike config for 
5.189.135.134...37.14.94.220
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   candidate: %any...%any, prio 28
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   candidate: %any...%any, prio 24
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   candidate: %any...%any, prio 28
Sep 16 17:42:13 vmi82861 charon: 04[CFG] found matching ike config: %any...%any 
with prio 28
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received NAT-T (RFC 3947) vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received draft-ietf-ipsec-nat-t-ike 
vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received draft-ietf-ipsec-nat-t-ike-08 
vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received draft-ietf-ipsec-nat-t-ike-07 
vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received draft-ietf-ipsec-nat-t-ike-06 
vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received draft-ietf-ipsec-nat-t-ike-05 
vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received draft-ietf-ipsec-nat-t-ike-04 
vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received draft-ietf-ipsec-nat-t-ike-03 
vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received draft-ietf-ipsec-nat-t-ike-02 
vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received 
draft-ietf-ipsec-nat-t-ike-02\n vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received XAuth vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received Cisco Unity vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received FRAGMENTATION vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] received DPD vendor ID
Sep 16 17:42:13 vmi82861 charon: 04[IKE] 37.14.94.220 is initiating a Main Mode 
IKE_SA
Sep 16 17:42:13 vmi82861 charon: 04[IKE] IKE_SA (unnamed)[1] state change: 
CREATED => CONNECTING
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable DIFFIE_HELLMAN_GROUP 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable PSEUDO_RANDOM_FUNCTION 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptable ENCRYPTION_ALGORITHM 
found
Sep 16 17:42:13 vmi82861 charon: 04[CFG] selecting proposal:
Sep 16 17:42:13 vmi82861 charon: 04[CFG]   no acceptabl

Re: [strongSwan] Strongswan 5.4 issue using certificates

[Andreas Steffen]

Hi Rajeev,

yes, you have to load the private key file in your management tool
and transfer it via the VICI interface as a binary blob.

Regards

Andreas

On 15.09.2016 21:20, rajeev nohria wrote:
> Anderas, 
> 
> When using davici- 
> For the loading of private rsa keys, that has to be loaded like the
> certificate?
> 
> Thanks,
> Rajeev
> 
> On Thu, Sep 15, 2016 at 3:19 PM, rajeev nohria  > wrote:
> 
> Anderas, 
> 
> For the loading of private rsa keys, that has to be loaded like the
> certificate?
> 
> Thanks,
> Rajeev
> 
> On Thu, Aug 4, 2016 at 12:16 AM, Andreas Steffen
>  > wrote:
> 
> Hi Rajeev,
> 
> different to the stroke protocol and ipsec.conf where the filename
> of the certificate gets transferred via the stroke socket and the
> charon daemon loads the certificate, vici transfers the certificate
> itself either as a binary DER or a base64-endocded PEM blob. Thus
> your management application has to load the certificate and transfer
> it over the vici socket using davici.
> 
> Regards
> 
> Andreas
> 
> On 04.08.2016 05:03, rajeev nohria wrote:
> > Thanks Andreas,
> >
> > It worked, I know started to implement in Davici. I had PSK working 
> in
> > Davici. With certificates, I am having  following issue during
> > parse_certs().
> >
> > 09[LIB]   file coded in unknown format, discarded
> > 09[LIB] building CRED_CERTIFICATE - X509 failed, tried 4 builders
> >
> >
> >
> > Corresponding code is for Davici is
> > davici_list_start(r,"certs");
> >
> > 
> davici_list_itemf(r,"%s","/usr/local/etc/swanctl/x509/hostCert.pem");
> > davici_list_end(r);
> >
> >
> > I have tried file name with and without path.
> >
> > certs = hostCert.pem worked in swanctl.conf as attached in previous 
> email.
> >
> >
> > Do you know what could be issue here? Looks like software is not 
> able to
> > recognize the pem format but again it worked when using 
> swanctl.conf file.
> >
> > Thanks,
> > Rajeev
> >
> >
> > On Tue, Aug 2, 2016 at 5:41 AM, Andreas Steffen
> >  
>  >>
> > wrote:
> >
> > Hi,
> >
> > according to your log, the initiator and responder create
> their
> > own Root CA certificate and store it locally in
> > /usr/local/etc/swanctl/x509ca. Therefore it is not surprising
> > that no trust into the received host certificate can be
> established
> > because it has been signed with the private key of a different
> > root CA (although the Distinguished Name of the issuer is
> the same).
> >
> > Fix: Generate only one private key and matching self-signed
> > Root CA certificate. Use the private Root CA key to sign both
> > initiator and responder host certificates and deploy the
> Root CA
> > certificate on both hosts.
> >
> > Best regards
> >
> > Andreas
> >
> > On 01.08.2016 21:24, rajeev nohria wrote:
> > >
> > > I was able to establish IKE connection using PSK but
> when using pubkey I
> > > am not able to able to establish the IKE connection.
> > >
> > > When I issue sudo swanctl --initiate --child net
> > >
> > >
> > > At receptor, it returns the Auth_failed.  Please see the
> swanctl.conf,
> > > strongswan.conf and charon.log.
> > >
> > > Aug  1 12:09:21 12[CFG]  no issuer certificate
> found for "C=US,
> > > ST=MA, L=Lowell, O=Arris, CN=10.13.199.185"
> > > Aug  1 12:09:21 12[IKE]  no trusted RSA public key
> found for
> > > '10.13.199.185'
> > > Aug  1 12:09:21 12[IKE]  peer supports MOBIKE
> > > Aug  1 12:09:21 12[ENC]  added payload of type
> NOTIFY to message
> > > Aug  1 12:09:21 12[ENC]  order payloads in message
> > > Aug  1 12:09:21 12[ENC]  added payload of type
> NOTIFY to message
> > > Aug  1 12:09:21 12[ENC]  generating IKE_AUTH
> response 1 [
> > > N(AUTH_FAILED) ]
> > >
> > > I used following commands to create certificates.
> > >
> > > *Initiator:*
> > > ---
> > >
> > > sudo ips