This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Weird Errors in IPSec Log, Clients can't connect.

Hi, I've been having similar problems on and off for quite sometime. At one point I was receiving the same errors I am now, and after rebooting the firewall, the VPN connections worked fine.

The specific errors I'm referring to are below. I have double, triple, quadruple checked every setting, AND astaro support requested a login to check the system config which they OK'd.

The log entries are in the order they appear in the logs, the client reports the failure occuring at the first stage of phase2 IPSec with the error "Exchanging IPSec proposals failed"

The client is SSH Sentinel 1.4 build 190
---
;;discarding duplicate packet; already STATE_MAIN_R2
;;cannot respond to IPsec SA request because no connection is known for 192.168.2.0/24===x.x.x.x...x.x.x.x[C=us, ST=MN, L=x, O=x, OU=IT, CN=x, E=no@spam.com]===x.x.x.23/32
;;sending encrypted notification INVALID_ID_INFORMATION to x.x.x.x:500
;;Quick Mode I1 message is unacceptable because it uses a previously used Message ID 0xbe7a5a32 (perhaps this is a duplicated packet)
;;ERROR: recvfrom on eth1 failed; Pluto cannot decode source sockaddr in rejection: unknown source. Errno 11: Resource temporarily unavailable

My client is setup like this.
X509 Certs
*IPSec/IKE settings*
Enc. Algorithm: AES Rijndael
Integrity: SHA1 192bit
IKE GROUP: MODP 1536 (5)

*Virtual IP*
192.168.1.23/255.255.255.0 


This thread was automatically locked due to age.
  • You didn't speak to me ;-)

    -> no connection is known for 192.168.2.0/24===x.x.x.x...x.x.x.x

    indicates that you have defined wrong, not matching,  network settings, maybe
    a wrong netmask or remote network on the client side or a faulty local network
    on the ASL side.

    read you
    o|iver  
  • You're right, I did not speak with you, and you were oh so correct.

    I had set the "Internal Subnet" to none instead of that of the ineternal LAN 192.168.2.0/255.255.255.0 yet it was defined on the client side. My bad, now I know. :-)

    Everything is working wonderfully and I noticed today that my client had established a connection over his verizon wireless link which made him quite pleased.

     
  • We have exactly the same prob. ASL 4.009 and Certs.
    We tried Sentinel 1.4-190 and 1.4.1 - no change. It seems to be a problem with 4.009. We have al lot of customers running with ASL 4.008 and CERTS. We tried a new test-install for an ASL. Nothing. Have you solved the problem ?