Support Forum
The Forums are a place to find answers on a range of Fortinet products from peers and product experts.
eb40
New Contributor

Is it possible to use ipsec Over Ipsec.

Hello,

 

Currently I am working on configuration below and can not make it work. Point is that local PC and EC2 PC must communicate with each other. There is APN router which is not managed by me , so using red ipsec2 network to make required site to site connection. 

This scheme was used for long time but with additional PC in local network which was making required IPsec. Now I want to get rid of it and move everything to FortiGate. This is FortiGate F40 OS 7.0.0 . 

Ipsec configurationIpsec configuration

 

Could any body take a look and advise if this is even possible ? 

If it is maybe there some some special (like "site to site") name for configuration I could google?

 

Thanks in advance.

 

19 REPLIES 19
scan888
Contributor

Hi eb40

 

This should work. I have not tried it myself yet.
On the firewall right you have to select the interface via CLI, because the other IPsec interface via GUI is not available.

 

 Configuration on Firewall right:

 

config vpn ipsec phase1-interface
set interface {your IPsec Interface}
...
end

 

Interleaving protocols is never recommended and leads to a smaller MTU size. Do not forget this and configure the correct MTU size.

 

As I can see you have prepared a lab already. Try it and figure it out, if it's work as expected.

 

Regards,

Andy

- Have you found a solution? Then give your helper a "Like" and mark the solution.
- Have you found a solution? Then give your helper a "Like" and mark the solution.
abarushka
Staff
Staff

Hello,

 

I would agree with scan888 that it should be technically possible, but design is questionable.

FortiGate
eb40
New Contributor

Thank you for encouraging opinion. I have experimented and both tunnels works but no traffic is flowing. Dont think that routing or firewall is  a problem. Thing that I found with 

commands:

diag sniff pack any 'esp' 4 0 1

diag debug app ike -1

 

That there is almost always when pinging "ignoring invalid SPI" error in the log,  looking thru the log I have impression that ipsec2 packets are recognized by ipsec1 like packets with wrong SPI.

 

Is there anything to be done to somehow prevent ipsec2 packets from being misstreeted?

 

 

 

 

scan888

Hi @eb40 

 

"invlaid SPI" indicate that no packet match an phase2 selector. 

To get a better view try the following troubleshooting steps:

1. check the outgoing IP address

diag sniffer packet any 'host <source IP>' 4 0 a

-> Check first, if the packet using the right IPsec Interface and what is the source IP on the IPsec Tunnel side

 

2. Check the IKE log on the "otherside" Fortigate

diag debug en
diag debug app ike -1

-> Check if the receive packet has the correct source IP (should be the same as the source IP from step 1).

 

3. Check the routing table on the "otherside" Fortigate

 

If all not help, what is your IPsec phase 2 configuration on both sides?

- Have you found a solution? Then give your helper a "Like" and mark the solution.
- Have you found a solution? Then give your helper a "Like" and mark the solution.
eb40
New Contributor

Hi,

 

I did what you sugest but did not understand results. I did not found ip of sender  but not sure where to expect it.

Here are Ips of the test environment:

eb40_0-1673946108623.png

 

All start with 192.168.xx.xx

When pinging from EC2 I get :

eb40_1-1673946151278.png

Fortinet shows:

FortiGate-VM64-KVM # diagnose debug application ike -1
Debug messages will be on for 30 minutes.

FortiGate-VM64-KVM # diagnose debug console

FortiGate-VM64-KVM # diagnose debug enable

