Cisco ASA logs report ESP errors

[Phil_Lofthouse]

I have a policy-based VPN between a Fortigate-300A and a Cisco ASA. All config relating to the VPN matches at both ends and the VPN works with no apparent issues apart from the following: When a host behind the Cisco end of the VPN attempts TCP communication with an unused IP address at the Fortigate end of the VPN, the Fortigate responds by sending an ICMP destination unreachable packet down the VPN back to the source of the TCP communication. Unfortunately the Fortigate uses the local gateway (main interface) IP address as the source address of the packet, rather than it' s LAN IP address (which is in the same range as the unused IP address). The consequence is that the source IP address of the packet falls outside the negotiated parameters of the SA and therefore is reported as an error by the Cisco. The Fortigate is running FortiOS 4 MR3 Patch 15. I have other Fortigate firewall with the same connectivity running different versions of firmware and displaying the same behavior. I have already been able get around the issue but I was wondering if anyone had advise on changing the behavior of the Fortigate?

[Phil_Lofthouse]

Thank you all again for your advise. Ede: I think I' ll raise a support case with Fortinet as soon as possible. Emnoc/Bob: I' ll start planning out migrating from a policy based to a route based VPN via the Cli. To be honest it hadn' t ' clicked' that the type of VPN on the Fortigate was independant of the peer, as you suggest. Emnoc: If I understand your last post correctly 1.1.1.1 is the peer IP of the remote end of the VPN, 192.168.254.119 and .113 are addresses in a subnet directly connected to the ' internal' side of the remote end of the VPN and the Cisco is, I assume, reporting ESP errors because the ICMP host unreachable packet is coming from an IP outside of the encryption access list? This suggests that the policy based and route based VPNs display the same behaviour, which may be a bug as Ede suggests?

[emnoc]

Phil Yes you have it correct. 1.1.1.1 peer-address 10.200.6.0/24 CISCO-LAN 192.168.254.0/24 FGT-LAN Ede, yes the unreachable is coming from the VPN-peer endpoint 1.1.1.1 in my case, but it' s carried within the tunnel known as VPNtun. I dumped on the cisco ASA tunnel side and see that it' s being dropped as what i suspected. I believe on my pb-vpn, the unreachable comes outside of the tunnel and via the egresss interface ip_addresss oh forgot to show you the errors on the ASA; #PMTUs sent: 0, #PMTUs rcvd: 0, #decapsulated frgs needing reassembly: 0 #TFC rcvd: 0, #TFC sent: 0 #Valid ICMP Errors rcvd: 0, #Invalid ICMP Errors rcvd: 0 #send errors: 0, #recv errors: 647 This is not a bug but how icmp unreachable works. The src of this icmp.type icmp.messages is NOT the lan that your trying to connect on, it' s the egresss interface of the device sending the code