cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3941
Views
0
Helpful
2
Replies

VPN between ASA and Fortigate

rcapao
Level 1
Level 1

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.

2 Accepted Solutions

Accepted Solutions

Rahul Govindan
VIP Alumni
VIP Alumni

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:

 

https://kb.fortinet.com/kb/documentLink.do?externalID=10440

View solution in original post

Problem solved. Thanks.

View solution in original post

2 Replies 2

Rahul Govindan
VIP Alumni
VIP Alumni

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:

 

https://kb.fortinet.com/kb/documentLink.do?externalID=10440

Problem solved. Thanks.

Review Cisco Networking for a $25 gift card