FortiGate-VM64-KVM # ike 0: unknown SPI b2b5756c 12 192.168.11.2:0->192.168.21.1
ike 0: found to_tel1 192.168.21.1 12 -> 192.168.11.2:500
ike 0:to_tel1:3: send INVALID-SPI b2b5756c
ike 0:to_tel1:3: enc B642B5456073DBB33C883056F0271920081005015162DE6B000000400B00001470C8E154CB15C359219748F03A530A6500000010000000010304000BB2B5756C
ike 0:to_tel1:3: out B642B5456073DBB33C883056F0271920081005015162DE6B000000447ADBD8A9A6215B3D0DCB9ED87C0C5C7B211F06D4A33D9FC7F5D52DAE57DD5140D4CC0CF81A829C03
ike 0:to_tel1:3: sent IKE msg (INVALID-SPI): 192.168.21.1:500->192.168.11.2:500, len=68, vrf=0, id=b642b5456073dbb3/3c883056f0271920:5162de6b
ike 0: comes 192.168.11.2:500->192.168.21.1:500,ifindex=12,vrf=0....
ike 0: IKEv1 exchange=Quick id=b642b5456073dbb3/3c883056f0271920:36698e70 len=356 vrf=0
ike 0: in B642B5456073DBB33C883056F02719200810200136698E7000000164147997D8A2407144400834A74C4BA2D855C6364629FBB3D72BCE35927B6C85AF4117A4B7128C3BAC826FFD8E5D5847D3644748D11483E33919B5FF041A17B95C9BE34F0342DB120DDAF1AE6D3D8E9D2876A0507C2DDDF9E144FB6177BB3ED4950B6DC2D50AB58E02875979D50E150A96621E7A01B70A5C233E4169F5BA803CAC9AB08D4D05AAAA4126A530B7C61795A86BE83F9103041BFF943BA34F933AE196DB065F60B8C4645F6E9940ED647ADF43915F0814B9F79C9D427C4AFC0269731AD29F5B70D943BA5FF45316A08AB8FD336C6FE7E112BF94CE803538E69D024E0B02623A229656424CD6EC04EB9F15F242F87C8C6DF0FA9F6F4BD588B0C67D0DFD162C91D51064F3E806E69974F8B028FC9F93FECEA78CF3B2FE5E1327AC9F602B0C5A49BCBA9C8E1F7F76C660AA10E8C9F6D79E7C8DBD7C904D3CE8F30FCEBEBDC74D4E072EA17FB6
ike 0:to_tel1:3:20: responder received first quick-mode message
ike 0:to_tel1:3: dec B642B5456073DBB33C883056F02719200810200136698E700000016401000014B286C7610194717E314EE0DDC842CA8E0A000034000000010000000100000028010304018B44E6FF0000001C01020000800100018002A8C080040001800500018003000504000014236C77E579DC66A700223BFC5A717C2D050000C4393A93BD7CCA2EC4159B7F45D2DEB5001A754E165C1EB60C6CCD3EA26A0325C5D3361539C1594C8F09B1094224F39B5CD61F579E356ECBBE3DC45983E99821271F1889E1FB19787D15321F12E1E82A25CF7CD9FCC9532F0CDE1EE8C03777C9FEED44CCD425611B52323EBC52FF41491FDE6B18AEF8A0353787B5DC01B0CD7536390C4ED75BA41F0527228E864749AEFC66EC8EB0F63AF9E2310616FF193F687078B2E6D267835AEE426ED5388C40B54314CFA33B5474448511A2488A2AA7A0790500001004000000C0A86F00FFFFFF000000001004000000C0A81500FFFFFF004000C0667C218107
ike 0:to_tel1:3:20: peer proposal is: peer:0:192.168.111.0-192.168.111.255:0, me:0:192.168.21.0-192.168.21.255:0
ike 0:to_tel1:3:to_tel1:20: trying
ike 0:to_tel1:3:to_tel1:20: matched phase2
ike 0:to_tel1:3:to_tel1:20: autokey
ike 0:to_tel1:3:to_tel1:20: my proposal:
ike 0:to_tel1:3:to_tel1:20: proposal id = 1:
ike 0:to_tel1:3:to_tel1:20:   protocol id = IPSEC_ESP:
ike 0:to_tel1:3:to_tel1:20:   PFS DH group = 5
ike 0:to_tel1:3:to_tel1:20:      trans_id = ESP_DES
ike 0:to_tel1:3:to_tel1:20:      encapsulation = ENCAPSULATION_MODE_TUNNEL
ike 0:to_tel1:3:to_tel1:20:         type = AUTH_ALG, val=MD5
ike 0:to_tel1:3:to_tel1:20: incoming proposal:
ike 0:to_tel1:3:to_tel1:20: proposal id = 1:
ike 0:to_tel1:3:to_tel1:20:   protocol id = IPSEC_ESP:
ike 0:to_tel1:3:to_tel1:20:   PFS DH group = 5
ike 0:to_tel1:3:to_tel1:20:      trans_id = ESP_DES
ike 0:to_tel1:3:to_tel1:20:      encapsulation = ENCAPSULATION_MODE_TUNNEL
ike 0:to_tel1:3:to_tel1:20:         type = AUTH_ALG, val=MD5
ike 0:to_tel1:3:to_tel1:20: negotiation result
ike 0:to_tel1:3:to_tel1:20: proposal id = 1:
ike 0:to_tel1:3:to_tel1:20:   protocol id = IPSEC_ESP:
ike 0:to_tel1:3:to_tel1:20:   PFS DH group = 5
ike 0:to_tel1:3:to_tel1:20:      trans_id = ESP_DES
ike 0:to_tel1:3:to_tel1:20:      encapsulation = ENCAPSULATION_MODE_TUNNEL
ike 0:to_tel1:3:to_tel1:20:         type = AUTH_ALG, val=MD5
ike 0:to_tel1:3:to_tel1:20: set pfs=MODP1536
ike 0:to_tel1:3:to_tel1:20: using tunnel mode.
ike 0:to_tel1:3:to_tel1:20: generate DH public value request queued
ike 0:to_tel1:3:to_tel1:20: compute DH shared secret request queued
ike 0:to_tel1: schedule auto-negotiate
ike 0:to_tel1:3:to_tel1:20: replay protection enabled
ike 0:to_tel1:3:to_tel1:20: SA life soft seconds=42933.
ike 0:to_tel1:3:to_tel1:20: SA life hard seconds=43200.
ike 0:to_tel1:3:to_tel1:20: IPsec SA selectors #src=1 #dst=1
ike 0:to_tel1:3:to_tel1:20: src 0 4 0:192.168.21.0/255.255.255.0:0
ike 0:to_tel1:3:to_tel1:20: dst 0 4 0:192.168.111.0/255.255.255.0:0
ike 0:to_tel1:3:to_tel1:20: add IPsec SA: SPIs=b2b5756d/8b44e6ff
ike 0:to_tel1:3:to_tel1:20: IPsec SA dec spi b2b5756d key 8:C5739B1E63453B12 auth 16:E34D76B9271C0EB8ABD9CD2EA3C641C2
ike 0:to_tel1:3:to_tel1:20: IPsec SA enc spi 8b44e6ff key 8:8E472DD4BDA5C8FE auth 16:F2B94013E578BF7E42C20ED330138F14
ike 0:to_tel1:3:to_tel1:20: added IPsec SA: SPIs=b2b5756d/8b44e6ff
ike 0:to_tel1:3: enc B642B5456073DBB33C883056F02719200810200136698E700000015C01000014C04A16596955E2EFC11D4C17EB24EE2B0A00003400000001000000010000002801030401B2B5756D0000001C01020000800100018002A8C080040001800500018003000504000014CE5FB9607E67A3D0F1F76E4159186B85050000C41E2781213C6DD88F16EE77DCD6BF1E069A4ECE224F0770094DACEF9948CC792A6D374DE955B044CE21844B99CDA4CFCCABD82B6ADD6BB7EFD938FDD459B3CAA7AD6AFB1FE8F75E9B75689712ACD636563BD7B408943EC36D29BD2D62A8652E709623E925AF232473B44655EC830DA1C58F261C651A87542A33989ADE5302257C46BCF039A799B0C79682BD15085DE73C0C4AC936970E91A62B308D45B04491D53168EF9ED979A5F1AA0753D6B3B4F50CEAD6D0D01752BF345C2FC587DCE4642E0500001004000000C0A86F00FFFFFF000000001004000000C0A81500FFFFFF00
ike 0:to_tel1:3: out B642B5456073DBB33C883056F02719200810200136698E70000001642C79DB2BBFB6D43E1E897BC81433AC320462F1E9FEEC20934FC6950AC38E7042A1CF65F4652450B613E0D6936C70048BE9397991AC84B4EA778B9CB0A93490C72705758BC6B6131C44F23655E4FB87C25681BE51F575784867F187A4E357A09D3A4965197B2D47FB7AB38F8EEA456FF62FD4C4E3E7CC6828981D4F65DF147C5AF9206238EB3717556BEDBB38DCCD6B21D030BD305A5BACD8AEF3A5596B247B25649F8D64823849B1823CBC3B8F0C6B5B103777D45696C67C3BDAF4D828A007DBFBD5725EC9CE17AF135BD99C06DEDF0C5C6FE6A7EEE6018574EC40F21D5554FEF95056EFF6A4038BCF8623CF82B19084CDBFD66369B3BE9EFD68C10F60C725073494ADFBFE74E1EBC83B3D95983E2F550FE30598A4AAF98859B235DA40B4E0B9AD31199E4BC8217BF3894AD3402324452FF9C91318AF74FA70EB3FD3606B6F05D412B52A8E30B6FE
ike 0:to_tel1:3: sent IKE msg (quick_r1send): 192.168.21.1:500->192.168.11.2:500, len=356, vrf=0, id=b642b5456073dbb3/3c883056f0271920:36698e70
ike 0:to_tel1: IPsec SA 8b44e6fb/b2b57569 hard expired 12 192.168.21.1->192.168.11.2:0 SA count 3 of 3
ike 0:to_tel1: IPsec SA b2b57569 delete failed: 2
ike 0:to_tel1:3: send IPsec SA delete, spi b2b57569
ike 0:to_tel1:3: enc B642B5456073DBB33C883056F027192008100501C46D2B5D000000400C000014CB57DA2B5432BA35D149DFB2ECA032E7000000100000000103040001B2B57569
ike 0:to_tel1:3: out B642B5456073DBB33C883056F027192008100501C46D2B5D00000044207BD5966A07CD074DDD97202C291A15F4CE925FBBC19E8ADE6C4EFA2366706207B7925E562C3BB7
ike 0:to_tel1:3: sent IKE msg (IPsec SA_DELETE-NOTIFY): 192.168.21.1:500->192.168.11.2:500, len=68, vrf=0, id=b642b5456073dbb3/3c883056f0271920:c46d2b5d
ike 0: comes 192.168.11.2:500->192.168.21.1:500,ifindex=12,vrf=0....
ike 0: IKEv1 exchange=Quick id=b642b5456073dbb3/3c883056f0271920:36698e70 len=52 vrf=0
ike 0: in B642B5456073DBB33C883056F02719200810200136698E7000000034E0A7F07AD53EF254ED92BD4E187BC4EAB8269637F38D149C
ike 0:to_tel1:3: dec B642B5456073DBB33C883056F02719200810200136698E70000000340000001400BB56F99AF219965E65B412C10E9D7B02B77303
ike 0:to_tel1:to_tel1:20: send SA_DONE SPI 0x8b44e6ff
ike 0: unknown SPI b2b5756d 12 192.168.11.2:0->192.168.21.1
ike 0: found to_tel1 192.168.21.1 12 -> 192.168.11.2:500
ike 0:to_tel1:3:to_tel1:20: ignoring invalid SPI b2b5756d, IPsec SA just negotiated
ike 0: unknown SPI b2b5756d 12 192.168.11.2:0->192.168.21.1
ike 0: found to_tel1 192.168.21.1 12 -> 192.168.11.2:500
ike 0:to_tel1:3:to_tel1:20: ignoring invalid SPI b2b5756d, IPsec SA just negotiated
ike shrank heap by 159744 bytes
ike 0: comes 192.168.11.2:500->192.168.21.1:500,ifindex=12,vrf=0....
ike 0: IKEv1 exchange=Informational id=b642b5456073dbb3/3c883056f0271920:25af12dd len=84 vrf=0
ike 0: in B642B5456073DBB33C883056F02719200810050125AF12DD00000054C7E8D92EA715D84BC7A67ED0EE9401F6F9151F858DFAF8A96F2C46758E0B2D97468B05213653C68737EB95A15AACB8FB21504F4A53B2A1B3
ike 0:to_tel1:3: dec B642B5456073DBB33C883056F02719200810050125AF12DD000000540B0000142FA335EF849469193F87DCD7DE23CC4C000000200000000101108D28B642B5456073DBB33C883056F0271920000000062BD29403
ike 0:to_tel1:3: notify msg received: R-U-THERE
ike 0:to_tel1:3: enc B642B5456073DBB33C883056F027192008100501138BF108000000500B000014BB884A1ED765F5FCDF4DB5D2E00BDF9B000000200000000101108D29B642B5456073DBB33C883056F027192000000006
ike 0:to_tel1:3: out B642B5456073DBB33C883056F027192008100501138BF10800000054B98CF6705808A6B1038E02BE05F0FCB09BC52571A6BB1A46D0B62DC7871C2A49F8A489EB130024CAA188C85E43C8322D36D064D44E600DC7
ike 0:to_tel1:3: sent IKE msg (R-U-THERE-ACK): 192.168.21.1:500->192.168.11.2:500, len=84, vrf=0, id=b642b5456073dbb3/3c883056f0271920:138bf108
ike 0:to_159: link is idle 3 192.168.1.114->192.168.1.159:0 dpd=2 seqno=1 rr=0
ike 0:to_159:1: send IKEv1 DPD probe, seqno 1
ike 0:to_159:1: enc E93D657FD5E34BB5A16FB85564CE7D8C08100501CB478B94000000500B000014AF117685F93DD1CB161215E9F0775F7A000000200000000101108D28E93D657FD5E34BB5A16FB85564CE7D8C00000001
ike 0:to_159:1: out E93D657FD5E34BB5A16FB85564CE7D8C08100501CB478B940000005409E3632BDE421CE6220C01DFB22AD01C5DC96FC0E13C1A67E7AA0BCA3E4B7C11F7BC8EA9DB3217E21AA1BCC87F800F0C60225E823034A1AF
ike 0:to_159:1: sent IKE msg (R-U-THERE): 192.168.1.114:500->192.168.1.159:500, len=84, vrf=0, id=e93d657fd5e34bb5/a16fb85564ce7d8c:cb478b94
ike 0: comes 192.168.1.159:500->192.168.1.114:500,ifindex=3,vrf=0....
ike 0: IKEv1 exchange=Informational id=e93d657fd5e34bb5/a16fb85564ce7d8c:1420110d len=84 vrf=0
ike 0: in E93D657FD5E34BB5A16FB85564CE7D8C081005011420110D000000543F30CE9E792CAE90BFD7FDD0EF96C4773E57F61D4C9F082FE7C8B95808C90F5FF1EB9494D39FBABCC9B3A644012A41183F147111B4104E3C
ike 0:to_159:1: dec E93D657FD5E34BB5A16FB85564CE7D8C081005011420110D000000540B000014FD53B076077D4BD095A1FC0D87DA93F0000000200000000101108D29E93D657FD5E34BB5A16FB85564CE7D8C00000001A23B3B03
ike 0:to_159:1: notify msg received: R-U-THERE-ACK
Timeout

 

