07-02-2019 04:38 AM
I have an issue with a VPN between an ASA 5515 (9.1(7)29) and a Fortigate 501E (5.6.8). We have the Cisco ASA and the customer has the Fortigate.
Both are configured to have an L2L VPN between them. The VPN is up and we see traffic being encrypted and decrypted.
The problem is, sometimes, some of the hosts from the networks that are on the customer side become unreachable. These networks are networks that belong to the ACL crypto map. Networks that are identified to have traffic to be encrypted.
But, this unreachability it not forever because after a while we start to have connectivity to those hosts. And others start to have connectivity problems.
For example, when we try to have traffic between the host 158.98.170.176 and the host 192.168.110.2 and the problem described happens, we have logs like the following:
Jul 1 19:59:05 120.30.187.59/120.30.187.59 Jul 01 2019 22:59:05 ipm-asa-inf-02 :
%ASA-4-402116: IPSEC: Received an ESP packet (SPI= 0x675040D1, sequence number= 0x3B) from 204.140.30.192
(user= 204.140.30.192) to 210.146.190.51. The decapsulated inner packet doesn't match the negotiated policy in the SA.
The packet specifies its destination as 158.98.170.176, its source as 192.168.110.2, and its protocol as TCP.
The SA specifies its local proxy as 158.98.170.176/255.255.255.255/tcp/0 and its remote_proxy as 172.19.0.0/255.255.0.0/tcp/0
The host 192.168.110.2 belongs to one of the networks that can be encrypted.
The network 172.19.0.0/16 it is one of the networks that can be encrypted.
Has someone seen a similar problem between Cisco ASA and Fortigates?
Can anybody help me with this issue?
Thanks.
Solved! Go to Solution.
07-02-2019 05:22 AM
I have seen similar issues when the non-Cisco side is set up for route based VPN instead of policy based. What happens is that the remote side all traffic through just 1 security association (SA). The ASA has checks in place to make sure that the actual data packet matches the SA source an destination IP.
In your case, it looks like the Fortigate is sending the packet from src 192.168.110.2 across the wrong SA from time to time. The ASA drops it as expected. This should be something that the Fortigate side fixes. The first check that they have to do is that they have the same proxy-id's as what the ASA has and it is not set to send everything via 1 SA. The fortigate KB to fix this is explained here:
09-16-2019 04:19 PM
Problem solved. Thanks.
07-02-2019 05:22 AM
I have seen similar issues when the non-Cisco side is set up for route based VPN instead of policy based. What happens is that the remote side all traffic through just 1 security association (SA). The ASA has checks in place to make sure that the actual data packet matches the SA source an destination IP.
In your case, it looks like the Fortigate is sending the packet from src 192.168.110.2 across the wrong SA from time to time. The ASA drops it as expected. This should be something that the Fortigate side fixes. The first check that they have to do is that they have the same proxy-id's as what the ASA has and it is not set to send everything via 1 SA. The fortigate KB to fix this is explained here:
09-16-2019 04:19 PM
Problem solved. Thanks.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide