Thanks the Windows server looks to be complaining about the remote certificate
(left) and not trusting it.
An IPsec main mode negotiation failed.
Local Endpoint:
Principal Name: LAB-FPSVR-01.lab.vdcs.local
Network Address: 192.168.2.5
Keying Module Port: 500
Local Certificate:
SHA Thumbprint: 86dc43a7d4fcab6ef6e6f9f12de41e7305b941d7
Issuing CA: lab-LAB-DC-01-CA-1
Root CA: DC=local, DC=vdcs, DC=lab, CN=lab-LAB-DC-01-CA-1
Remote Endpoint:
Principal Name: lab-debclient-01.lab.vdcs.local
Network Address: 192.168.2.9
Keying Module Port: 500
Remote Certificate:
SHA thumbprint: 343288fe7510bf8f424d364f361cfd96098e6ec1
Issuing CA: lab-debclient-01.lab.vdcs.local
Root CA: -
Additional Information:
Keying Module Name: IKEv1
Authentication Method: Certificate
Role: Initiator
Impersonation State: Not enabled
Main Mode Filter ID: 73226
Failure Information:
Failure Point: Local computer
Failure Reason: IKE authentication credentials are unacceptable
State: Sent third (ID) payload
Initiator Cookie: 278de834073ca514
Responder Cookie: 075cc7a5819aa05f
-----Original Message-----
From: Noel Kuntze [mailto:[email protected]]
Sent: 27 October 2017 13:47
To: Ben Lavender <[email protected]>; [email protected]
Subject: Re: [strongSwan] Host-to-Host Windows to Debian (StrongSwan)
The logs of the Windows server will tell you what it doesn't like.
On 27.10.2017 11:13, Ben Lavender wrote:
>
> Anyone think they could assist with this?
>
>
>
> *From:*Ben Lavender
> *Sent:* 24 October 2017 17:23
> *To:* '[email protected]' <[email protected]>
> *Subject:* Host-to-Host Windows to Debian (StrongSwan)
>
>
>
> Hello,
>
>
>
> Please could anyone assist with this problem?
>
>
>
> We have setup a connection between to servers (right Windows | left
> Debian-StrongSwan) in a host-to-host configure, where the Windows server will
> be establishing the connection using transport mode (IKEv1). The
> authentication is set to use a X.509 certificates.
>
>
>
> The problem we are having seems to be within the two log lines below:
>
>
>
> Oct 24 16:21:45 LAB-DEBCLIENT-01 charon: 07[ENC] parsed INFORMATIONAL_V1
> request 62237808 [ HASH N(AUTH_FAILED) ]
>
> Oct 24 16:21:45 LAB-DEBCLIENT-01 charon: 07[IKE] received
> AUTHENTICATION_FAILED error notify
>
>
>
> Is there any advice given for attempting to resolve this issue? I can provide
> full logs if need be. Thanks.
>
>
>
> /etc/ipsec.conf
>
>
>
> # ipsec.conf - strongSwan IPsec configuration file
>
>
>
> config setup
>
> charondebug="ike 4, knl 4, cfg 4"
>
>
>
> conn %default
>
> ikelifetime=60m
>
> keylife=20m
>
> rekeymargin=3m
>
> keyingtries=1
>
> mobike=no
>
> keyexchange=ike
>
>
>
> conn host-host
>
> left=192.168.2.9
>
> leftcert=deb.crt.pem
>
> leftid="CN=LAB-DEBCLIENT-01.lab.vdcs.local"
>
> leftfirewall=yes
>
> right=192.168.2.5
>
> rightid="CN=LAB-FPSVR-01.lab.vdcs.local"
>
> type=transport
>
> auto=add
>
>
>
> ca strongswan
>
> cacert=rootca.pem
>
> crluri=http://LAB-DC-01.lab.vdcs.local/tempcrl/lab-LAB-DC-01-CA-1.crl
>
> auto=add
>
>
>
>
>
> /etc/ipsec.secrets
>
>
>
> # This file holds shared secrets or RSA private keys for authentication.
>
>
>
> # RSA private key for this host, authenticating it to any other host
>
> # which knows the public part.
>
>
>
> : RSA deb.key.pem
>
>
>
> Regards
>
>
>
> Ben
>
>
>
> Virtual Data Centre Services (virtualDCS) is registered in England and Wales
> under company number 07238621; registered address: The Waterscape, 42 Leeds
> and Bradford Road, LS5 3EG. This e-mail and any attachments are strictly
> confidential and intended for the addressee only. If you are not the named
> addressee you must not disclose, copy, or take any action in reliance of this
> transmission, and you should notify us as soon as possible. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of virtualDCS. This e-mail and any attachments are believed
> to be free from viruses but it is your responsibility to carry out all
> necessary virus checks, and virtualDCS accepts no liability in connection
> therewith.
>