Where should I expect sender IP in this log ?

From what I see everything seams right exept this "unknown SPI "

 

Routing table of fortinet device :

 

eb40_3-1673946505389.png

 

scan888

I guess something is wrong here:

to_tel1:3: sent IKE msg (R-U-THERE-ACK): 192.168.21.1:500->192.168.11.2:500

 

Because 192.168.11.2 is the "wan" IP-Address from the left-Fortigate and 192.168.21.1 is the "lan" IP-address from the right Fortigate.

 

  • Where is your first IPsec tunnel?
  • What is the name of the interface of your first IPsec connection on the left Fortigate?
  • What are the IP-address in the first IPsec tunnel?

 

- Have you found a solution? Then give your helper a "Like" and mark the solution.
- Have you found a solution? Then give your helper a "Like" and mark the solution.
eb40
New Contributor

Ipsec 1

            APN                                                             Fortinet

name:              to_114                                               to_159

Interface:        port1                                                 port1

gateway          192.168.1.159                                   192.168.1.114

subnet              192.168.11.0/24                              192.168.21.0/24

 

ipsec2  Teltonika                                                       Fortinet

name               to_forti                                               to_tel1

interface         port1                                                   to_159

gateway         192.168.21.1                                        192.168.11.2

localgateway 192.168.11.2                                        192.168.21.1

