IPSec/Strongswan -- server refusing connection despite correct username/password

stangri · February 19, 2019, 10:48pm

Hello,

Trying to use Strongswan on 18.06.2 as a client, I experience the XAuth authentication of 'my-user-name' (myself) failed.

I have the password specified in /etc/ipsec.secrets (as my-user-name : XAUTH my-password), but I feel that it doesn't get picked up because even if I completely comment out that line, I still get the same error.

I do not have control to the server logs (it's a third-party server), so I cannot investigate on that side. Does the Strongswan (as a client) try to pick up the XAUTH from any other files?

mpa · February 19, 2019, 11:50pm

From your client, please show us:

/etc/ipsec.secrets (with obfuscated secrets)
/etc/ipsec.conf
the output of ipsec statusall

stangri · February 20, 2019, 12:08am

Thanks for your prompt reply!


WRT3200 in ~ # ipsec statusall
Status of IKE charon daemon (strongSwan 5.6.3, Linux 4.14.95, armv7l):
  uptime: 5 hours, since Feb 19 10:08:41 2019
  worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
  loaded plugins: charon test-vectors ldap pkcs11 aes des blowfish rc2 sha2 sha1 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl gcrypt af-alg fips-prf gmp curve25519 agent xcbc cmac hmac ctr ccm gcm curl mysql sqlite attr kernel-netlink resolve socket-default connmark forecast farp stroke vici smp updown eap-identity eap-md5 eap-mschapv2 eap-radius eap-tls xauth-generic xauth-eap dhcp whitelist led duplicheck addrblock unity
Listening IP addresses:
  *.*.*.*
Connections:
         cac:  %any...remote-server  IKEv1
         cac:   local:  [my-user-name] uses pre-shared key authentication
         cac:   local:  [my-user-name] uses XAuth authentication: any with XAuth identity 'my-user-name'
         cac:   remote: uses pre-shared key authentication
         cac:   remote: uses XAuth authentication: any with XAuth identity 'my-user-name'
         cac:   child:  dynamic === 0.0.0.0/0 TUNNEL
Security Associations (0 up, 0 connecting):
  none

WRT3200 in ~ # cat /etc/ipsec.secrets
# /etc/ipsec.secrets - strongSwan IPsec secrets file
%any remote-server : PSK cloudatcost
my-user-name : XAUTH my-password

WRT3200 in ~ # cat /etc/ipsec.conf
# ipsec.conf - strongSwan IPsec configuration file

# basic configuration

config setup
  charondebug=all

# Add connections here.
conn cac
  keyexchange=ikev1
#  compress=yes
  authby=xauthpsk
  xauth=client
  xauth_identity=my-user-name
#  left=%any
  left=%defaultroute
  leftsourceip=%config
  leftfirewall=yes
  leftauth=psk
  leftauth2=xauth
  leftid=my-user-name
  right=remote-server
  rightsubnet=0.0.0.0/0
  rightauth=psk
  rightauth2=xauth
  rightid=%any
  ike=aes128-sha-modp1536,3des-sha-modp1536
  auto=start

WRT3200 in ~ # ipsec up cac
initiating Main Mode IKE_SA cac[12] to remote-server
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from my-ip[500] to remote-server[500] (272 bytes)
received packet: from remote-server[500] to my-ip[500] (156 bytes)
parsed ID_PROT response 0 [ SA V V V V ]
received DPD vendor ID
received FRAGMENTATION vendor ID
received XAuth vendor ID
received NAT-T (RFC 3947) vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from my-ip[500] to remote-server[500] (308 bytes)
received packet: from remote-server[500] to my-ip[500] (308 bytes)
parsed ID_PROT response 0 [ KE No NAT-D NAT-D ]
local host is behind NAT, sending keep alives
remote host is behind NAT
generating ID_PROT request 0 [ ID HASH ]
sending packet: from my-ip[4500] to remote-server[4500] (76 bytes)
received packet: from remote-server[4500] to my-ip[4500] (76 bytes)
parsed ID_PROT response 0 [ ID HASH ]
received packet: from remote-server[4500] to my-ip[4500] (76 bytes)
parsed TRANSACTION request 1551987860 [ HASH CPRQ(X_USER X_PWD) ]
generating TRANSACTION response 1551987860 [ HASH CPRP(X_USER X_PWD) ]
sending packet: from my-ip[4500] to remote-server[4500] (92 bytes)
received packet: from remote-server[4500] to my-ip[4500] (76 bytes)
parsed TRANSACTION request 2640688873 [ HASH CPS(X_STATUS) ]
XAuth authentication of 'my-user-name' (myself) failed
generating TRANSACTION response 2640688873 [ HASH CPA(X_STATUS) ]
sending packet: from my-ip[4500] to remote-server[4500] (76 bytes)
establishing connection 'cac' failed

slh · February 20, 2019, 12:11am

Any change if you quote the password?
my-user-name : XAUTH "my-password"

mpa · February 20, 2019, 12:26am

Xauth is not a mutual authentication protocol. Remove this line.

You can find examples in the strongswan wiki:

Roadwarrior scenario
-> Initiator
-> ipsec.conf
-> conn ikev1-psk-xauth

and in the testsuite configs.

stangri · February 20, 2019, 12:30am

nope, same result.

Thanks, I was suspecting it may not be needed, however after removing this line and ipsec reload I still get: XAuth authentication of 'my-user-name' (myself) failed.

mpa · February 20, 2019, 12:49am

Are username/password correct? Can you authenticate with a different client software?

Turn up the charon debug level to see the contents of the config payloads, or to dump the encryption keys and use them with wireshark to decrypt IKE.

stangri · February 20, 2019, 12:56am

Yes, I can create a connection from macOS just fine.

Is the charondebug=all not enough? Should it dump extra debug info into syslog or somewhere else?

mpa · February 20, 2019, 12:31pm

It doesn't have any effect for me. I don't know which option will dump the config payloads; try charondebug="ike 4, enc 3" and see the logger documentation for more options.

I would suggest to look inside this message

with the help of charon logging or wireshark, check the contained username and password, and maybe compare it with the equivalent message sent by your MacOS client.

ipsec reload is OK where you used it (a conn section has changed), but note that it is not enough when you want to change the charon debug level. Use ipsec restart in this case.

Yes, it is sent to syslog by default. Keep logread -f running in another shell session to see it.
Charon can also send its log messages to a file; see the logger documentation.

These options are deprecated, they were replaced by leftauth=psk and leftauth2=xauth. They should not do any harm, but I would still suggest to remove them.

I believe this one is deprecated as well.

stangri · February 20, 2019, 7:56pm

It did dump some binary (possibly encrypted) blobs into the log, I can't figure out how to make use of them.

I'd probably need wireshark to make sense of the information I'm seeing, but setting it up exceeds the level of complexity I'm prepared to undertake to get strongswan working.

mpa · February 20, 2019, 9:03pm

These are the relevant parts (not encrypted):

generating TRANSACTION response .......... [ HASH CPRP(X_USER X_PWD) ]
generating payload of type CONFIGURATION_V1

generating payload of type CONFIGURATION_ATTRIBUTE_V1
attribute value has not fixed size
   => 10 bytes @ 0x7f7680001c40
   0: 78 61 75 74 68 2D 75 73 65 72                    xauth-user 

generating payload of type CONFIGURATION_ATTRIBUTE_V1
attribute value has not fixed size
   => 12 bytes @ 0x7f7680001c80
   0: 78 61 75 74 68 2D 73 65 63 72 65 74              xauth-secret

stangri · February 20, 2019, 10:45pm

Thank you, it was helpful in a way that I don't have these in the log.

But first of all, I've noticed this:
11:39:42 : 00[CFG] loaded EAP secret for my-user-name
Should it be treated as an EAP secret? Not an Xauth secret?

Now the records in the log immediately preceding the error are:

11:40:12 : 05[ENC] found payload of type HASH_V1
11:40:12 : 05[ENC] found payload of type CONFIGURATION_V1
11:40:12 : 05[ENC] parsed TRANSACTION request 39381261 [ HASH CPS(X_STATUS) ]
11:40:12 : 05[IKE] Hash => 20 bytes @ 0x016f8cb0
11:40:12 : 05[IKE] 0: 60 6F 58 FA B1 92 5E 2B 48 07 53 C6 00 07 73 11 `oX...^+H.S...s.
11:40:12 : 05[IKE] 16: 8C 60 A0 1B .`..
11:40:12 : 05[ENC] HASH received => 20 bytes @ 0x016fa5d0
11:40:12 : 05[ENC] 0: 60 6F 58 FA B1 92 5E 2B 48 07 53 C6 00 07 73 11 `oX...^+H.S...s.
11:40:12 : 05[ENC] 16: 8C 60 A0 1B .`..
11:40:12 : 05[ENC] HASH expected => 20 bytes @ 0x016f8cb0
11:40:12 : 05[ENC] 0: 60 6F 58 FA B1 92 5E 2B 48 07 53 C6 00 07 73 11 `oX...^+H.S...s.
11:40:12 : 05[ENC] 16: 8C 60 A0 1B .`..
11:40:12 : 05[IKE] next IV for MID 39381261 => 16 bytes @ 0x016fa550
11:40:12 : 05[IKE] 0: 38 75 28 2D E1 39 39 45 6F 7E CD 93 31 8B 95 02 8u(-.99Eo~..1...
11:40:12 : 05[IKE] XAuth authentication of 'my-user-name' (myself) failed

The hash expected and received look exactly the same, yet somethings failing -- any ideas?

mpa · February 20, 2019, 11:24pm

EAP and Xauth secrets are often used as synonyms within strongswan, so I guess this is OK. Xauth is IKEv1, EAP is IKEv2.

This is the final status returned by the server, too late in the protocol. Look for the preceding TRANSACTION response, generated by the client.

The matching hash confirms that the message was not damaged/manipulated in transit.
It is not relevant here.

stangri · February 20, 2019, 11:38pm

Ah, right, well, I see both my username and password in the log being added to the response. There are too many occurrences of them to sanitize both text and hex.

So the password is being picked up, but negotiation doesn't happen between my router and the server. Any ideas why? I'm very new to strongswan, out of my depth.