Changed subject on this thread... On 2020-03-21 19:38, MN Lists wrote: > On 2020-03-21 02:32, Paul Wouters wrote: >> On Fri, 20 Mar 2020, MN Lists wrote: >> >>>> try: ipsec whack --initiate --name <con> >>>> You can also, if you put the leftusername= back, add the password to >>>> /etc/ipsec.secrets using: >>>> >>>> @yourxauthname : XAUTH "password" >>> >>> Both these actions gave the same result. >> >>>> Seems the other end did not send a password request. Something else >>>> might be wrong. You have to ask the other endpoint what error they >>>> see. >>> >>> After diving in to the logs, I found the following: >>> Mar 20 11:07:49.073524: | Received Cisco XAUTH type: Generic >>> Mar 20 11:07:49.073529: | ****parse ISAKMP ModeCfg attribute: >>> Mar 20 11:07:49.073533: | ModeCfg attr type: XAUTH-USER-NAME (0x4089) >>> Mar 20 11:07:49.073538: | length/value: 0 (0x0) >>> Mar 20 11:07:49.073542: | Received Cisco XAUTH username >>> Mar 20 11:07:49.073547: | ****parse ISAKMP ModeCfg attribute: >>> Mar 20 11:07:49.073551: | ModeCfg attr type: XAUTH-PASSCODE (0x408b) >>> Mar 20 11:07:49.073556: | length/value: 0 (0x0) >>> Mar 20 11:07:49.073561: | Unsupported XAUTH (inI0) long attribute >>> XAUTH-PASSCODE received. >>> >>> It looks like the gateway is sending a request for an XAUTH-PASSCODE >>> attribute which ipsec does >>> not support. >> >> Based on >> https://tools.ietf.org/html/draft-beaulieu-ike-xauth-02#section-6.2 >> it looks like it is expecting some kind of OTP reply from a hardware or >> software token, and not a static password? So in that case you cannot >> store the password in the secrets file. > > Correct, in our case the OTP is a concatenation of a 4-8 character > PIN/alphanumeric password and a 6-digit number from an RSA SecurID > hardware token, like this one: > https://en.wikipedia.org/wiki/RSA_SecurID. The number changes every 60 > seconds so the passcode entry should preferably be done interactively. >> >> Is your password static? We could patch the code to handle >> XAUTH-PASSCODE the same as XAUTH-USER-PASSWORD ? That would >> allow you to put it in the secrets file if static, and allow >> you to type it in uing ipsec whack --initiate --name <conn> > > The passcode is not static. As described above, it consists of a static > part and a dynamic part. If we had to enter it into the secrets file, > it would have to be done within 60 seconds of it changing on the token. > It could be done but it would be rather inconvenient. > Update: I'm not a coder so this may have broken something but as an experiment I replaced all occurrences of XAUTH-USER-PASSWORD with XAUTH-PASSCODE in ikev1_xauth.c and re-compiled. This had the effect that I could get through the XAUTH authentication. I even got a password prompt when there was no password in the secrets file. On the authentication server, the authentication was approved.
Now, I'm having ModeCfg issues. the client received this payload: Mar 25 14:09:09.890911: | HASH(1) PRF sha2_256 update M-ID-bytes@0x7ffd12aa2ffc (length 4) Mar 25 14:09:09.890919: | 81 71 59 87 Mar 25 14:09:09.890929: | HASH(1) PRF sha2_256 update payload-bytes@0x55b304aa4108 (length 40) Mar 25 14:09:09.890938: | 00 00 00 28 03 00 5f 4b 00 01 00 04 0a 14 33 28 Mar 25 14:09:09.890945: | 00 02 00 04 ff ff ff ff 00 03 00 04 0a 14 00 20 Mar 25 14:09:09.890953: | 00 03 00 04 0a 14 00 24 Mar 25 14:09:09.890973: | HASH(1) PRF sha2_256 final-bytes@0x7ffd12aa3088 (length 32) Mar 25 14:09:09.890982: | fb 19 ed 78 f8 b5 bc b6 42 9d f4 4c 74 f8 c3 c5 Mar 25 14:09:09.890990: | 6f cb 5e 3a 86 88 fb 72 29 ae 6e 43 25 3e ae f4 Mar 25 14:09:09.890998: | xauth_inI0 HASH(1): Mar 25 14:09:09.891006: | fb 19 ed 78 f8 b5 bc b6 42 9d f4 4c 74 f8 c3 c5 Mar 25 14:09:09.891014: | 6f cb 5e 3a 86 88 fb 72 29 ae 6e 43 25 3e ae f4 Mar 25 14:09:09.891023: | received 'xauth_inI0' message HASH(1) data ok I can see the offered IP address, netmask and DNS servers in the payload but when libreswan processes it, it looks as if the values are ignored: Mar 25 14:09:09.891135: | arrived in xauth_inI0 Mar 25 14:09:09.891144: | ****parse ISAKMP ModeCfg attribute: Mar 25 14:09:09.891152: | ModeCfg attr type: INTERNAL_IP4_ADDRESS (0x1) Mar 25 14:09:09.891162: | length/value: 4 (00 04) Mar 25 14:09:09.891170: | Received Cisco Internal IPv4 address Mar 25 14:09:09.891178: | ****parse ISAKMP ModeCfg attribute: Mar 25 14:09:09.891186: | ModeCfg attr type: INTERNAL_IP4_NETMASK (0x2) Mar 25 14:09:09.891196: | length/value: 4 (00 04) Mar 25 14:09:09.891203: | Received Cisco Internal IPv4 netmask Mar 25 14:09:09.891212: | ****parse ISAKMP ModeCfg attribute: Mar 25 14:09:09.891220: | ModeCfg attr type: INTERNAL_IP4_DNS (0x3) Mar 25 14:09:09.891229: | length/value: 4 (00 04) Mar 25 14:09:09.891237: | Received Cisco IPv4 DNS info Mar 25 14:09:09.891245: | ****parse ISAKMP ModeCfg attribute: Mar 25 14:09:09.891253: | ModeCfg attr type: INTERNAL_IP4_DNS (0x3) Mar 25 14:09:09.891263: | length/value: 4 (00 04) Mar 25 14:09:09.891270: | Received Cisco IPv4 DNS info Mar 25 14:09:09.891279: | complete v1 state transition with STF_FAIL I have tried with modecfgpull=yes, modecfgpull=no and no modecfgpull setting, neither of which result in a different outcome. I have also tried with remote-peer-type=cisco and without it. Could this point to a problem with the structure of the incoming payload? Thanks, /Mikael _______________________________________________ Swan mailing list [email protected] https://lists.libreswan.org/mailman/listinfo/swan
