[Swan] Libreswan client to Juniper XAUTH + ModeCfg (was:Libreswan and USER FQDN IKE IDs)
mnlists at frimail.net
mnlists at frimail.net
Wed Mar 25 13:42:53 UTC 2020
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 at 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 at 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 at 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
More information about the Swan
mailing list