|
After replacing the certificate on both devices, the IPsec tunnel between FortiGate and Cisco might not work as expected.
The behavior seen is the tunnel being up in GUI, as seen on the FortiGate side, but there is no traffic going through.
If trying to generate any type of traffic, the tunnel goes down and then up again.
To check if the tunnel is up via CLI, the following command can be used:
diagnose vpn tunnel list
The output of the debug will look like this:
ike V=root:0:vpn-p1:9694: responder received AUTH msg
ike V=root:0:vpn-p1:9694: processing notify type INITIAL_CONTACT
ike V=root:0:vpn-p1:9694: processing notify type SET_WINDOW_SIZE
ike V=root:0:vpn-p1:9694: processing notify type ESP_TFC_PADDING_NOT_SUPPORTED
ike V=root:0:vpn-p1:9694: processing notify type NON_FIRST_FRAGMENTS_ALSO
ike V=root:0:vpn-p1:9694: peer identifier IPV4_ADDR 10.245.112.101
ike V=root:0:vpn-p1:9694: received peer certreq 'CERTIFICATE_USED'
ike V=root:0:vpn-p1:9694: Validating X.509 certificate
ike V=root:0:vpn-p1:9694: peer cert, subject='', issuer='Certificate_Issuer'
ike V=root:0:vpn-p1:9694: building fnbam peer candidate list
ike V=root:0:vpn-p1:9694: FNBAM_GROUP_NAME candidate 'test_user'
ike V=root:0:vpn-p1:9694: certificate validation pending
ike V=root:0:vpn-p1: link is idle 33 192.168.15.43:4500->80.75.32.24:4500 dpd=2 seqno=1973 rr=0
ike V=root:0: comes 80.75.32.24:4500->192.168.15.43:4500,ifindex=33,vrf=0,len=1204....
ike V=root:0: IKEv2 exchange=AUTH id=5e6f78c2c158b47c/08adcd1492ebb5a3:00000001 len=1200
-----------------------------------------------------------
ike V=root:0:vpn-p1:9694: detected retransmit
ike 0:vpn-p1:9693: out CEXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ike V=root:0:vpn-p1:9693: sent IKE msg (RETRANSMIT_INFORMATIONAL): 192.168.15.43:4500->80.75.32.24:4500, len=80, vrf=0, id=c39ea13e5dfb4caa/8ad258aa0da66fe9, oif=33
ike V=root:0:vpn-p1:9694: certificate validation succeeded
ike V=root:0:vpn-p1:9694: signature verification succeeded
ike V=root:0:vpn-p1:9694: auth verify done
ike V=root:0:vpn-p1:9694: responder AUTH continuation
ike V=root:0:vpn-p1:9694: authentication succeeded
ike V=root:0:vpn-p1:9694: responder creating new child
ike V=root:0:vpn-p1:9694:14018: peer proposal:
ike V=root:0:vpn-p1:9694:14018: TSi_0 0:10.254.50.0-10.254.50.255:0
ike V=root:0:vpn-p1:9694:14018: TSr_0 0:0.0.0.0-255.255.255.255:0
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: comparing selectors
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: matched by rfc-rule-2
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: phase2 matched by subset
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: accepted proposal:
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: TSi_0 0:10.254.50.0-10.254.50.255:0
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: TSr_0 0:0.0.0.0-255.255.255.255:0
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: autokey
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: incoming child SA proposal:
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: proposal id = 1:
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: protocol = ESP:
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: encapsulation = TUNNEL
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: type=ENCR, val=AES_GCM_16 (key_len = 128)
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: type=ESN, val=NO
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: PFS is disabled
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: matched proposal id 1
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: proposal id = 1:
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: protocol = ESP:
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: encapsulation = TUNNEL
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: type=ENCR, val=AES_GCM_16 (key_len = 128)
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: type=INTEGR, val=AUTH_NONE
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: type=ESN, val=NO
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: PFS is disabled
ike V=root:0:vpn-p1:9694:vpn-p2x:14018: lifetime=3600
ike V=root:0:vpn-p1:9694: responder preparing AUTH msg
ike V=root:0:vpn-p1:9694: remote port change 500 -> 4500
ike V=root:0:vpn-p1:9694: established IKE SA 5e6f98c1c158c47b/08adcd1392ebd5a3
ike V=root:0:vpn-p1:9694: check peer route: if_addr4_rcvd=0, if_addr6_rcvd=0, mode_cfg=0
ike V=root:0:vpn-p1: HA send IKE connection add 192.168.15.43->80.75.32.24
ike V=root:0:vpn-p1:9694: HA send IKE SA add 5e6f98c1c158c47b/08adcd1392ebd5a3
ike V=root:0:vpn-p1:9694: processing INITIAL-CONTACT
ike V=root:0:vpn-p1: flushing
ike V=root:0:vpn-p1: deleting IPsec SA with SPI e6f49425
ike V=root:0:vpn-p1:vpn-p2x: deleted IPsec SA with SPI e6f49425, SA count: 0
ike V=root:0:vpn-p1: sending SNMP tunnel DOWN trap for vpn-p2x
ike V=root:0:vpn-p1: static tunnel down event 0.0.0.0 (dev=44)
ike V=root:0:vpn-p1: static tunnel down event :: (dev=44)
ike V=root:0:vpn-p1:9693:vpn-p2x:14016: sending delete for IPsec SA SPI 8b30dcf8
ike V=root:0:vpn-p1:9693::14019: wait for pending request :14017
ike V=root:0:vpn-p1: deleting IPsec SA with SPI e6f49425
ike V=root:0:vpn-p1: IPsec SA with SPI e6f49425 deletion failed: 2
ike V=root:0:vpn-p1:9693: HA send IKE SA del c39ea13e5dfb4caa/8ad258aa0da66fe9
ike V=root:0:vpn-p1: deleting IPsec SA with SPI e6f49425
ike V=root:0:vpn-p1: IPsec SA with SPI e6f49425 deletion failed: 2
ike V=root:0:vpn-p1:9693:14020: send informational
ike 0:vpn-p1:9693: enc 00000008010000000706050403020107
ike 0:vpn-p1:9693: out CEXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
ike V=root:0:vpn-p1:9693: sent IKE msg (INFORMATIONAL): 192.168.15.43:4500->80.75.32.24:4500, len=80, vrf=0, id=c39ea13e5dfb4caa/8ad258aa0da66fe9, oif=33
ike V=root:0:vpn-p1: flushed
These logs can be collected using the following commands while replicating the issue (generate traffic on the tunnel):
diagnose vpn ike log-filter dst-addr4 <Remote_Peer_IP>
diagnose debug application ike -1
diagnose debug console timestamp enable
diagnose debug enable
To disable it:
diagnose debug disable
This issue might be caused by the mismatch of encryption methods between these two devices.
What can be done in this case, is to generate a new CSR in FortiGate using the CLI and test the connection again.
|
