[strongSwan] ikev2: Tunnel established inspite of different phase 2 DH group
Good afternoon,
I am using StrongSwan 5.8.2. It is noticed that the tunnel comes up and starts
allowing traffic even though the DH group is different for esp in ipsec.conf:
Device 1: ipsec.conf
conn m1
type=tunnel
authby=secret
auto=add
keyexchange=ikev2
ike=aes256-sha512-modp1536!
aggressive=no
ikelifetime=3s
esp=aes256-sha256-modp1536!
lifetime=15s
right=91.0.0.3
rightid=m1_91.0.0.3
rightsubnet=10.10.9.0/24,192.168.61.0/24
left=91.0.0.2
leftid=m1_91.0.0.2
leftsubnet=192.168.9.0/24,192.168.51.0/24
On device 2 ipsec.conf:
conn m1
type=tunnel
authby=secret
auto=add
keyexchange=ikev2
ike=aes256-sha512-modp1536!
aggressive=no
ikelifetime=3s
esp=aes256-sha256-modp2048!
lifetime=15s
right=91.0.0.2
rightid=m1_91.0.0.2
rightsubnet=192.168.9.0/24,192.168.51.0/24
left=91.0.0.3
leftid=m1_91.0.0.3
leftsubnet=10.10.9.0/24,192.168.61.0/24
After the expiry of the lifetime, the CHILD_SA goes down due to proposal
mismatch, but till then traffic continues to flow.
As per my understanding in the quick mode negotiation for phase 2, the CHILD_SA
should not get built as the proposal should get rejected.
Log:
root@t1024rdb:/usr/local/etc# ipsec up m1
initiating IKE_SA m1[2] to 91.0.0.3
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP)
N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 91.0.0.2[500] to 91.0.0.3[500] (400 bytes)
received packet: from 91.0.0.3[500] to 91.0.0.2[500] (408 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP)
N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
selected proposal: IKE:AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536
authentication of 'm1_91.0.0.2' (myself) with pre-shared key
establishing CHILD_SA m1{5}
generating IKE_AUTH request 1 [ IDi N(INIT_CONTACT) IDr AUTH SA TSi TSr
N(MOBIKE_SUP) N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) N(MULT_AUTH)
N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
sending packet: from 91.0.0.2[4500] to 91.0.0.3[4500] (400 bytes)
received packet: from 91.0.0.3[4500] to 91.0.0.2[4500] (352 bytes)
parsed IKE_AUTH response 1 [ IDr AUTH SA TSi TSr N(AUTH_LFT) N(MOBIKE_SUP)
N(ADD_4_ADDR) N(ADD_4_ADDR) N(ADD_4_ADDR) ]
authentication of 'm1_91.0.0.3' with pre-shared key successful
IKE_SA m1[2] established between 91.0.0.2[m1_91.0.0.2]...91.0.0.3[m1_91.0.0.3]
scheduling reauthentication in -624s
maximum IKE_SA lifetime -84s
selected proposal: ESP:AES_CBC_256/HMAC_SHA2_256_128/NO_EXT_SEQ
CHILD_SA m1{5} established with SPIs c8bed58d_i c3d2c2e5_o and TS
192.168.9.0/24 192.168.51.0/24 === 10.10.9.0/24 192.168.61.0/24
connection 'm1' established successfully
root@t1024rdb:/usr/local/etc# ipsec statusall m1
Status of IKE charon daemon (strongSwan 5.8.2, Linux 4.1.35-rt41, ppc64):
uptime: 9 seconds, since Apr 01 14:05:34 2020
malloc: sbrk 2297856, mmap 0, used 314912, free 1982944
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0,
scheduled: 12
loaded plugins: charon aes des rc2 sha2 sha1 md5 mgf1 random nonce x509
revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem
fips-prf gmp curve25519 xcbc cmac hmac drbg attr kernel-netlink resolve
socket-default stroke vici updown xauth-generic counters
Listening IP addresses:
10.10.5.1
192.168.51.2
192.168.52.2
91.0.0.2
Connections:
m1: 91.0.0.2...91.0.0.3 IKEv2
m1: local: [m1_91.0.0.2] uses pre-shared key authentication
m1: remote: [m1_91.0.0.3] uses pre-shared key authentication
m1: child: 192.168.9.0/24 192.168.51.0/24 === 10.10.9.0/24
192.168.61.0/24 TUNNEL
Security Associations (2 up, 0 connecting):
m1[2]: ESTABLISHED 7 seconds ago,
91.0.0.2[m1_91.0.0.2]...91.0.0.3[m1_91.0.0.3]
m1[2]: IKEv2 SPIs: accd0f528860aa9e_i* e11f4d8d8bb4c717_r, pre-shared
key reauthentication in 24 minutes
m1[2]: IKE proposal:
AES_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_1536
m1{5}: INSTALLED, TUNNEL, reqid 2, ESP SPIs: c8bed58d_i c3d2c2e5_o
m1{5}: AES_CBC_256/HMAC_SHA2_256_128, 420 bytes_i (5 pkts, 1s ago),
420 bytes_o (5 pkts, 1s ago), rekeying active
m1{5}: 192.168.9.0/24 192.168.51.0/24 === 10.10.9.0/24
192.168.61.0/24
root@t1024rdb:/usr/local/etc# ipsec statusall m1
Status of IKE charon daemon (strongSwan 5.8.2, Linux 4.1.35-rt41, ppc64):
uptime: 21 seconds, since Apr 01 14:05:34 2020
malloc: sbrk 2297856, mmap 0, used 295952, free 2001904
Re: [strongSwan] Strongswan client support for the XAUTH_PASSCODE attribute
Hi,
AFAIR it doesn't/can't. I'm not sure though. You'd have to check.
Kind regards
Noel
Am 01.04.20 um 19:26 schrieb mnli...@frimail.net:
> Hi,
>
> But the NetworkManager plugin could prompt for a passcode couldn't it?
>
> Best regards,
>
> /Mikael
>
> On 2020-04-01 19:19, Noel Kuntze wrote:
>> Hi,
>>
>> Yw.
>>
>> There's also no support for dynamic prompting for EAP credentials.
>> I envisioned to implement that using VICI some time later. It'd be the
>> natural choice.
>> Switching to IKEv2 won't solve the problem for you right now.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 01.04.20 um 19:10 schrieb Mikael Nordstrom:
>>> OK,
>>>
>>> Thanks anyway for the quick reply.
>>>
>>> The Juniper has IKEv2 support and the RSA SecurID box has a built-in radius
>>> server
>>> so maybe that is the way to go with this.
>>>
>>> Thanks again,
>>>
>>> /Mikael
>>>
>>> On 2020-04-01 18:30, Noel Kuntze wrote:
Hi,
There's just no frontend to ask dynamically for such credentials yet.
You'd need to implement that, then you can dynamically prompt for the
passcode (after hooking up X_CODE the same way as X_USER is). Other than
that, there are no provisions for X_CODE or anything else. The code base
wouldn't be extended particularly for X_CODE because IKEv1 is deprecated.
Kind regards
Noel
Am 01.04.20 um 18:22 schrieb MN Lists:
> Hi,
>
> This is my first message to the list so sorry in advance if the answer is
> obvious or well-known.
> Also, sorry if my terminology is messed up, hopefully you will understand
> my issue.
>
> I have a Juniper ScreenOS gateway that does IKEv1 VPNs with RSA and then
> XAuth authentication
> towards an RSA SecurID box. SecurID is an MFA implementation with
> hardware tokens that display
> a new 6-digit number every 60 seconds.
>
> Clients can connect to it from Mac OS X with a client called NCP Secure
> Entry and from Windows
> with the Shrewsoft client. In the past vpnc on Linux was working but as
> it has not been developed
> since a long time and doesn't support newer algorithms, I'm looking for
> an alternative and
> Strongswan looks promising.
>
> So far I have been able to get IKE phase1 up but it fails on XAuth. It
> looks as if the gateway
> is sending a request for X_USER and X_CODE but charon is responding with
> just X_USER. Here is
> a log excerpt:
>
> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] authentication of
> 'gw.example.com' with RSA_EMSA_PKCS1_NULL successful
> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] activating new tasks
> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] nothing to initiate
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[NET] received packet:
> from 212.112.174.86[4500] to 172.20.33.34[4500] (92 bytes)
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID
> 3123281050 => 16 bytes @ 0x7f0304001ed0
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 51 2C 54 DC D7
> 31 2D 5F 5D 84 00 10 81 42 88 2B Q,T..1-_]B.+
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] parsed TRANSACTION
> request 3123281050 [ HASH CPRQ(X_TYPE X_USER X_CODE) ]
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @
> 0x7f03040026b0
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 87 1C CA 53 F3
> 1A 81 40 E3 68 E8 78 EA 1C CF CE ...S...@.h.x
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] 16: B3 53 17 C6 8C
> 1B E7 F3 CA DD 50 DC F7 60 97 DD .SP..`..
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID
> 3123281050 => 16 bytes @ 0x7f02f8005600
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 33 C2 3E 9C 64
> 14 4C 87 85 C2 1B 26 45 84 2D FF 3.>.d.L
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @
> 0x7f0304001ed0
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: CB A7 62 8F 3F
> E0 98 7B 92 75 7F AE 70 B6 E4 0C ..b.?..{.u..p...
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] 16: 9E B8 66 14 91
> 79 63 45 5C 9E B1 EF FD B3 5F B9 ..f..ycE\._.
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] generating
> TRANSACTION response 3123281050 [ HASH CPRP(X_USER) ]
>
> Relevant swanctl authentication and secret sections are:
>
> connections {
> conn1 {
> local-2 {
> auth = xauth-generic
> xauth_id = xauthuser
> }
> }
> }
>
> secrets {
> xauth-1 {
> id-1 = xauthuser
> secret = 1234556677
> }
>
> Is this a well known deficiency in strongswan or is there some
> configuration that can make
> this work?
Re: [strongSwan] Strongswan client support for the XAUTH_PASSCODE attribute
Hi,
Yw.
There's also no support for dynamic prompting for EAP credentials.
I envisioned to implement that using VICI some time later. It'd be the natural
choice.
Switching to IKEv2 won't solve the problem for you right now.
Kind regards
Noel
Am 01.04.20 um 19:10 schrieb Mikael Nordstrom:
> OK,
>
> Thanks anyway for the quick reply.
>
> The Juniper has IKEv2 support and the RSA SecurID box has a built-in radius
> server
> so maybe that is the way to go with this.
>
> Thanks again,
>
> /Mikael
>
> On 2020-04-01 18:30, Noel Kuntze wrote:
>> Hi,
>>
>> There's just no frontend to ask dynamically for such credentials yet. You'd
>> need to implement that, then you can dynamically prompt for the passcode
>> (after hooking up X_CODE the same way as X_USER is). Other than that, there
>> are no provisions for X_CODE or anything else. The code base wouldn't be
>> extended particularly for X_CODE because IKEv1 is deprecated.
>>
>> Kind regards
>>
>> Noel
>>
>> Am 01.04.20 um 18:22 schrieb MN Lists:
>>> Hi,
>>>
>>> This is my first message to the list so sorry in advance if the answer is
>>> obvious or well-known.
>>> Also, sorry if my terminology is messed up, hopefully you will understand
>>> my issue.
>>>
>>> I have a Juniper ScreenOS gateway that does IKEv1 VPNs with RSA and then
>>> XAuth authentication
>>> towards an RSA SecurID box. SecurID is an MFA implementation with hardware
>>> tokens that display
>>> a new 6-digit number every 60 seconds.
>>>
>>> Clients can connect to it from Mac OS X with a client called NCP Secure
>>> Entry and from Windows
>>> with the Shrewsoft client. In the past vpnc on Linux was working but as it
>>> has not been developed
>>> since a long time and doesn't support newer algorithms, I'm looking for an
>>> alternative and
>>> Strongswan looks promising.
>>>
>>> So far I have been able to get IKE phase1 up but it fails on XAuth. It
>>> looks as if the gateway
>>> is sending a request for X_USER and X_CODE but charon is responding with
>>> just X_USER. Here is
>>> a log excerpt:
>>>
>>> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] authentication of
>>> 'gw.example.com' with RSA_EMSA_PKCS1_NULL successful
>>> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] activating new tasks
>>> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] nothing to initiate
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[NET] received packet: from
>>> 212.112.174.86[4500] to 172.20.33.34[4500] (92 bytes)
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID
>>> 3123281050 => 16 bytes @ 0x7f0304001ed0
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 51 2C 54 DC D7
>>> 31 2D 5F 5D 84 00 10 81 42 88 2B Q,T..1-_]B.+
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] parsed TRANSACTION
>>> request 3123281050 [ HASH CPRQ(X_TYPE X_USER X_CODE) ]
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @
>>> 0x7f03040026b0
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 87 1C CA 53 F3
>>> 1A 81 40 E3 68 E8 78 EA 1C CF CE ...S...@.h.x
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] 16: B3 53 17 C6 8C
>>> 1B E7 F3 CA DD 50 DC F7 60 97 DD .SP..`..
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID
>>> 3123281050 => 16 bytes @ 0x7f02f8005600
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 33 C2 3E 9C 64
>>> 14 4C 87 85 C2 1B 26 45 84 2D FF 3.>.d.L
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @
>>> 0x7f0304001ed0
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: CB A7 62 8F 3F
>>> E0 98 7B 92 75 7F AE 70 B6 E4 0C ..b.?..{.u..p...
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] 16: 9E B8 66 14 91
>>> 79 63 45 5C 9E B1 EF FD B3 5F B9 ..f..ycE\._.
>>> apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] generating TRANSACTION
>>> response 3123281050 [ HASH CPRP(X_USER) ]
>>>
>>> Relevant swanctl authentication and secret sections are:
>>>
>>> connections {
>>> conn1 {
>>> local-2 {
>>> auth = xauth-generic
>>> xauth_id = xauthuser
>>> }
>>> }
>>> }
>>>
>>> secrets {
>>> xauth-1 {
>>> id-1 = xauthuser
>>> secret = 1234556677
>>> }
>>>
>>> Is this a well known deficiency in strongswan or is there some
>>> configuration that can make
>>> this work?
>>>
>>> I'm happy to supply any further information that could help resolve this.
>>>
>>> Many thanks,
>>> /Mikael
>>>
>>
signature.asc
Description: OpenPGP digital signature
Re: [strongSwan] Strongswan client support for the XAUTH_PASSCODE attribute
Hi,
But the NetworkManager plugin could prompt for a passcode couldn't it?
Best regards,
/Mikael
On 2020-04-01 19:19, Noel Kuntze wrote:
> Hi,
>
> Yw.
>
> There's also no support for dynamic prompting for EAP credentials.
> I envisioned to implement that using VICI some time later. It'd be the
> natural choice.
> Switching to IKEv2 won't solve the problem for you right now.
>
> Kind regards
>
> Noel
>
> Am 01.04.20 um 19:10 schrieb Mikael Nordstrom:
>> OK,
>>
>> Thanks anyway for the quick reply.
>>
>> The Juniper has IKEv2 support and the RSA SecurID box has a built-in radius
>> server
>> so maybe that is the way to go with this.
>>
>> Thanks again,
>>
>> /Mikael
>>
>> On 2020-04-01 18:30, Noel Kuntze wrote:
>>> Hi,
>>>
>>> There's just no frontend to ask dynamically for such credentials yet. You'd
>>> need to implement that, then you can dynamically prompt for the passcode
>>> (after hooking up X_CODE the same way as X_USER is). Other than that, there
>>> are no provisions for X_CODE or anything else. The code base wouldn't be
>>> extended particularly for X_CODE because IKEv1 is deprecated.
>>>
>>> Kind regards
>>>
>>> Noel
>>>
>>> Am 01.04.20 um 18:22 schrieb MN Lists:
Hi,
This is my first message to the list so sorry in advance if the answer is
obvious or well-known.
Also, sorry if my terminology is messed up, hopefully you will understand
my issue.
I have a Juniper ScreenOS gateway that does IKEv1 VPNs with RSA and then
XAuth authentication
towards an RSA SecurID box. SecurID is an MFA implementation with hardware
tokens that display
a new 6-digit number every 60 seconds.
Clients can connect to it from Mac OS X with a client called NCP Secure
Entry and from Windows
with the Shrewsoft client. In the past vpnc on Linux was working but as it
has not been developed
since a long time and doesn't support newer algorithms, I'm looking for an
alternative and
Strongswan looks promising.
So far I have been able to get IKE phase1 up but it fails on XAuth. It
looks as if the gateway
is sending a request for X_USER and X_CODE but charon is responding with
just X_USER. Here is
a log excerpt:
apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] authentication of
'gw.example.com' with RSA_EMSA_PKCS1_NULL successful
apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] activating new tasks
apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] nothing to initiate
apr 01 17:48:11 phoenix charon-debug[21177]: 07[NET] received packet: from
212.112.174.86[4500] to 172.20.33.34[4500] (92 bytes)
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID
3123281050 => 16 bytes @ 0x7f0304001ed0
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 51 2C 54 DC D7
31 2D 5F 5D 84 00 10 81 42 88 2B Q,T..1-_]B.+
apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] parsed TRANSACTION
request 3123281050 [ HASH CPRQ(X_TYPE X_USER X_CODE) ]
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @
0x7f03040026b0
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 87 1C CA 53 F3
1A 81 40 E3 68 E8 78 EA 1C CF CE ...S...@.h.x
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] 16: B3 53 17 C6 8C
1B E7 F3 CA DD 50 DC F7 60 97 DD .SP..`..
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID
3123281050 => 16 bytes @ 0x7f02f8005600
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 33 C2 3E 9C 64
14 4C 87 85 C2 1B 26 45 84 2D FF 3.>.d.L
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @
0x7f0304001ed0
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: CB A7 62 8F 3F
E0 98 7B 92 75 7F AE 70 B6 E4 0C ..b.?..{.u..p...
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] 16: 9E B8 66 14 91
79 63 45 5C 9E B1 EF FD B3 5F B9 ..f..ycE\._.
apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] generating
TRANSACTION response 3123281050 [ HASH CPRP(X_USER) ]
Relevant swanctl authentication and secret sections are:
connections {
conn1 {
local-2 {
auth = xauth-generic
xauth_id = xauthuser
}
}
}
secrets {
xauth-1 {
id-1 = xauthuser
secret = 1234556677
}
Is this a well known deficiency in strongswan or is there some
configuration that can make
this work?
I'm happy to supply any further information that could help resolve this.
Many thanks,
/Mikael
>>>
>
Re: [strongSwan] Strongswan client support for the XAUTH_PASSCODE attribute
Hi,
There's just no frontend to ask dynamically for such credentials yet. You'd
need to implement that, then you can dynamically prompt for the passcode (after
hooking up X_CODE the same way as X_USER is). Other than that, there are no
provisions for X_CODE or anything else. The code base wouldn't be extended
particularly for X_CODE because IKEv1 is deprecated.
Kind regards
Noel
Am 01.04.20 um 18:22 schrieb MN Lists:
> Hi,
>
> This is my first message to the list so sorry in advance if the answer is
> obvious or well-known.
> Also, sorry if my terminology is messed up, hopefully you will understand my
> issue.
>
> I have a Juniper ScreenOS gateway that does IKEv1 VPNs with RSA and then
> XAuth authentication
> towards an RSA SecurID box. SecurID is an MFA implementation with hardware
> tokens that display
> a new 6-digit number every 60 seconds.
>
> Clients can connect to it from Mac OS X with a client called NCP Secure Entry
> and from Windows
> with the Shrewsoft client. In the past vpnc on Linux was working but as it
> has not been developed
> since a long time and doesn't support newer algorithms, I'm looking for an
> alternative and
> Strongswan looks promising.
>
> So far I have been able to get IKE phase1 up but it fails on XAuth. It looks
> as if the gateway
> is sending a request for X_USER and X_CODE but charon is responding with just
> X_USER. Here is
> a log excerpt:
>
> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] authentication of
> 'gw.example.com' with RSA_EMSA_PKCS1_NULL successful
> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] activating new tasks
> apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] nothing to initiate
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[NET] received packet: from
> 212.112.174.86[4500] to 172.20.33.34[4500] (92 bytes)
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID
> 3123281050 => 16 bytes @ 0x7f0304001ed0
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 51 2C 54 DC D7 31
> 2D 5F 5D 84 00 10 81 42 88 2B Q,T..1-_]B.+
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] parsed TRANSACTION
> request 3123281050 [ HASH CPRQ(X_TYPE X_USER X_CODE) ]
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @
> 0x7f03040026b0
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 87 1C CA 53 F3 1A
> 81 40 E3 68 E8 78 EA 1C CF CE ...S...@.h.x
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] 16: B3 53 17 C6 8C 1B
> E7 F3 CA DD 50 DC F7 60 97 DD .SP..`..
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID
> 3123281050 => 16 bytes @ 0x7f02f8005600
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 33 C2 3E 9C 64 14
> 4C 87 85 C2 1B 26 45 84 2D FF 3.>.d.L
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @
> 0x7f0304001ed0
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: CB A7 62 8F 3F E0
> 98 7B 92 75 7F AE 70 B6 E4 0C ..b.?..{.u..p...
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] 16: 9E B8 66 14 91 79
> 63 45 5C 9E B1 EF FD B3 5F B9 ..f..ycE\._.
> apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] generating TRANSACTION
> response 3123281050 [ HASH CPRP(X_USER) ]
>
> Relevant swanctl authentication and secret sections are:
>
> connections {
> conn1 {
> local-2 {
> auth = xauth-generic
> xauth_id = xauthuser
> }
> }
> }
>
> secrets {
> xauth-1 {
> id-1 = xauthuser
> secret = 1234556677
> }
>
> Is this a well known deficiency in strongswan or is there some configuration
> that can make
> this work?
>
> I'm happy to supply any further information that could help resolve this.
>
> Many thanks,
> /Mikael
>
signature.asc
Description: OpenPGP digital signature
[strongSwan] Strongswan client support for the XAUTH_PASSCODE attribute
Hi,
This is my first message to the list so sorry in advance if the answer is
obvious or well-known.
Also, sorry if my terminology is messed up, hopefully you will understand my
issue.
I have a Juniper ScreenOS gateway that does IKEv1 VPNs with RSA and then XAuth
authentication
towards an RSA SecurID box. SecurID is an MFA implementation with hardware
tokens that display
a new 6-digit number every 60 seconds.
Clients can connect to it from Mac OS X with a client called NCP Secure Entry
and from Windows
with the Shrewsoft client. In the past vpnc on Linux was working but as it has
not been developed
since a long time and doesn't support newer algorithms, I'm looking for an
alternative and
Strongswan looks promising.
So far I have been able to get IKE phase1 up but it fails on XAuth. It looks as
if the gateway
is sending a request for X_USER and X_CODE but charon is responding with just
X_USER. Here is
a log excerpt:
apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] authentication of
'gw.example.com' with RSA_EMSA_PKCS1_NULL successful
apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] activating new tasks
apr 01 17:48:08 phoenix charon-debug[21177]: 02[IKE] nothing to initiate
apr 01 17:48:11 phoenix charon-debug[21177]: 07[NET] received packet: from
212.112.174.86[4500] to 172.20.33.34[4500] (92 bytes)
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID 3123281050
=> 16 bytes @ 0x7f0304001ed0
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 51 2C 54 DC D7 31 2D
5F 5D 84 00 10 81 42 88 2B Q,T..1-_]B.+
apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] parsed TRANSACTION request
3123281050 [ HASH CPRQ(X_TYPE X_USER X_CODE) ]
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @
0x7f03040026b0
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 87 1C CA 53 F3 1A 81
40 E3 68 E8 78 EA 1C CF CE ...S...@.h.x
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] 16: B3 53 17 C6 8C 1B E7
F3 CA DD 50 DC F7 60 97 DD .SP..`..
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] next IV for MID 3123281050
=> 16 bytes @ 0x7f02f8005600
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: 33 C2 3E 9C 64 14 4C
87 85 C2 1B 26 45 84 2D FF 3.>.d.L
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] Hash => 32 bytes @
0x7f0304001ed0
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE]0: CB A7 62 8F 3F E0 98
7B 92 75 7F AE 70 B6 E4 0C ..b.?..{.u..p...
apr 01 17:48:11 phoenix charon-debug[21177]: 07[IKE] 16: 9E B8 66 14 91 79 63
45 5C 9E B1 EF FD B3 5F B9 ..f..ycE\._.
apr 01 17:48:11 phoenix charon-debug[21177]: 07[ENC] generating TRANSACTION
response 3123281050 [ HASH CPRP(X_USER) ]
Relevant swanctl authentication and secret sections are:
connections {
conn1 {
local-2 {
auth = xauth-generic
xauth_id = xauthuser
}
}
}
secrets {
xauth-1 {
id-1 = xauthuser
secret = 1234556677
}
Is this a well known deficiency in strongswan or is there some configuration
that can make
this work?
I'm happy to supply any further information that could help resolve this.
Many thanks,
/Mikael
signature.asc
Description: OpenPGP digital signature
