Forum Discussion

Alessiom_265101's avatar
Alessiom_265101
Icon for Nimbostratus rankNimbostratus
May 23, 2016

F5 Ipsec VPN and ERROR: none message must be encrypted.

Greetings Folks.

 

Recently have been tasked to configure an IPSEC vpn between my company and another company's network. Managed to get all the configuration parameters and followed the following documents being new to F5:

 

https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-tmos-tunnels-ipsec-12-0-0/8.htmlconceptid https://support.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-tmos-tunnels-ipsec-12-0-0/11.htmlconceptid

 

Stumbled on many many different types of errors and learned a lot! However, for much i'd love to linger and understand all the subtle changes in the implementation (or nerfing?) of racoon module in the different releases of the TMOS need to get things up and running!

 

During the tunnel establishment (phase 1) i get the following error "ERROR: none message must be encrypted" is there someone out there that has experienced this before?

 

Many thanks in advance

 

Cheers

 

Alessio

 

  • One reason for the message is covered in K35087734.

     

    The log is not due to the specific misconfiguration mentioned in K35087734, but because racoon (the IPsec daemon) is at the encrypted stage of negotiating an SA, but unexpectedly receives an unencrypted ISAKMP message from the peer.

     

  • hello, not much experience but from googled that error message : That means the peer is trying to send you data without encrypting it, or it's sending data on a connection that you no longer considers valid.

     

    and :

     

    Just want to add that this can also mean the shared secret does not match. I just ran into this error recently. The remote end (Checkpoint) revealed in the logs that it could be a shared secret mismatch. Sure enough it was off on one character. The pfsense side was initiating the connection.

     

  • zeiss_63263's avatar
    zeiss_63263
    Historic F5 Account

    One reason for the message is covered in K35087734.

     

    The log is not due to the specific misconfiguration mentioned in K35087734, but because racoon (the IPsec daemon) is at the encrypted stage of negotiating an SA, but unexpectedly receives an unencrypted ISAKMP message from the peer.