ignoring unsupported INFORMATIONAL message 0

[Scott_Perry]

I am attempting to setup an IPsec VPN and this is the message I get when it attempts to connect. ignoring unsupported INFORMATIONAL message 0 Does anyone know what that means?

[howardsinc]

I'm working on a IPsec VPN issue right now with the remote peer being a Cisco ASR doing VRF-IPsec.

While debugging, I received this same error message. The remote sides debug display the following:

*********************************ASR Debug

*Sep 17 20:58:05.715: ISAKMP:(0): vendor ID is DPD *Sep 17 20:58:05.715: ISAKMP:(0): processing vendor id payload *Sep 17 20:58:05.715: ISAKMP:(0): vendor ID seems Unity/DPD but major 2 mismatch *Sep 17 20:58:05.715: ISAKMP:(0):No pre-shared key with 40.x.x.132! *Sep 17 20:58:05.717: ISAKMP : Scanning profiles for xauth ... RExET-VRF-PROFILE *Sep 17 20:58:05.717: ISAKMP:(0):Checking ISAKMP transform 1 against priority 10 policy *Sep 17 20:58:05.717: ISAKMP:      life type in seconds *Sep 17 20:58:05.717: ISAKMP:      life duration (basic) of 28800 *Sep 17 20:58:05.717: ISAKMP:      encryption AES-CBC *Sep 17 20:58:05.717: ISAKMP:      keylength of 256 *Sep 17 20:58:05.717: ISAKMP:      auth pre-share *Sep 17 20:58:05.717: ISAKMP:      hash SHA *Sep 17 20:58:05.717: ISAKMP:      default group 2 *Sep 17 20:58:05.717: ISAKMP:(0):Preshared authentication offered but does not match policy! *Sep 17 20:58:05.717: ISAKMP:(0):atts are not acceptable. Next payload is 0 *Sep 17 20:58:05.717: ISAKMP:(0):no offers accepted! *Sep 17 20:58:05.719: ISAKMP:(0): phase 1 SA policy not acceptable! (local 10.1.5.15 remote 40.x.x.132) *Sep 17 20:58:05.719: ISAKMP (0): incrementing error counter on sa, attempt 1 of 5: construct_fail_ag_init *Sep 17 20:58:05.719: ISAKMP:(0): Failed to construct AG informational message. *Sep 17 20:58:05.719: ISAKMP:(0): sending packet to 40.128.70.132 my_port 500 peer_port 500 (R) MM_NO_STATE *Sep 17 20:58:05.719: ISAKMP:(0):Sending an IKE IPv4 Packet. *Sep 17 20:58:05.719: ISAKMP:(0):peer does not do paranoid keepalives.

=================================

as you can see the remote side states we are not sending a PSK, but while testing the connection to the a Lab Fortigate we can successfully build an IPsec VPN. The remote side is involving Cisco TAC to investigate config.

My conclusion, the remote side is not configured correctly to bring up phase1 and the reason why is an information message not supported by the fortigate. I will update this thread if I found out what the fix is for the remote side.

Best of luck!

[emnoc]

Do you have DPD enabled? That would be my 1st guess without seeing the cfgs. You could probably catch this in tshark/wireshark and validate.

[howardsinc]

I took a look on my config and DPD was currently on I turned off an received same error:

ke 9: comes 216.x.x.250:500->40.x.x.132:500,ifindex=133.... ike 9: IKEv1 exchange=Informational id=db15c6a913fd97e4/b716e6b3f2ca12c1 len=384 id=36871 trace_id=51626 msg="Find an existing session, id-328b36d0, reply direction" ike 9: in DB15C6A913FD97E4B716E6B3F2CA12C10B100500000000000000018000000164000000010100000E0D00015800000001000000010000000000007FD61121B858020000000000000000007FD60C7295CC58B82111D67F0000000000000A3A4170E5C100C000000000B0385D12D67F00005029B10DD67F0000CF1B68080000000000007FD60DB12940000000000A3A4170000000000A3623280200000000000000000000000000000000007FD61121B858B0385D12D67F000000007FD6125D38B0300000000000000058B82111D67F000000007FD60DB1294400007FD60DB128F000007FD61121B88888B82111D67F000000000000017F0000AB176808000000008029B10DD67F000052A462080000000000007FD61121BDBC20CB9C120000000000000000000000000000000000000000C029B10DD67F0000DCBE9B080000000000007FD6125D38B0A0876612D67F000000007FD61121B85800000003000000000000000500000000E783D80300000000F029B10DD67F000017BE9B0800000000 ike 9:258841_VPN:28514329: ignoring unsupported INFORMATIONAL message 0.

[emnoc]

Qs;

Did you disable before sides ( FGT and ASR )?

So are you just worried about the informational message and does the  VPn establish?

I'm sure this is just informational and probably some type of vendor specific messages between both peers.

[bcallan]

In my case, with Fortigate->Sonicwall, this turned out to be Local ID Type.  FG30d running 5.4.0 uses FQDN type by default, but Sonicwall does not like this with remote peer type set to Domain Name, Key ID or Firewall ID.  Setting Sonicwall remote peer type to Key ID and specifying "set localid-type=keyid" in P1 solved the problem.

[MehmetKaya]

From Site-to-Site VPN check the below configuration probable one of them is not matched.

IPSec Tunnels > Edit VPN Tunnels > Authentication Phase 1 Proposal  ( check Engryption and Authentication information - seems they are not matched with another side)

Plz feedback and rate if it works.