HI,
I'm trying to perform an ipsec between a fortigate device and a teltonika rut950, and I can't get it, I'm looking for an idea of why or if there is no compatibility
Solved! Go to Solution.
What I can see in this IKE debug output is, despite what you showed on Teltonika side config, the router is initiating IKEv2 IPSec and the negotiation is successful all the way to the point the FGT side accepted and came up, then sent the reply back to the router. Then the router rejected.
I think the reason is you're using LAN side IP for identifier on the router's config. The FGT wouldn't check the received identifier unless you configured "peer ID" on the FGT side. But FGT doesn't send the identifier you configured on the router side unless you configure "local ID" on the FGT side.
First option I would try is to disable identification checking on the router side by like setting FQDN, and leave the FQDN config box empty, which I saw at Teltonika's KB.
https://wiki.teltonika-networks.com/view/IPsec_configuration_examples
Since this seems to be site-to-site, it wouldn't break anything without identification checking.
If you have to do it for security reason, you can try configuring peer ID/local ID on the FGT side to match the router side. There should be some FTNT KBs for that part of config but mostly for dialup IPSec situations.
Toshi
Hello,
Do you get any phase up ? 1 or 2 ?
First we need to try to get phase 1 up, can both devices ping each other ?
Are they behind a NAT ?
In the second image in the network part, you have "Dialup" selected, is the other device supposed to initiate the vpn tunnel creation process ?
You can use the command: diagnose debug application ike -1 , and diag debug enable. To see the IKE messages, and see if there is any incompatibility in phase 1.
Then you can use the commands to check phase2:
One of the key points must be, to see what IKE parameters does the Fortigate recieve and try to make them equal in the fortigate.
Best regards.
Created on 03-03-2022 11:02 AM Edited on 03-03-2022 11:03 AM
i check the status of ike negotiation I can see that the tunnel rises and the negotiations are successful, until at a certain point it falls
The scenario is a Fortigate device with a public IP and a Teltonik cellular network device, which does not have a public IP, so I chose the dial up option. In the debug messages, I can see that ike negotiations begin and these are successful, dynamic tunnels are created, routes are added, until. ike 3:Teltonika_0:167: dec D8E1C348F9957B6BD40C8667F56292282E20250800000002000000282900000040000000800000018 ike 3:Teltonika_0:167: received informational request ike 3:Teltonika_0:167: processing notify type AUTHENTICATION_FAILED ike 3:Teltonika_0:167: AUTH rejected by initiator ike 3:Teltonika_0:167: schedule delete of IKE SA d8e1c348f9957b6b/d40c8667f5629228 ike 3:Teltonika_0:167: scheduled delete of IKE SA d8e1c348f9957b6b/d40c8667f5629228 ike 3:Teltonika_0: deleting IPsec SA with SPI c31d7597 ike 3:Teltonika_0:Teltonika: deleted IPsec SA with SPI c31d7597, SA count: 0 ike 3:Teltonika:25: del route 30.0.10.0/255.255.255.0 oif Teltonika(47) metric 15 priority 0 ike 3:Teltonika_0: sending SNMP tunnel DOWN trap for Teltonika ike 3:Teltonika_0:Teltonika: delete
Did you remove the ike debug output at your "FW-LAB" after posting once? I saw it in email update but don't see it here.
But that output was for a different VPN coming from different IP with IKEv2.
You need to specify the peer IP when you run IKE debug with "diag vpn ike log-filter src-addr4 <peer_IP>".
Toshi
Ok, now much better.
AUTH rejected means either identity or prehsare key is not matching.
If I deleted some entries because it wouldn't let me upload the whole thing, I'm attaching the full output if you'd like to take a look, the device is one that I have to carry out the test before putting it in a productive environment, it is the only existing tunnel. It is worth mentioning that the device has multiple vdom enabled
https://mega.nz/file/ok1jWA6A#7JgoBUkfBqFL_myEW0ug_O_89btNGKkERjXCOuPH9Qo
What I can see in this IKE debug output is, despite what you showed on Teltonika side config, the router is initiating IKEv2 IPSec and the negotiation is successful all the way to the point the FGT side accepted and came up, then sent the reply back to the router. Then the router rejected.
I think the reason is you're using LAN side IP for identifier on the router's config. The FGT wouldn't check the received identifier unless you configured "peer ID" on the FGT side. But FGT doesn't send the identifier you configured on the router side unless you configure "local ID" on the FGT side.
First option I would try is to disable identification checking on the router side by like setting FQDN, and leave the FQDN config box empty, which I saw at Teltonika's KB.
https://wiki.teltonika-networks.com/view/IPsec_configuration_examples
Since this seems to be site-to-site, it wouldn't break anything without identification checking.
If you have to do it for security reason, you can try configuring peer ID/local ID on the FGT side to match the router side. There should be some FTNT KBs for that part of config but mostly for dialup IPSec situations.
Toshi
thanks Toshi, now is working
i cant see this option, add vertion firmware in picture. you can help me?
Select Forum Responses to become Knowledge Articles!
Select the “Nominate to Knowledge Base” button to recommend a forum post to become a knowledge article.
User | Count |
---|---|
1737 | |
1108 | |
752 | |
447 | |
240 |
The Fortinet Security Fabric brings together the concepts of convergence and consolidation to provide comprehensive cybersecurity protection for all users, devices, and applications and across all network edges.
Copyright 2024 Fortinet, Inc. All Rights Reserved.