received NO_PROPOSAL CHOSEN error notify
Resolution:
No change required
Description
I am trying to configure my client on rasppyberry pi for a remote VPN server(Shrew) provided with the following information.
I am trying to configure my client using VPN (strongswan) to access the remote server whose DNS is
vpngw.fh-kempten.de
Details of my remote VPN Server are:
Authentication Method = Mutual +XAuth PSK =**** Phase 1 Exchange Type = aggressive DH exchange = group2 Cipher Algorithm = 3ds Hash Algorithm = md5 Key life time limit = 28800secs Phase 2 Tensform Algorithm = esp-3des HMAC Algorithm = md5 PFC exchange = Auto compress Algorithm = disabled Key life time limit = 28800secs General Host Name or IP = vpngw.fh-kempten.de port = 500 Auto configuration = IKE conf. pull MTU = 1400 Adapter mode = use a virtual adapter and assigned address Client firewall options NAT traversal = enable NAT traversal port = 4500 Keep alive packet rate = 15s IKE fragmentation = enable Maximum packet siye = 540 bytes This is all info I have related to my VPN Server(shrew) which is a remote server.
My ipsec configuration file looks like the following (Recommend me any changes if needed?)
config setup
conn ikev1-psk-xauth
ikelifetime=28800s
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
authby=secret
ike = 3des-md5-modp1024!
esp = 3des-md5-modp1024!
modeconfig = pull
aggressive = yes
fragmentation=yes
#keyexchange = ikev2
type = transport
left = 10.48.130.136
leftauth = psk
# leftauth2 = xauth
leftprotoport=17/1701
rightprotoport=17/1701
right = 193.174.193.64
rightauth = psk
# rightauth2 =
auto = add
My ipsec.secrete file looks like¶
%any : PSK "PSK_OF_MY_REMOTE_VPN"
With above configuration, when I run my ipsec command i get the following error¶
sudo ipsec up ikev1-psk-xauth
initiating Aggressive Mode IKE_SA ikev1-psk-xauth[1] to 193.174.193.64
generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]
sending packet: from 10.48.130.136[500] to 193.174.193.64[500] (356 bytes)
received packet: from 193.174.193.64[500] to 10.48.130.136[500] (92 bytes)
parsed INFORMATIONAL_V1 request 0 [ N(NO_PROP) ]
received NO_PROPOSAL_CHOSEN error notify
establishing connection 'ikev1-psk-xauth' failed
in
Remember, the mode of my configuration should be aggressive but when I try to do with aggressive=no in ipsec.config. I get the following output:
sudo ipsec up ikev1-psk-xauth
initiating Main Mode IKE_SA ikev1-psk-xauth[1] to 193.174.193.64
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 10.48.130.136[500] to 193.174.193.64[500] (176 bytes)
received packet: from 193.174.193.64[500] to 10.48.130.136[500] (124 bytes)
parsed ID_PROT response 0 [ SA V V ]
received draft-ietf-ipsec-nat-t-ike-02n vendor ID
received FRAGMENTATION vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 10.48.130.136[500] to 193.174.193.64[500] (236 bytes)
received packet: from 193.174.193.64[500] to 10.48.130.136[500] (296 bytes)
parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
received Cisco Unity vendor ID
received XAuth vendor ID
received unknown vendor ID: 89:cd:2f:bc:5d:ef:78:c5:89:27:99:2c:3a:98:ac:85
received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (92 bytes)
received packet: from 193.174.193.64[4500] to 10.48.130.136[4500] (84 bytes)
parsed ID_PROT response 0 [ ID HASH V ]
received DPD vendor ID
IKE_SA ikev1-psk-xauth[1] established between 10.48.130.136[10.48.130.136]...193.174.193.64[193.174.193.64]
scheduling reauthentication in 28562s
maximum IKE_SA lifetime 28742s
generating QUICK_MODE request 3081517716 [ HASH SA No KE ID ID NAT-OA NAT-OA ]
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (324 bytes)
received packet: from 193.174.193.64[4500] to 10.48.130.136[4500] (84 bytes)
parsed INFORMATIONAL_V1 request 1042226567 [ HASH N(NO_PROP) ]
received NO_PROPOSAL_CHOSEN error notify
establishing connection 'ikev1-psk-xauth' failed
My motivation is to access the shared drive which is present on the remote VPN server
I am looking for help as I am newbie to this stuff and already scratched my head on it for about 3 weeks before posting here. so
my expectations from this forum are very high.
Looking forward to the kind responses:)
Thanks in advance!!
History
#1
Updated by Tobias Brunner almost 4 years ago
- Description updated (diff)
- Category changed from libstrongswan to configuration
- Status changed from New to Feedback
- Priority changed from Immediate to Normal
We discussed this on serverfault.com already. Apparently, not successfully.
If you receive a NO_PROPOSAL_CHOSEN notify it means the peers is not happy about any of the algorithms or authentication methods. In your case it might be related to this:
# leftauth2 = xauth
If you only propose PSK authentication and not PSK+XAuth the server is probably not happy about it. So you want to set leftauth2 to xauth.
#2
Updated by Saqib Shakeel almost 4 years ago
Okay, Thanks for your reply. whith
leftauth2=xauth , what changes are expected in
ipsec.secrets #4
Updated by Saqib Shakeel almost 4 years ago
Now after following your suggestion, I am getting this error
initiating Aggressive Mode IKE_SA ikev1-psk-xauth[1] to 193.174.193.64
generating AGGRESSIVE request 0 [ SA KE No ID V V V V V ]
sending packet: from 10.48.130.136[500] to 193.174.193.64[500] (356 bytes)
received packet: from 193.174.193.64[500] to 10.48.130.136[500] (404 bytes)
parsed AGGRESSIVE response 0 [ SA KE No ID HASH V V V NAT-D NAT-D V V ]
received Cisco Unity vendor ID
received XAuth vendor ID
received draft-ietf-ipsec-nat-t-ike-02n vendor ID
received FRAGMENTATION vendor ID
received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
*calculated HASH does not match HASH payload*
generating INFORMATIONAL_V1 request 1622174910 [ HASH N(AUTH_FAILED) ]
sending packet: from 10.48.130.136[500] to 193.174.193.64[500] (84 bytes)
establishing connection 'ikev1-psk-xauth' failed
#5
Updated by Saqib Shakeel almost 4 years ago
Update:¶
When I run it by commenting aggressive mode. It gives me the following output..
$ sudo ipsec up ikev1-psk-xauth
initiating Main Mode IKE_SA ikev1-psk-xauth[1] to 193.174.193.64
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 10.48.130.136[500] to 193.174.193.64[500] (176 bytes)
received packet: from 193.174.193.64[500] to 10.48.130.136[500] (124 bytes)
parsed ID_PROT response 0 [ SA V V ]
received draft-ietf-ipsec-nat-t-ike-02n vendor ID
received FRAGMENTATION vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 10.48.130.136[500] to 193.174.193.64[500] (236 bytes)
received packet: from 193.174.193.64[500] to 10.48.130.136[500] (296 bytes)
parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
received Cisco Unity vendor ID
received XAuth vendor ID
received unknown vendor ID: fb:ee:13:63:2b:d4:bb:25:f5:57:77:e3:08:52:bd:64
received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (92 bytes)
received packet: from 193.174.193.64[4500] to 10.48.130.136[4500] (84 bytes)
parsed ID_PROT response 0 [ ID HASH V ]
received DPD vendor ID
received packet: from 193.174.193.64[4500] to 10.48.130.136[4500] (68 bytes)
parsed TRANSACTION request 3248835481 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
no XAuth method found
generating TRANSACTION response 3248835481 [ HASH CP ]
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (60 bytes)
received packet: from 193.174.193.64[4500] to 10.48.130.136[4500] (68 bytes)
parsed TRANSACTION request 3615668993 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
no XAuth method found
generating TRANSACTION response 3615668993 [ HASH CP ]
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (60 bytes)
received packet: from 193.174.193.64[4500] to 10.48.130.136[4500] (68 bytes)
parsed TRANSACTION request 3955024272 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
no XAuth method found
generating TRANSACTION response 3955024272 [ HASH CP ]
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (60 bytes)
received packet: from 193.174.193.64[4500] to 10.48.130.136[4500] (60 bytes)
parsed TRANSACTION request 1994187572 [ HASH CPS(X_STATUS) ]
no XAuth method found
generating TRANSACTION response 1994187572 [ HASH CP ]
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (60 bytes)
received packet: from 193.174.193.64[4500] to 10.48.130.136[4500] (60 bytes)
received retransmit of request with ID 1994187572, retransmitting response
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (60 bytes)
received packet: from 193.174.193.64[4500] to 10.48.130.136[4500] (60 bytes)
received retransmit of request with ID 1994187572, retransmitting response
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (60 bytes)
received packet: from 193.174.193.64[4500] to 10.48.130.136[4500] (60 bytes)
received retransmit of request with ID 1994187572, retransmitting response
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (60 bytes)
received packet: from 193.174.193.64[4500] to 10.48.130.136[4500] (76 bytes)
queueing INFORMATIONAL_V1 request as tasks still active
sending keep alive to 193.174.193.64[4500]
peer did not initiate expected exchange, reestablishing IKE_SA
reinitiating IKE_SA ikev1-psk-xauth[1]
initiating Main Mode IKE_SA ikev1-psk-xauth[1] to 193.174.193.64
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (176 bytes)
establishing connection 'ikev1-psk-xauth' failed
1. now I get the error
<pre><code class="text">
no XAuth method found
peer did not initiate expected exchange, reestablishing IKE_SA
</code></pre>
and
2. I want to know if server is set on aggressive mode , our client must also have aggressive mode or we can use main mode as well?
#6
Updated by Saqib Shakeel almost 4 years ago
Update :
After changing settings in the secrete file
10.48.130.136 %any : PSK "Password_of_my_Wifi"
Myid@University_Server : XAUTH "My_Password"
I got this output(Remember the default server setting for aggressive is on but the following output is without aggressive)
initiating Main Mode IKE_SA ikev1-psk-xauth[1] to 193.174.193.64
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 10.48.130.136[500] to 193.174.193.64[500] (176 bytes)
received packet: from 193.174.193.64[500] to 10.48.130.136[500] (124 bytes)
parsed ID_PROT response 0 [ SA V V ]
received draft-ietf-ipsec-nat-t-ike-02n vendor ID
received FRAGMENTATION vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 10.48.130.136[500] to 193.174.193.64[500] (236 bytes)
received packet: from 193.174.193.64[500] to 10.48.130.136[500] (296 bytes)
parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
received Cisco Unity vendor ID
received XAuth vendor ID
received unknown vendor ID: 11:63:12:e1:ba:1f:31:64:d1:72:8e:55:6a:14:c4:ef
received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (92 bytes)
sending retransmit 1 of request message ID 0, seq 3
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (92 bytes)
received packet: from 193.174.193.64[500] to 10.48.130.136[500] (296 bytes)
received retransmit of response with ID 0, but next request already sent
sending retransmit 2 of request message ID 0, seq 3
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (92 bytes)
received packet: from 193.174.193.64[500] to 10.48.130.136[500] (296 bytes)
received retransmit of response with ID 0, but next request already sent
received packet: from 193.174.193.64[500] to 10.48.130.136[500] (296 bytes)
received retransmit of response with ID 0, but next request already sent
sending retransmit 3 of request message ID 0, seq 3
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (92 bytes)
received packet: from 193.174.193.64[500] to 10.48.130.136[500] (76 bytes)
invalid HASH_V1 payload length, decryption failed?
could not decrypt payloads
message parsing failed
ignore malformed INFORMATIONAL request
INFORMATIONAL_V1 request with message ID 3083439986 processing failed
sending keep alive to 193.174.193.64[4500]
sending retransmit 4 of request message ID 0, seq 3
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (92 bytes)
sending keep alive to 193.174.193.64[4500]
sending keep alive to 193.174.193.64[4500]
sending retransmit 5 of request message ID 0, seq 3
sending packet: from 10.48.130.136[4500] to 193.174.193.64[4500] (92 bytes)
sending keep alive to 193.174.193.64[4500]
sending keep alive to 193.174.193.64[4500]
sending keep alive to 193.174.193.64[4500]
giving up after 5 retransmits
establishing IKE_SA failed, peer not responding
establishing connection 'ikev1-psk-xauth' failed
Desperately looking for your kind recommendations 
#7
Updated by Tobias Brunner almost 4 years ago
The last error indicates an incorrect PSK. The one above (about the XAuth method) I commented on already on serverfault.com (you need the xauth-generic plugin).
#8
Updated by Saqib Shakeel almost 4 years ago
Saqib Shakeel wrote:
Update :
After changing settings in the secrete file[…]
I got this output(Remember the default server setting for aggressive is on but the following output is without aggressive)
[…]
Desperately looking for your kind recommendations
do you think
10.48.130.136 %any : PSK "Password_of_my_Wifi"
is correct in secrete file??
and I have reverified the PSK with my university server, it matches. Also, for xauth-generic,I also commented on serverfault.com, I am trying to install xauth-generic plugin using
sudo apt-get install strongswan strongswan-plugin-xauth-generic
but I am getting this error
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package strongswan-plugin-xauth-generic
Your thoughts please??
and just for reference, My current .config has the following content
config setup
conn ikev1-psk-xauth
ikelifetime=28800s
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev1
authby=secret
ike = 3des-md5-modp1024!
esp = 3des-md5!
modeconfig = pull
aggressive = yes
fragmentation=yes
#keyexchange = ikev2
type = transport
left = 10.48.130.136
# left = %any
leftauth = psk
leftauth2 = xauth-generic
# leftprotoport=17/1701
# rightprotoport=17/1701
right = 193.174.193.64
rightauth = psk
rightauth2 = xauth
auto = add
and .secretes has
193.174.193.64 %any : PSK "PSK of Server provided by university" #right PSK
10.48.130.136 %any : PSK "Current wifi password on which my raspberry pi is connected" #left PSK
10.48.130.136 %any : xauth "Password of my raspberry" #left xauth
please let me know if I am doing anything wrong.
Many thanks,
#9
Updated by Tobias Brunner almost 4 years ago
is correct in secrete file??
and I have reverified the PSK with my university server, it matches.
According to the log it might be wrong (you wrote «Password_of_my_Wifi» above, but the PSK is for the VPN not the WiFi and obviously not yours but that of your university).
Also, for xauth-generic,I also commented on serverfault.com, I am trying to install xauth-generic plugin using
[…]
but I am getting this error
[…]Your thoughts please??
You need to adapt that to your distribution. Individual packages for plugins were only available on older Ubuntu releases. On newer ones the plugin is in the libcharon-standard-plugins package.
and just for reference, My current .config has the following content
You don’t need rightauth2, only leftauth2. authby is not used if you set left|rightauth. You also don’t need to specify left. type = transport is probably wrong too (unless you want to use L2TP, which doesn’t seem to be the case according to the original description), just remove it or set it to tunnel. To request a virtual IP from the server (mode config) you also want to set leftsourceip = %config.
[…]
and .secretes has
[…]
As mentioned above, you don’t need the PSK of your Wi-Fi. If the first PSK is correct you should get past that step.
#11
Updated by Saqib Shakeel almost 4 years ago
Thanks for your detailed reply, after rectification of all your recommendations. I cam out with the following output.¶
initiating Main Mode IKE_SA ikev1-psk-xauth[1] to 193.174.193.64
generating ID_PROT request 0 [ SA V V V V V ]
sending packet: from 10.48.X.X[500] to 193.174.X.X[500] (176 bytes)
received packet: from 193.174.X.X[500] to 10.48.X.X[500] (124 bytes)
parsed ID_PROT response 0 [ SA V V ]
received draft-ietf-ipsec-nat-t-ike-02n vendor ID
received FRAGMENTATION vendor ID
generating ID_PROT request 0 [ KE No NAT-D NAT-D ]
sending packet: from 10.48.X.X[500] to 193.174.X.X[500] (236 bytes)
received packet: from 193.174.X.X[500] to 10.48.X.X[500] (296 bytes)
parsed ID_PROT response 0 [ KE No V V V V NAT-D NAT-D ]
received Cisco Unity vendor ID
received XAuth vendor ID
received unknown vendor ID: ff:0b:90:72:76:c2:fd:96:48:4c:e1:a3:d8:b3:5f:05
received unknown vendor ID: 1f:07:f7:0e:aa:65:14:d3:b0:fa:96:54:2a:50:01:00
local host is behind NAT, sending keep alives
generating ID_PROT request 0 [ ID HASH N(INITIAL_CONTACT) ]
sending packet: from 10.48.X.X[4500] to 193.174.X.X[4500] (92 bytes)
received packet: from 193.174.X.X[4500] to 10.48.X.X[4500] (84 bytes)
parsed ID_PROT response 0 [ ID HASH V ]
received DPD vendor ID
received packet: from 193.174.X.X[4500] to 10.48.X.X[4500] (68 bytes)
parsed TRANSACTION request 2735128820 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
no XAuth password found for '10.48.X.X' - '193.174.X.X'
generating TRANSACTION response 2735128820 [ HASH CP ]
sending packet: from 10.48.X.X[4500] to 193.174.X.X[4500] (60 bytes)
received packet: from 193.174.X.X[4500] to 10.48.X.X[4500] (68 bytes)
parsed TRANSACTION request 2217701343 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
no XAuth password found for '10.48.X.X' - '193.174.X.X'
generating TRANSACTION response 2217701343 [ HASH CP ]
sending packet: from 10.48.X.X[4500] to 193.174.X.X[4500] (60 bytes)
received packet: from 193.174.X.X[4500] to 10.48.X.X[4500] (68 bytes)
parsed TRANSACTION request 4240452121 [ HASH CPRQ(X_TYPE X_USER X_PWD) ]
no XAuth password found for '10.48.X.X' - '193.174.X.X'
generating TRANSACTION response 4240452121 [ HASH CP ]
sending packet: from 10.48.X.X[4500] to 193.174.X.X[4500] (60 bytes)
received packet: from 193.174.X.X[4500] to 10.48.X.X[4500] (60 bytes)
parsed TRANSACTION request 1205019406 [ HASH CPS(X_STATUS) ]
XAuth authentication of '10.48.X.X' (myself) failed
generating TRANSACTION response 1205019406 [ HASH CPA(X_STATUS) ]
sending packet: from 10.48.X.X[4500] to 193.174.X.X[4500] (68 bytes)
establishing connection 'ikev1-psk-xauth' failed
Configuration file is¶
config setup
conn ikev1-psk-xauth
ikelifetime=28800
keyexchange=ikev1
ike = 3des-md5-modp1024!
esp = 3des-md5!
leftsourceip=%config
leftauth = psk
leftauth2 = xauth-generic
right = 193.174.X.X
rightauth = psk
auto = add
and .secrets file is¶
%any : PSK "PSK_provided_with_Server"
what do you recommend to do next ?
#12
Updated by Saqib Shakeel almost 4 years ago
For giving you the more info and to get more relevant and precise feedback I would like to share the status of ipsec as well which is as
follows,
tatus of IKE charon daemon (weakSwan 5.5.1, Linux 4.14.79-v7+, armv7l):
uptime: 10 minutes, since Mar 14 21:38:32 2019
malloc: sbrk 1216512, mmap 0, used 261256, free 955256
worker threads: 10 of 16 idle, 6/0/0/0 working, job queue: 0/0/0/0, scheduled: 0
loaded plugins: charon aes rc2 sha2 sha1 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs7 pkcs8 pkcs12 pgp dnskey sshkey pem openssl fips-prf gmp agent xcbc hmac gcm attr kernel-netlink resolve socket-default connmark farp stroke updown eap-identity eap-aka eap-md5 eap-gtc eap-mschapv2 eap-radius eap-tls eap-ttls eap-tnc *xauth-generic* xauth-eap xauth-pam tnc-tnccs dhcp lookip error-notify certexpire led addrblock unity
Listening IP addresses:
10.48.X.X
Connections:
ikev1-psk-xauth: %any...193.174.X.X IKEv1
ikev1-psk-xauth: local: [10.48.X.X] uses pre-shared key authentication
ikev1-psk-xauth: local: uses XAuth authentication: generic
ikev1-psk-xauth: remote: [193.174.X.X] uses pre-shared key authentication
ikev1-psk-xauth: child: dynamic === dynamic TUNNEL
Security Associations (0 up, 0 connecting):
none
#13
Updated by Tobias Brunner almost 4 years ago
What you need to do to pass the XAuth authentication is setting xauth_identity to the username of your university account (e.g. user@fh-kempten.de or whatever it is, maybe works even without the domain part) and add an XAUTH secret with the matching password to ipsec.secrets:
conn ikev1-psk-xauth
...
xauth_identity = <username for university account>
...
... : PSK ... <username> : XAUTH "password for university account"
#14
Updated by Saqib Shakeel almost 4 years ago
Tobias Brunner wrote:
What you need to do to pass the XAuth authentication is setting xauth_identity to the username of your university account (e.g. user@fh-kempten.de or whatever it is, maybe works even without the domain part) and add an XAUTH secret with the matching password to ipsec.secrets:
[…]
[…]
after doing the above recommended changes, I am getting the same output as in #11¶
#15
Updated by Tobias Brunner almost 4 years ago
after doing the above recommended changes, I am getting the same output as in #11
Hm, the problem there was that no XAuth secret was found. If you configured one and set the username correctly that shouldn’t be a problem anymore. So I guess your config is not correct.
#16
Updated by Saqib Shakeel almost 4 years ago
Hm, the problem there was that no XAuth secret was found. If you configured one and set the username correctly that shouldn’t be a problem anymore. So I guess your config is not correct.
Actually I am using the same credentials from my PC using GUI based Shrewsoft VPN Access Manager and I am successfully able to connect but with strongswan I cannot 
#17
Updated by Tobias Brunner almost 4 years ago
Actually I am using the same credentials from my PC using GUI based Shrewsoft VPN Access Manager and I am successfully able to connect but with strongswan I cannot
If the error is really the same as before the actual username/password doesn’t matter. You have to configure it correctly so it is found.
#18
Updated by Saqib Shakeel almost 4 years ago
If the error is really the same as before the actual username/password doesn’t matter. You have to configure it correctly so it is found.
So, thanks for your through out support and debugging my scripts of strongswan, I tried alot of things to get my work done. I ma not sure to post it here or not but for others to help, I want to say that I switched to [[https://cs.uwaterloo.ca/twiki/view/CF/OpenConnect]] because strongswan was not compatable with my university’s VPN so using openconnect, now I have my VPN up and working.
This platfrom is run by very professional people and I will definiely come back to it in future forsure
Cheers!!!
#19
Updated by Tobias Brunner almost 4 years ago
- Status changed from Feedback to Closed
- Resolution set to No change required
No worries, the issue is that your university only supports an old and insecure version of IKE (the protocol implemented by openconnect is more modern but it’s a non-standardized protocol by Cisco).
Содержание
- strongSwan
- Задачи
- Issue #2969
- received NO_PROPOSAL CHOSEN error notify
- My ipsec.secrete file looks like¶
- With above configuration, when I run my ipsec command i get the following error¶
- История
- #1 Обновлено Tobias Brunner почти 4 года назад
- #2 Обновлено Saqib Shakeel почти 4 года назад
- #3 Обновлено Tobias Brunner почти 4 года назад
- #4 Обновлено Saqib Shakeel почти 4 года назад
- #5 Обновлено Saqib Shakeel почти 4 года назад
- Update:¶
- #6 Обновлено Saqib Shakeel почти 4 года назад
- #7 Обновлено Tobias Brunner почти 4 года назад
- #8 Обновлено Saqib Shakeel почти 4 года назад
- #9 Обновлено Tobias Brunner почти 4 года назад
- strongSwan
- Задачи
- Issue #2562
- received NO_PROPOSAL_CHOSEN error notify and sending retransmit 1 of request message ID 0, seq 1
- ipsec.conf:¶
- Box 2¶
- ipsec.conf¶
- Common on box1 and box 2¶
- История
- #1 Обновлено Tobias Brunner почти 5 года назад
- #2 Обновлено Anne ENYIH почти 5 года назад
- #3 Обновлено Tobias Brunner почти 5 года назад
- #4 Обновлено Anne ENYIH почти 5 года назад
strongSwan
Задачи
Issue #2969
received NO_PROPOSAL CHOSEN error notify
Добавил(а) Saqib Shakeel почти 4 года назад. Обновлено почти 4 года назад.
Описание
I am trying to configure my client on rasppyberry pi for a remote VPN server(Shrew) provided with the following information.
I am trying to configure my client using VPN (strongswan) to access the remote server whose DNS is
vpngw.fh-kempten.de
Details of my remote VPN Server are:
My ipsec configuration file looks like the following (Recommend me any changes if needed?)
My ipsec.secrete file looks like¶
With above configuration, when I run my ipsec command i get the following error¶
My motivation is to access the shared drive which is present on the remote VPN server
I am looking for help as I am newbie to this stuff and already scratched my head on it for about 3 weeks before posting here. so
my expectations from this forum are very high.
Looking forward to the kind responses:)
Thanks in advance!!
Связанные задачи
История
#1 Обновлено Tobias Brunner почти 4 года назад
- Описание обновлено (diff)
- Параметр Категория изменился с libstrongswan на configuration
- Параметр Статус изменился с New на Feedback
- Параметр Приоритет изменился с Immediate на Normal
We discussed this on serverfault.com already. Apparently, not successfully.
If you receive a NO_PROPOSAL_CHOSEN notify it means the peers is not happy about any of the algorithms or authentication methods. In your case it might be related to this:
If you only propose PSK authentication and not PSK+XAuth the server is probably not happy about it. So you want to set leftauth2 to xauth.
#2 Обновлено Saqib Shakeel почти 4 года назад
Okay, Thanks for your reply. whith , what changes are expected in
#3 Обновлено Tobias Brunner почти 4 года назад
- Описание обновлено (diff)
You need to add an XAUTH secret.
#4 Обновлено Saqib Shakeel почти 4 года назад
Now after following your suggestion, I am getting this error
#5 Обновлено Saqib Shakeel почти 4 года назад
Update:¶
When I run it by commenting aggressive mode. It gives me the following output..
#6 Обновлено Saqib Shakeel почти 4 года назад
Update :
After changing settings in the secrete file
I got this output(Remember the default server setting for aggressive is on but the following output is without aggressive)
Desperately looking for your kind recommendations 🙂
#7 Обновлено Tobias Brunner почти 4 года назад
The last error indicates an incorrect PSK. The one above (about the XAuth method) I commented on already on serverfault.com (you need the xauth-generic plugin).
#8 Обновлено Saqib Shakeel почти 4 года назад
Saqib Shakeel wrote:
Update :
After changing settings in the secrete file
I got this output(Remember the default server setting for aggressive is on but the following output is without aggressive)
[. ]
Desperately looking for your kind recommendations 🙂
is correct in secrete file??
and I have reverified the PSK with my university server, it matches. Also, for xauth-generic,I also commented on serverfault.com, I am trying to install xauth-generic plugin using
but I am getting this error
Your thoughts please??
and just for reference, My current .config has the following content
and .secretes has
please let me know if I am doing anything wrong.
Many thanks,
#9 Обновлено Tobias Brunner почти 4 года назад
and I have reverified the PSK with my university server, it matches.
According to the log it might be wrong (you wrote «Password_of_my_Wifi» above, but the PSK is for the VPN not the WiFi and obviously not yours but that of your university).
Also, for xauth-generic,I also commented on serverfault.com, I am trying to install xauth-generic plugin using
[. ]
but I am getting this error
[. ]
Your thoughts please??
You need to adapt that to your distribution. Individual packages for plugins were only available on older Ubuntu releases. On newer ones the plugin is in the libcharon-standard-plugins package.
and just for reference, My current .config has the following content
You don’t need rightauth2, only leftauth2. authby is not used if you set left|rightauth. You also don’t need to specify left. type = transport is probably wrong too (unless you want to use L2TP, which doesn’t seem to be the case according to the original description), just remove it or set it to tunnel. To request a virtual IP from the server (mode config) you also want to set leftsourceip = %config.
As mentioned above, you don’t need the PSK of your Wi-Fi. If the first PSK is correct you should get past that step.
Источник
strongSwan
Задачи
Issue #2562
received NO_PROPOSAL_CHOSEN error notify and sending retransmit 1 of request message ID 0, seq 1
Добавил(а) Anne ENYIH почти 5 года назад. Обновлено почти 5 года назад.
Описание
Hi,
I have been struggling for the past week to configure an ipsec tunnel between two fedora19 boxes using strongswan version 5.1.3
I have the exact configuration for net2net with PSK found on this link https://www.strongswan.org/testing/testresults/ikev2/net2net-psk/index.html except for the ipaddresses to match my network.
Here is my configuration:
ipsec.conf:¶
Box 2¶
ipsec.conf¶
Common on box1 and box 2¶
Here is problem:
1. When i try to bring up the tunnel from moon I get the following error:
2. When I try to bring up the tunnel from sun, I get the following error:
История
#1 Обновлено Tobias Brunner почти 5 года назад
- Описание обновлено (diff)
- Параметр Категория изменился на configuration
- Параметр Статус изменился с New на Feedback
Please consider the response by Jafar to your email: https://lists.strongswan.org/pipermail/users/2018-February/012272.html (the same applies to any error received, e.g. NO_PROPOSAL_CHOSEN). And also see HelpRequests and the warning regarding charon.load on PluginLoad.
#2 Обновлено Anne ENYIH почти 5 года назад
Thanks Tobias. I have read through that and i was successful in creating the ipsec tunnel. However,our main need is deployed route based VPNs and I have been trying to no avail to get it to work. I have followed the instructions given in https://wiki.strongswan.org/projects/strongswan/wiki/RouteBasedVPN and also followed the thread https://wiki.strongswan.org/issues/2542 which is quite similar to my issue but I still have some issues.Here below is my configuration.
Box 1:
Ipsec.conf
config setup
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
authby=secret
mobike=no
conn fed1_fed2
left=192.168.20.106
leftsubnet=192.168.12.0/24
leftid=@fed1
leftfirewall=yes
right=192.168.20.109
rightsubnet=192.168.13.0/24
rightid=@fed2
mark=42
auto=add
strongswan.conf
charon <
- load = random nonce aes gmp sha1 sha2 curve25519 hmac stroke kernel-netlink socket-default updown
install_routes = 0
>
strongswan statusall:
Status of IKE charon daemon (strongSwan 5.1.3, Linux 3.14.27-100.fc19.x86_64, x86_64):
uptime: 43 minutes, since Feb 28 09:47:41 2018
malloc: sbrk 2560000, mmap 0, used 345456, free 2214544
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 5
loaded plugins: charon curl aes des rc2 sha1 sha2 md4 md5 random nonce x509 revocation constraints pubkey pkcs1 pkcs8 pgp dnskey sshkey pem fips-prf gmp xcbc cmac hmac attr kernel-netlink resolve socket-default farp stroke updown eap-identity eap-md5 eap-gtc eap-mschapv2 eap-tls eap-ttls eap-peap xauth-generic xauth-eap xauth-pam dhcp
Listening IP addresses:
192.168.12.3
192.168.12.4
192.168.20.106
192.168.20.108
192.168.3.1
192.168.6.1
192.168.12.2
Connections:
fed1_fed2: 192.168.20.106. 192.168.20.109 IKEv2
fed1_fed2: local: [fed1] uses pre-shared key authentication
fed1_fed2: remote: [fed2] uses pre-shared key authentication
fed1_fed2: child: 192.168.12.0/24 === 192.168.13.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
fed1_fed2 2 : ESTABLISHED 25 minutes ago, 192.168.20.106[fed1]. 192.168.20.109[fed2]
fed1_fed2 2 : IKEv2 SPIs: fe8ae63a600d47d4_i ea75e90a5af54c68_r*, pre-shared key reauthentication in 31 minutes
fed1_fed2 2 : IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
fed1_fed2<2>: INSTALLED, TUNNEL, ESP SPIs: cb5c029a_i c02f09b7_o
fed1_fed2<2>: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 3 minutes
fed1_fed2<2>: 192.168.12.0/24 === 192.168.13.0/24
Iptables:
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT all — anywhere anywhere
ACCEPT all — anywhere anywhere
Chain FORWARD (policy ACCEPT)
target prot opt source destination
ACCEPT all — 192.168.13.0/24 192.168.12.0/24 policy match dir in pol ipsec reqid 2 proto esp
ACCEPT all — 192.168.12.0/24 192.168.13.0/24 policy match dir out pol ipsec reqid 2 proto esp
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
BOX 2:
ipsec.conf
config setup
conn %default
ikelifetime=60m
keylife=20m
rekeymargin=3m
keyingtries=1
keyexchange=ikev2
authby=secret
mobike=no
conn fed1_fed2
left=192.168.20.109
leftsubnet=192.168.13.0/24
leftid=@fed2
leftfirewall=yes
right=192.168.20.106
rightsubnet=192.168.12.0/24
rightid=@fed1
mark=42
auto=add
strongswan.conf
charon <
load = random nonce aes gmp sha1 sha2 curve25519 hmac stroke kernel-netlink socket-default updown
install_routes = 0
>
strongswan stattusall
Status of IKE charon daemon (strongSwan 5.1.3, Linux 3.14.27-100.fc19.x86_64, x86_64):
uptime: 29 minutes, since Feb 28 10:08:40 2018
malloc: sbrk 2404352, mmap 0, used 187680, free 2216672
worker threads: 11 of 16 idle, 5/0/0/0 working, job queue: 0/0/0/0, scheduled: 3
loaded plugins: charon random nonce aes gmp sha1 sha2 hmac stroke kernel-netlink socket-default updown
Listening IP addresses:
192.168.13.3
192.168.13.4
192.168.20.109
192.168.20.111
192.168.3.1
192.168.6.1
Connections:
fed1_fed2: 192.168.20.109. 192.168.20.106 IKEv2
fed1_fed2: local: [fed2] uses pre-shared key authentication
fed1_fed2: remote: [fed1] uses pre-shared key authentication
fed1_fed2: child: 192.168.13.0/24 === 192.168.12.0/24 TUNNEL
Security Associations (1 up, 0 connecting):
fed1_fed2 1 : ESTABLISHED 28 minutes ago, 192.168.20.109[fed2]. 192.168.20.106[fed1]
fed1_fed2 1 : IKEv2 SPIs: fe8ae63a600d47d4_i* ea75e90a5af54c68_r, pre-shared key reauthentication in 25 minutes
fed1_fed2 1 : IKE proposal: AES_CBC_128/HMAC_SHA1_96/PRF_HMAC_SHA1/MODP_2048
fed1_fed2<1>: INSTALLED, TUNNEL, ESP SPIs: c02f09b7_i cb5c029a_o
fed1_fed2<1>: AES_CBC_128/HMAC_SHA1_96, 0 bytes_i, 0 bytes_o, rekeying in 46 seconds
fed1_fed2<1>: 192.168.13.0/24 === 192.168.12.0/24
ip xfrm policy:
src 192.168.12.0/24 dst 192.168.13.0/24
dir fwd priority 1859 ptype main
mark 42/0xffffffff
tmpl src 192.168.20.106 dst 192.168.20.109
proto esp reqid 1 mode tunnel
src 192.168.12.0/24 dst 192.168.13.0/24
dir in priority 1859 ptype main
mark 42/0xffffffff
tmpl src 192.168.20.106 dst 192.168.20.109
proto esp reqid 1 mode tunnel
src 192.168.13.0/24 dst 192.168.12.0/24
dir out priority 1859 ptype main
mark 42/0xffffffff
tmpl src 192.168.20.109 dst 192.168.20.106
proto esp reqid 1 mode tunnel
I created a VTI on both boxes using command:
ip link add ipsec1 type vti key 42 local [ipaddr local] remote [ipaddr remote] (i must admit this command is different from the one suggested on the website => ip tunnel add ipsec0 local 192.168.0.1 remote 0.0.0.0 mode vti key 42) but that is because when I tried to use this command i get an error: Keys are not allowed with ipip and sit tunnels ; However, as show the VTI is up and running quite well.
ip -s tunnel show
ipsec1: ip/ip remote 192.168.20.106 local 192.168.20.109 ttl inherit nopmtudisc key 42
RX: Packets Bytes Errors CsumErrs OutOfSeq Mcasts
0 0 0 0 0 0
TX: Packets Bytes Errors DeadLoop NoRoute NoBufs
0 0 3285 0 3285 0
Added routes to make sure all traffic from my ipsec sbunets are sent to the vti as such:
ip route add 192.168.12.0/24 dev ipsec1 => box2
ip route add 192.168.13.0/24 dev ipsec1 => box1
Here is my issue: when i try to ping from box1 to box2 or vice versa using the command
ping -I 192.168.12.3 192.168.13.3 => box1 (all ip address are up), i get
From 192.168.12.3 icmp_seq=1 Destination Host Unreachable
when i try to capture on the vti on box1 i get (tcpdump -i ipsec1 -n -v)
192.168.12.3 > 192.168.13.3: ICMP echo request, id 1803, seq 65, length 64
10:43:40.761089 IP (tos 0x0, ttl 63, id 11257, offset 0, flags [DF], proto UDP (17), length 140)
192.168.12.16.terabase > 192.168.13.3.terabase: UDP, length 112
10:43:40.761096 IP (tos 0x0, ttl 63, id 24934, offset 0, flags [DF], proto UDP (17), length 140)
192.168.12.16.terabase > 192.168.13.16.terabase: UDP, length 112
10:43:40.823208 IP (tos 0x0, ttl 64, id 55054, offset 0, flags [DF], proto TCP (6), length 60)
192.168.12.2.39942 > 192.168.13.3.8050: Flags [S], cksum 0x5a75 (correct), seq 1463734659, win 25840, options [mss 1292,sackOK,TS val 3803768 ecr 0,nop,wscale 7], length 0
Am I doing something wrong ? Please help me.
#3 Обновлено Tobias Brunner почти 5 года назад
However,our main need is deployed route based VPNs and I have been trying to no avail to get it to work.
Why do you think you need route based VPNs?
You did see this, right?
Maybe a kernel issue, as mentioned on RouteBasedVPN, some important changes were not implemented until 3.15+ kernels (the error you get at least indicates that the iproute2 version is relatively old or buggy).
#4 Обновлено Anne ENYIH почти 5 года назад
Tobias Brunner wrote:
However,our main need is deployed route based VPNs and I have been trying to no avail to get it to work.
Why do you think you need route based VPNs?
Well the reason for our decision is to be able to combine different IPsec gateways into one VTI interface and also for some multicast implementations; this seemed to be the best option for us.
You did see this, right?
Thanks, I missed the errors.
Maybe a kernel issue, as mentioned on RouteBasedVPN, some important changes were not implemented until 3.15+ kernels (the error you get at least indicates that the iproute2 version is relatively old or buggy).
I think I will resort to a kernel upgrade. Thank you very much.
Источник
ASA IPSec IKEv1
When creating an ASA IPsec VPN, there will be times when Phase 2 does not match between the peers. When the VPN is initiated from the ASA, and debugs are enabled, you will see that the ASA receives a No Proposal Chosen message. There are two specific types of No Proposal Chosen messages that the ASA will see which are No proposal chosen (14) and Invalid ID (18). The 14 and 18 specify which portion of Phase 2 that is mismatching.
IPSec Phase 2
Phase 2 consists of Encryption, Hash, Perfect Forward Secrecy (PFS), Lifetime and Encryption Domain. The numbers 14 and 18 in the non-routine Notify response correlate to these settings.
Invalid ID info (18)
is the easiest to identify. This message is stating that the Encryption Domains do not match on both sides of the VPN. If the ASA has received this message, this means all other settings are valid for Phase 2, just the Access-List for the VPN needs to be updated on either the ASA or Remote Peer.
Error Example:
Oct 05 23:18:54 [IKEv1]Group = 1.2.3.4, IP = 1.2.3.4, Received non-routine Notify message: Invalid ID info (18)
No Proposal Chosen (14)
is a little tougher to troubleshoot which piece of the Phase 2 configuration is mismatched. 14 represents the Encryption, Hash, PFS and Lifetime. Usually this issue is not related to lifetime as this will auto negotiate to the lowest value between the ASA and the Remote peer. There are times when the Remote peer may not negotiate the lifetime which will present this message but this is rare.
This leaves Encryption, Hash and PFS. PFS tends to be the largest culprit of the issues with Phase 2. Some other VPN vendors will have PFS on by default, so the Remote side may believe that PFS is disabled as this was not configured by them. The easiest way to troubleshoot error 14 is to enable pfs as group2. This is the usual default PFS setting for other VPN endpoints and is the default PFS used by the ASA when enabled.
If the issue persists after testing PFS, then it is best to reach out to the other side and compare the settings for Encryption, Hash, PFS and Lifetime to make sure everything matches.
When changing these settings, be careful to watch if the No proposal message has changed from 14 to 18 (Invalid ID info). That would mean that Encryption, Hash, PFS and Lifetime are now correct. Message 18 is only presented if the tunnel has made it past message 14.
Error Example:
Oct 05 23:10:43 [IKEv1]Group = 1.2.3.4, IP = 1.2.3.4, Received non-routine Notify message: No proposal chosen (14)
IPSec Phase 2 Configuration Table
Invalid ID info (18)
access-list 200 permit ip 10.10.10.0 255.255.255.0 192.168.0.0 255.255.255.0 <-Encryption Domain
crypto map VPNMAP 200 match address 200 <-Encryption Domain
No Proposal Chosen (14)
crypto ipsec ikev1 transform-set ESP-AES-SHA esp-aes esp-sha-hmac <-Encryption and Hash
crypto map VPNMAP 200 set peer 1.2.3.4
crypto map VPNMAP 200 set pfs group2 <-PFS
crypto map VPNMAP 200 set ikev1 transform-set ESP-AES-SHA <-Encryption and Hash
crypto map VPNMAP 200 set security-association lifetime seconds 3600 <-Lifetime
To understand more on configuring IPSec VPNs, please see my Basic Site to Site VPN Article or my Route Based VPN Article to learn more. If you wish to see more on troubleshooting VPNs, please check out my Troubleshooting article as well. If you would like to see any new Articles or if you have any questions, feel free to contact me.
IPSec Troubleshooting
Last adaptation to the version: 12.2.3
New:
- The log level can be set directly in the admin interface
Preparation — Increase log level
As a prerequisite for successful troubleshooting, the log level must first be increased.
When the log level is changed, the IPSec service is restarted. All IPSec connections are interrupted once during this process.
| Log-Level: New as of 12.2.3 |
Rudimentary (recommended) | Default setting |
| Detailed | Suitable for detailed troubleshooting | |
| very detailed | May be required for specific troubleshooting
|
|
| User-defined | All values can be logged in the ╭╴Advanced settings╶╮ section in 5 different levels | |
| Save the changed settings with Save and restart
|
Alternative option to change the log level:
CLI command
extc value set application «ipsec» variable «DBG_LVL_IKE» value [ «2» ]
Menu Application IPSEC Button
Alternative option to change the log level:
Set extc-variable
In the advanced settings: Tab extc-variables search for DBG_LVL_IKE change value to » ✕2
Menu Application IPSEC Button
Alternative option to change the log level:
SSH
via SSH at runtime as root
- (only up to version 12.1.8):
ipsec stroke loglevel ike 2
This command returns the setting to its original value after a restart!
- (as of version 12.2):
spcli extc value set application ipsec variable DBG_LVL_IKE value 2
spcli appmgmt config
swanctl —reload-settings
The establishment of an IPSec connection using IKEv1 takes place in two phases. In phase 1, both gateways are authenticated against each other. This can be done in two different ways: The «Aggressive Mode» or the «Main Mode». The aggressive mode encrypts the Pre Shared Key (PSK) using a simple hash algorithm.
Apart from this PSK, no further identification is provided. This results in the following disadvantages:
- When several remote stations are connected, they cannot be distinguished from each other in phase 1. Therefore, the same PSK must be used in all connections. The probability of being compromised increases with the number of remote stations.
- The simple hash encryption of the PSK makes it vulnerable to dictionary attacks, and more so the simpler it is. Since no other identification feature is provided besides the PSK, such attacks can be carried out by any computer with Internet access.
For these reasons, the aggressive mode of IPSec does not find any use in connection with Securepoint NextGen UTM. Only the secure main mode is used. In addition to the PSK, this requires a further identification feature, the so-called ID. Furthermore, the transmission of the PSK is secured by the Diffie-Hellman key exchange method. This makes it mathematically impossible to intercept a transmitted key. In addition to PSKs, the main mode also allows RSA keys or X.509 certificates for authentication.
Phase 1
The normal connection setup
| If no errors occur in phase 1, this is indicated by an entry in the LiveLog that reports the successful establishment of an IKE_SA. If this entry is found in both the initiator’s log and the responder’s log, phase 1 has been configured without errors and any configuration error should be looked for in phase 2. | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 10[IKE] IKE_SA Standort_1_2[1] established between 198.51.100.75[198.51.100.75]…198.51.100.1[198.51.100.1] |
False proposal
| If both sides cannot agree on encryption parameters acceptable to both sides, the responder reports this in its livelog. The initiator gets the message «NO_PROPOSAL_CHOSEN». |
|
| Initiator-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 10[IKE] received NO_PROPOSAL_CHOSEN notify error |
| Responder-Log | |
| Dienst | Nachricht |
| IPSec(charon) | 05[CFG] selecting proposal: |
| IPSec(charon) | 05[CFG] no acceptable ENCRYPTION_ALGORITHM found |
| IPSec(charon) | 05[CFG] selecting proposal: |
| IPSec(charon) | 05[CFG] received proposals: IKE:BLOWFISH_CBC_256/HMAC_SHA2_512_256/PRF_HMAC_SHA2_512/MODP_8192 |
| IPSec(charon) | 05[CFG] configured proposals:IKE:AES_CBC_128/HMAC_SHA2_256_128/PRF_HMAC_SHA2_256/MODP_2048,IKE:AES_CBC_128/AES_CBC_192/AES_CBC_256/3DES_CBC/CAMELLIA_CBC_128/CAMELLIA_CBC_192/CAMELLIA_CBC_256/AES_CTR_128/AES_CTR_192/AES_CTR_256/CAMELLIA_CTR_128/CAMELLIA_CTR_192/CAMELLIA_CTR_256/HMAC_MD5_96/HMAC_SHA1_96/HMAC_SHA2_256_128/HMAC_SHA2_384_192/HMAC_SHA2_512/AES_XCBC_96/AES_CMAC_96/PRF_HMAC_MD5/PRF_HMAC_SHA1/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_512/256/AES_XCBC_96/AES_CMAC_96/PRF_AES128_CMAC/MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/MODP_3072/MODP_4096/MODP_8192/MODP_1024/MODP_1024_160/ECP_256/ECP_384/ECP_512/ECP_224/ECP_192/ECP_224_BP/ECP_256_BP/ECP_384_BP_ECP_512_BP,IKE:AES_GCM_8_128/AES_GCM_8_192/AES_GCM_8_256/AES_GCM_12_128/AES_GCM_12_192/AES_GCM_12_256/AES_GCM_16_128/AES_GCM_16_192/AES_GCM_16_256/PRF_HMAC_MD5/PRF_HMAC_SHA1/PRF_HMAC_SHA2_256/PRF_HMAC_SHA2_384/PRF_HMAC_SHA2_512/PRF_AES128_XCBC/PRF_AES128_CMAC/MODP_2048/MODP_2048_224/MODP_2048_256/MODP_1536/MODP_3072/MODP_4096/MODP_8192/MODP_1024/MODP_1024_160/ECP_256/ECP_384/ECP__521/ECP_224/ECP_192/ECP_224_BP/ECP_256_BP/ECP_384_BP/ECP_512_BP |
| IPSec(charon) | 10[IKE] received proposals inacceptable |
Incorrect remote gateway address
| If the initiator attempts to establish a connection from a gateway address other than the one configured on the responder side, the responder cannot classify this connection. This is reported accordingly in the LiveLog. The initiator gets the message NO_PROPOSAL_CHOSEN. |
|
| Responder-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 11[CFG] looking for an ike config for 198.51.100.75…195.51.100.1 |
| IPSec(charon) | 11[IKE] no IKE config found for 198.51.100.75…195.51.100.1, sending NO_PROPOSAL_CHOSEN |
Incorrect ID Initiator
| If the initiator logs in with an identifier (ID) other than the one stored in the responder’s configuration, the responder cannot determine a PSK configuration for this connection attempt and reports this accordingly in the LiveLog. The initiator receives the error message AUTHENTICATION_FAILED. |
|
| Initiator-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 09[IKE] received AUTHENTICATION_FAILED error notify |
| Responder-Log | |
| Dienst | Nachricht |
| IPSec(charon) | 07[CFG] looking for pre-shared key peer configs matching 198.51.100.75…198.51.100.1[blubb] |
| IPSec(charon) | 07[IKE] no peer config found |
Incorrect ID Responder
| If the responder reports with a different ID than in the initiator’s configuration, then this is reported accordingly in the initiator’s log. | |
| Initiator-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 05[IKE] IDir ‘blubb’ does not match to ‘198.51.100.75’ |
Incorrect PSK
| In contrast to older software versions, there is no clearly readable hint in the log for mismatched PSKs when using IKEv1. Indirectly, the indication of «malformed» packets points to this error. | |
| Initiator-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 15[IKE] message parsing failed |
| IPSec(charon) | 15[IKE] ignore malformed INFORMATIONAL request |
| IPSec(charon) | 15[IKE] INFORMATIONAL_V1 request with message ID 1054289493 processing failed |
| Responder-Log | |
| Dienst | Nachricht |
| IPSec(charon) | 14[IKE] message parsing failed |
| IPSec(charon) | 14[IKE] ID_PROT request with message ID 0 processing failed |
Incorrect RSA key initiator
| If the initiator of the connection uses a different RSA key than the one set in the responder configuration, authentication cannot take place. The initiator receives the error message «AUTHENTICATION_FAILED». |
|
| Initiator-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 15[IKE] authentication of ‘Filiale’ (myself) succesful |
| IPSec(charon) | 16[IKE] received AUTHENTICATION_FAILED error notify |
| Responder-Log | |
| Dienst | Nachricht |
| IPSec(charon) | 14[CFG] looking for RSA signature peer configs matching 198.51.100.75…198.51.100.1[Filiale] |
| IPSec(charon) | 14[CFG] candidate «Standort1_4», match: 1/20/28 (me/other/ike) |
| IPSec(charon) | 14[CFG] selected peer config «Standort1_4» |
| IPSec(charon) | 14[CFG] using trusted certificate «Filiale» |
| IPSec(charon) | 14[IKE] ignature validation failed, looking for another key |
| IPSec(charon) | 14[IKE] no trusted RSA public key found for ‘Filiale’ |
Incorrect RSA key responder
| If the responder uses a different RSA key than the one specified in the initiator’s configuration, the authentication fails again on the initiator’s side. The responder that has already established an IKE_SA is instructed to delete it again. | |
| Initiator-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 16[CFG] authentication of ‘Filiale’ (myself) succesful |
| IPSec(charon) | 16[IKE] using trusted certificate «Zentrale» |
| IPSec(charon) | 16[IKE] signature validation failed, looking for another key |
| IPSec(charon) | 15[IKE] no trusted RSA public key found for ‘Zentrale’ |
| Responder-Log | |
| Dienst | Nachricht |
| IPSec(charon) | 10[CFG] looking for RSA signature peer configs matching 198.51.100.75…198.51.100.1[Filiale] |
| IPSec(charon) | 10[CFG] candidate «Standort1_4», match: 1/20/28 (me/other/ike) |
| IPSec(charon) | 10[CFG] selected peer config «Standort1_4» |
| IPSec(charon) | 10[CFG] using trusted certificate «Filiale» |
| IPSec(charon) | 10[IKE] authentication of ‘Filiale’ with RSA succesful |
| IPSec(charon) | 10[IKE] authentication of ‘Zentrale’ (myself) succesful |
| IPSec(charon) | 10[IKE] IKE_SA Standort1_4[1] established between 198.51.100.75[Zentrale]…198.51.100.1[Filiale] |
| IPSec(charon) | 10[IKE] IKE_SA Standort1_4[1] established between 198.51.100.75[Zentrale]…198.51.100.1[Filiale] |
| IPSec(charon) | 10[IKE] scheduling reauthentication in 2593s |
| IPSec(charon) | 10[IKE] maximum IKE_SA lifetime 3133s |
| IPSec(charon) | 13[IKE] received DELETE for IKE_SA Standort_4[1] |
Phase 2
The normal connection setup
| If phase 2 is also configured correctly, the successful establishment of a CHILD_SA is documented in the livelog of both sides. | |
| Initiator-Log & Responder-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 05[IKE] CHILD_SA Zentrale_2{1} established with SPIs ca7520e3_i c562f9d6_o and TS 10.1.10.0/24 === 10.0.0.0/24 |
| IPSec(charon) | 05[IKE] CHILD_SA Zentrale_2{1} established with SPIs ca7520e3_i c562f9d6_o and TS 10.1.10.0/24 === 10.0.0.0/24 |
Incorrect subnet configuration
| If the configured subnets (the so-called traffic selectors) do not match in phase 2 of the initiator and responder, no tunnel can be set up on the previously established IKE_SA, i.e., no CHILD_SA is established. This information can be found in the responder’s livelog. | |
| Initiator-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 13[CFH] proposing traffic selectors for us: |
| IPSec(charon) | 13[CFG] 10.1.0.0/24 |
| IPSec(charon) | 13[CFG] proposing traffic selectors for other: |
| IPSec(charon) | 13[CFG] 11.0.0.0/24 |
| IPSec(charon) | 05[IKE] received INVALID_ID_INFORMATION error notify |
| Responder-Log | |
| Dienst | Nachricht |
| IPSec(charon) | 11[CFG] looking for a child config for 11.0.0.0/24 === 10.1.0.0/24 |
| IPSec(charon) | 11[CFG] proposing traffic selectors for us: |
| IPSec(charon) | 11[CFG] 10.0.0.0/24 |
| IPSec(charon) | 11[CFG] proposing traffic selectors for other: |
| IPSec(charon) | 11[CFG] 10.1.0.0/24 |
| IPSec(charon) | 11[IKE] no matching CHILD_SA config found |
IKEv2 Troubleshooting
The establishment of the connection with IKEv2 has been drastically simplified compared to IKEv1. It is now no longer divided into phase 1 (authentication) and phase 2 (tunnel establishment); instead, one message pair is used to exchange first the proposals and DH keys and then the authentication and the traffic selectors (subnets). This makes the connection setup easier and less susceptible to interference.
Connection setup
Connection is established
| Initiator-Log & Responder-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 11[CFG] selected proposal_ ESP_AES_CBC_128/HMAC_SHA2_256_128/NO_EXT_SEQ |
| IPSec(charon) | 11[CFG] selecting traffic selectors for us: |
| IPSec(charon) | 11[CFG] config: 10.1.0.0/24, received: 10.1.0.0/24 => match: 10.1.0.0/24 |
| IPSec(charon) | 11[CFG] selecting traffic selectors for ther: |
| IPSec(charon) | 11[CFG] config: 10.0.0.0/24, received: 10.0.0.0/24 0 => match: 10.0.0.0/24 |
| IPSec(charon) | 11[IKE] CHILD_SA Zentrale_3{2} established with SPIs c24bb346_i c8e52c94_o and T S 10.1.0.0/24 === 10.0.0.0/24 |
| IPSec(charon) | 11[IKE] CHILD_SA Zentrale_3{2} established with SPIs c24bb346_i c8e52c94_o and T S 10.1.0.0/24 === 10.0.0.0/24 |
Incorrect remote gateway address
| If the gateway address of the initiator and the remote gateway address specified in the responder configuration do not match, the connection attempt cannot be assigned. This is reported in the responder’s log. The initiator receives the error message «NO_PROPOSAL_CHOSEN». |
|
| Responder-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 11[CFG] looking for an ike config fo 198.51.100.75…198.51.100.1 |
| IPSec(charon) | 11[IKE] no IKE config for 198.51.100.75…198.51.100.1, sending NO_PROPOSAL_CHOSEN |
Incorrect ID Initiator
| If the configured remote ID does not match the ID reported by the initiator, the connection attempt cannot be assigned here either and is documented in the responder log. The initiator gets the error message AUTHENTICATION_FAILED. |
|
| Initiator-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 09[IKE] received AUTHENTICATION_FAILED error notify |
| Responder-Log | |
| Dienst | Nachricht |
| IPSec(charon) | 07[CFG] looking for pre-shared key peer configs matching 198.51.100.75…198.51.100.1[blubb] |
| IPSec(charon) | 07[IKE] no peer config found |
Incorrect ID Responder
| Vice versa, a responder ID other than the one configured at the initiator is reported accordingly in the initiator’s log. | |
| Initiator-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 05[IKE] IDir ‘blubb’ does not match to ‘198.51.100.75’ |
Incorrect PSK
| Initiator-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 13[IKE] received AUTHENTICATION_FAILED notify error |
| Responder-Log | |
| Dienst | Nachricht |
| IPSec(charon) | 10[IKE] tried 2 shared keys for ‘198.51.100.75’ — ‘198.51.100.1’, but MAC mismatched |
Incorrect subnet configuration
| If the configured subnets (the so-called traffic selectors) of initiator and responder do not match in the second step, no tunnel can be set up on the previously established IKE_SA, i.e., no CHILD_SA is established. This information can be found in the responder’s livelog. | |
| Initiator-Log | |
| Dienst | Nachricht |
|---|---|
| IPSec(charon) | 10[IKE] received T S_UNACCEPTABLE notify, no CHILD_SA built |
| IPSec(charon) | 10[IKE] failed to establish CHILD_SA, keeping IKE_SA |
| Responder-Log | |
| Dienst | Nachricht |
| IPSec(charon) | 05[CFG] looking for a child config for 10.0.0.0/24 === 11.1.0.0/24 |
| IPSec(charon) | 05[CFG] proposing traffic selectors for us: |
| IPSec(charon) | 05[CFG] 10.0.0.0/24 |
| IPSec(charon) | 05[CFG] proposing traffic selectors for other: |
| IPSec(charon) | 05[CFG] 10.1.0.0/24 |
| IPSec(charon) | 10[IKE] traffic selectors 10.0.0.0/24 === 11.1.0.0/24 inacceptable |
| IPSec(charon) | 10[IKE] failed to establish CHILD_SA, keeping IKE_SA |