|
During the architecture phase, some users/administrators run a dynamic routing protocol in a FortiGate/FortiOS environment to implement an IPSec tunnel solution over an existing IPSec setup. Unfortunately, this will not work as FortiOS does not support this type of implementation/setup.
The old and the new tunnel come 'UP', suggesting that it is working as intended, but other issues arise.
The following two issues occur:
- To run a dynamic routing protocol over this new IPSec tunnel, an IP address assigned to the new tunnel interface is required (UNDER2 in this case). However, this is not possible: the error message shown below will keep appearing when attempting to assign an IP address to the tunnel. This is because FortiOS has a check in place to prevent this type of Operation (UNDER1 checking failed because UNDER1, which is the host or the binding interface of UNDER2, is another IPsec tunnel).
- To use the tunnel without assigning an IP address to it or running a dynamic routing protocol over it, simply configure a static route over the tunnel. It will be possible to configure the static route, and it will be installed in the routing table. However, the tunnel will not be able to route traffic back and forth. Transmitting (encryption) will work as expected, but the receiving side (for decryption) will not.
This means that the site will send out traffic over this new tunnel (UNDER2 in this case) but will not be able to receive traffic, leading to one-way communication, which is not usable/useful. The encryption operation proceeds without issues, but the decrypting part does not function because the second layer of ESP will not be decryptable.
Debug flow:
2024-12-22 11:57:03 id=65308 trace_id=363 func=nipsec_set_ipsec_sa_enc line=933 msg="Trying to offload IPsec encrypt SA (p1/p2/spi={004-
IPSEC-018/004-IPSEC-018/0x72a21ed3}), npudev=1, skb-dev=BGP004-024"
2024-12-22 11:57:03 id=65308 trace_id=363 func=nipsec_set_ipsec_sa_enc line=967 msg="IPsec encrypt SA (p1/p2/spi={004-IPSEC-018/004-IPSE
C-018/0x72a21ed3}) offloadingfailed, err=14, flag/id={0/0, 0/0, 0/0}"
The debug flow shows repeated failures in offloading IPsec SA encryption (offloadingfailed, err=14) in an IPsec-over-IPsec setup, causing encryption failures and one-way communication issues.
In cases where a dynamic Dial-up IPsec tunnel is terminated in one of the FortiGate interfaces, and the tunnel traffic is passing through an existing IPsec tunnel terminated on the same FortiGate, this will cause an 'unknown SPI' error messages in the IKE debug.
The tunnel phase1 and phase2 may come up, however the 'unknown SPI' error will appear as soon as there is traffic passing through the dynamic Dial-up IPsec tunnel.
IKE Debug:
Before initiating the traffic:
FG400F # diag vpn tun list name dialuptunnel_0
list ipsec tunnel by names in vd 0
------------------------------------------------------
name=dialuptunnel_0 ver=2 serial=79 172.16.50.1:4500->10.10.10.1:63288 nexthop= tun_id=192.168.2.20 tun_id3=::10.0.0.24 dst_mtu=0 dpd-link=on weight=1
bound_if=0 real_if=7 lgwy=static/1 tun=intf mode=dial_inst/3 encap=none/73896 options[120a8]=npu rgwy-chg run_state=0 role=primary accept_traffic=1 overlay_id=0
parent=dlp index=0
proxyid_num=1 child_num=0 refcnt=5 ilast=17 olast=17 ad=/0
stat: rxp=22 txp=3 rxb=2568 txb=180
dpd: mode=on-demand on=1 idle=60000ms retry=3 count=0 seqno=0
natt: mode=none draft=0 interval=0 remote_port=0
fec: egress=0 ingress=0
proxyid=dialup proto=0 sa=1 ref=2 serial=1 add-route
src: 0:0.0.0.0-255.255.255.255:0
dst: 0:192.168.2.20-192.168.2.20:0
SA: ref=3 options=6a7 type=00 soft=0 mtu=1280 expire=7148/0B replaywin=1024
seqno=1 esn=0 replaywin_lastseq=00000000 qat=0 rekey=0 hash_search_len=1
life: type=01 bytes=0/0 timeout=7189/7200
dec: spi=a44cz2df esp=aes-gcm key=36 5aa0c5a2bbe2400a7b405b3c7e53330ee1b6dc8e69086d9575092a2cf572b8f61d6b64af
ah=null key=0
enc: spi=hf335624 esp=aes-gcm key=36 6aa174ee85e7580951771ae8ade779246a5b7515222037de2d10c2659f1350faeea3c15c
ah=null key=0
dec:pkts/bytes=0/0, enc:pkts/bytes=0/0
npu_flag=00 npu_rgwy=10.10.10.1 npu_lgwy=172.16.50.1 npu_selid=13e dec_npuid=0 enc_npuid=0
After initiating the traffic:
FG400F #
ike 0: unknown SPI a44cz2df 43 10.10.10.1:63288->172.16.50.1
ike 0: found dialuptunnel_0 172.16.50.1 0 -> 10.10.10.1:63288
ike 0:dialuptunnel_0:5936: send IPsec SA delete, SPI a44cz2df
ike 0:dialuptunnel_0:5936:110789: send informational
ike 0:dialuptunnel_0:5936: sent IKE msg (INFORMATIONAL): 172.16.50.1:4500->10.10.10.1:63288, len=77, vrf=0, id=3fac55a44dd4hgtsa/14feagtytt11460ef
ike 0: comes 10.10.10.1:63288->172.16.50.1:4500,ifindex=43,vrf=0....
ike 0: IKEv2 exchange=INFORMATIONAL_RESPONSE id=3fac55a44dd4hgtsa/14feagtytt11460ef len=77
ike 0:dialuptunnel_0:5936: received informational response
ike 0:dialuptunnel_0:5936:110789: processing informational acknowledgement
ike 0:dialuptunnel_0:5936: processing delete ack (proto 3)
ike 0:dialuptunnel_0: deleting IPsec SA with SPI hf335624
|
