Thread: [Ipsec-tools-devel] Hybrid mode authentication
Brought to you by:
mit_warlord,
netbsd
From: Pj <pj...@ba...> - 2007-08-27 17:50:29
Attachments:
Xauth_exchange.log
|
Hi, we are using hybrid mode authentication in our configuration for ipsec remote access to our vpn gateway. Peers seem to quite often fail the Xauth exchange. When the the responder has sent an ISAKMP_CFG_REQUEST message to the initiator, it never seem to get ISAKMP_CFG_REPLY message back. Even though the xauth exchange has failed the responder continues to try start ph2 for hours. The attached log file shows an example case with one peer (I have added ip address information for couple of log messages). Usually there is few clients in same condition where the xauth has failed and racoon keeps flooding those error logs since ph2 cannot be started. - If the peer does not reply during the extended authentication exchange, not even with XAUTH_STATUS set to FAIL, is it acceptable that the responder keeps trying to start ph2 for hours? - Any idea on trying to resend the ISAKMP_CFG_REQUEST message again in case peer does not reply? - Has anyone had similar experiences of possible issues in the Xauth message exchanges? Some peers seem to recover from this condition by restarting racoon. Unfortunately, I have not been able to get possibility to debug this on the client side so far. Best Regards, Petri |
From: Pj <pj...@ba...> - 2007-08-28 17:14:23
|
I noticed that a probable reason for this is a corrupted isakmp generic payload header. There was WARNING log message for short payload and seems to be a result of false payload header. 1) For example, I get e.g. following isakmp data in successful logins: ISAKMP Header: bda445af 5899541e Initiator cookie dafeab6b 3910b7d1 Responder cookie 08100601 Next payload 8 (HASH), Exchange type 6 (Certificate) fa7e6345 Message ID 00000044 Length Generic payload header for 'Hash': 0e000018 ef2f083a a469b54e 53bce79c 2ba4f0d4 9c0c7348 Generic payload header for 'Attribute': 0000000c 04004ad2 c08f0000 f21f7e03 Both generic payload headers seems ok. 2) When the peer login failed there seemed to be problems in the generic payload header for payload type 'hash' as follows: ISAKMP Header: f14fcaee 5609dabb Initiator cookie 78c4c6d8 81637ea9 Responder cookie 08100601 Next payload 8 (HASH), Exchange type 6 (Certificate) 822011ca Message ID 0000005c Length Corrupted generic payload header for 'Hash': a2ed71b6 e1c97821 a69c84c9 5a7ca27b 1726db78 1f57cab7 Other generic payload header: 00000024 02009fb6 c0880000 40890008 77736830 31343236 408a0008 65737572 366a7a69 bf9eec03 Any ideas why the generic payload header would be corrupted as in this example? Regards, Petri On Mon, 2007-08-27 at 20:48 +0300, Pj wrote: > Hi, > > we are using hybrid mode authentication in our configuration for ipsec > remote access to our vpn gateway. Peers seem to quite often fail the > Xauth exchange. When the the responder has sent an ISAKMP_CFG_REQUEST > message to the initiator, it never seem to get ISAKMP_CFG_REPLY message > back. Even though the xauth exchange has failed the responder continues > to try start ph2 for hours. > > The attached log file shows an example case with one peer (I have added > ip address information for couple of log messages). Usually there is few > clients in same condition where the xauth has failed and racoon keeps > flooding those error logs since ph2 cannot be started. > > - If the peer does not reply during the extended authentication > exchange, not even with XAUTH_STATUS set to FAIL, is it acceptable that > the responder keeps trying to start ph2 for hours? > > - Any idea on trying to resend the ISAKMP_CFG_REQUEST message again in > case peer does not reply? > > - Has anyone had similar experiences of possible issues in the Xauth > message exchanges? > > Some peers seem to recover from this condition by restarting racoon. > Unfortunately, I have not been able to get possibility to debug this on > the client side so far. > > Best Regards, > Petri > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ Ipsec-tools-devel mailing list Ips...@li... https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel |
From: Pj <pj...@ba...> - 2007-08-28 19:43:06
|
Sorry, naturally the exchange type is Mode Configuration not 'certificate'. Please note, that the hash payload header has always been corrupted in those cases I have debugged when the extended authentication has failed. On Tue, 2007-08-28 at 20:12 +0300, Pj wrote: > I noticed that a probable reason for this is a corrupted isakmp generic > payload header. There was WARNING log message for short payload and > seems to be a result of false payload header. > > > 1) For example, I get e.g. following isakmp data in successful logins: > > ISAKMP Header: > > bda445af 5899541e Initiator cookie > dafeab6b 3910b7d1 Responder cookie > 08100601 Next payload 8 (HASH), Exchange type 6 (Certificate) > fa7e6345 Message ID > 00000044 Length > > Generic payload header for 'Hash': > > 0e000018 ef2f083a a469b54e 53bce79c 2ba4f0d4 9c0c7348 > > Generic payload header for 'Attribute': > > 0000000c 04004ad2 c08f0000 f21f7e03 > > > Both generic payload headers seems ok. > > > > 2) When the peer login failed there seemed to be problems in the generic > payload header for payload type 'hash' as follows: > > > ISAKMP Header: > > f14fcaee 5609dabb Initiator cookie > 78c4c6d8 81637ea9 Responder cookie > 08100601 Next payload 8 (HASH), Exchange type 6 (Certificate) > 822011ca Message ID > 0000005c Length > > Corrupted generic payload header for 'Hash': > > a2ed71b6 e1c97821 a69c84c9 5a7ca27b 1726db78 1f57cab7 > > Other generic payload header: > > 00000024 02009fb6 c0880000 40890008 77736830 31343236 408a0008 65737572 > 366a7a69 bf9eec03 > > > Any ideas why the generic payload header would be corrupted as in this > example? > > > Regards, > Petri > > > > > > > On Mon, 2007-08-27 at 20:48 +0300, Pj wrote: > > Hi, > > > > we are using hybrid mode authentication in our configuration for ipsec > > remote access to our vpn gateway. Peers seem to quite often fail the > > Xauth exchange. When the the responder has sent an ISAKMP_CFG_REQUEST > > message to the initiator, it never seem to get ISAKMP_CFG_REPLY message > > back. Even though the xauth exchange has failed the responder continues > > to try start ph2 for hours. > > > > The attached log file shows an example case with one peer (I have added > > ip address information for couple of log messages). Usually there is few > > clients in same condition where the xauth has failed and racoon keeps > > flooding those error logs since ph2 cannot be started. > > > > - If the peer does not reply during the extended authentication > > exchange, not even with XAUTH_STATUS set to FAIL, is it acceptable that > > the responder keeps trying to start ph2 for hours? > > > > - Any idea on trying to resend the ISAKMP_CFG_REQUEST message again in > > case peer does not reply? > > > > - Has anyone had similar experiences of possible issues in the Xauth > > message exchanges? > > > > Some peers seem to recover from this condition by restarting racoon. > > Unfortunately, I have not been able to get possibility to debug this on > > the client side so far. > > > > Best Regards, > > Petri > > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. > > Still grepping through log files to find problems? Stop. > > Now Search log events and configuration files using AJAX and a browser. > > Download your FREE copy of Splunk now >> http://get.splunk.com/ > > _______________________________________________ Ipsec-tools-devel mailing list Ips...@li... https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. > Still grepping through log files to find problems? Stop. > Now Search log events and configuration files using AJAX and a browser. > Download your FREE copy of Splunk now >> http://get.splunk.com/ > _______________________________________________ > Ipsec-tools-devel mailing list > Ips...@li... > https://lists.sourceforge.net/lists/listinfo/ipsec-tools-devel |
From: <ma...@ne...> - 2007-08-28 20:08:16
|
Pj <pj...@ba...> wrote: > Sorry, naturally the exchange type is Mode Configuration not > 'certificate'. Please note, that the hash payload header has always been > corrupted in those cases I have debugged when the extended > authentication has failed. I somewhat recall that you could get unexpected suff when the IV get out of sync. The problem is that the IV has to be changed after each exchange, but some exchanges take more than just a request and a reply. I had many problems with that when initially implementing hybrid authentication in ipsec-tools, but it's quite far away now: I'm quite unable to help debugging your problem. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz ma...@ne... |