subnet            192.168.111.0/24                                 192.168.21.0/24

 

ipsec2 fortinet settings:

only after setting local gateway this tunnel started to work.

eb40_0-1673976412843.png

 

 

scan888

how is routing working on the Forti APN?
Does the client connect EC2 -> teltonika -> APN -> Net -> Fortinet -> Local
Or
EC2 -> teltonika -> APN -> IPsec -> Fortinet -> Local

 

And is my assumption correct that the IPsec from teltonika connects to Fortinet via the IPsec tunnel between APN and Fortinet?
If yes, you have to select the IPsec tunnel between APN and Fortinet as IPsec interface on Fortinet (this is only possible via CLI).

The first IPsec Tunnel (between APN and Fortinet) needs IP addresses in the tunnel.

 

- Have you found a solution? Then give your helper a "Like" and mark the solution.
- Have you found a solution? Then give your helper a "Like" and mark the solution.
eb40
New Contributor

Your assumptions are correct.

Routing from EC2 does not go thru the Net

EC2 -> teltonika -> APN -> IPsec -> Fortinet -> Local, plus ipsec from teltonika directly to Fortinet.

I am selecting interface ipsec1(to_159) as interface for to_tel1, by the way GUI allows to do it. It just selects gateway automatically which i override with local gateway setting, please check last picture in my previous post. And with all that tunnels are green/working, but I see error invalid SPI and no data flows. 

Message from the log:

sent IKE msg (R-U-THERE-ACK): 192.168.21.1:500->192.168.11.2:500

for me  looks completely normal, as that is how I expect packets to travel.

 

Unfortunately I start to think that this will not work in the end, and looks like I will stay with old connection model.

 

Regards.

Labels
Top Kudoed Authors