Cisco ASA logs report ESP errors

Hi, and welcome to the forums. This sounds like a real bug to me. I guess you got around it by some action on the Cisco side. To eventually have this fixed, if this behavior is reproduceable, could you imagine yourself filing a support case and thus notify the Fortinet team officially?

OK, I tried to reproduce the situation. My end is 192.168.234.0/24. Remote end is 192.168.166.0/24. Tunnel phase1 is called " VPN" . I' m pinging 192.168.166.11 which is non-existent.

 2014-05-21 15:00:03.466040 VPN in 192.168.151.1 -> 192.168.234.11: icmp: host 192.168.166.11 unreachable  2014-05-21 15:00:03.466303 internal out 192.168.151.1 -> 192.168.234.11: icmp: host 192.168.166.11 unreachable  2014-05-21 15:00:03.466326 eth0 out 192.168.151.1 -> 192.168.234.11: icmp: host 192.168.166.11 unreachable  2014-05-21 15:00:06.536313 VPN in 192.168.151.1 -> 192.168.234.11: icmp: host 192.168.166.11 unreachable  2014-05-21 15:00:06.536504 internal out 192.168.151.1 -> 192.168.234.11: icmp: host 192.168.166.11 unreachable  2014-05-21 15:00:06.536523 eth0 out 192.168.151.1 -> 192.168.234.11: icmp: host 192.168.166.11 unreachable  2014-05-21 15:00:09.605352 VPN in 192.168.151.1 -> 192.168.234.11: icmp: host 192.168.166.11 unreachable  2014-05-21 15:00:09.605625 internal out 192.168.151.1 -> 192.168.234.11: icmp: host 192.168.166.11 unreachable  2014-05-21 15:00:09.605646 eth0 out 192.168.151.1 -> 192.168.234.11: icmp: host 192.168.166.11 unreachable  2014-05-21 15:00:12.675596 VPN in 192.168.151.1 -> 192.168.234.11: icmp: host 192.168.166.11 unreachable  2014-05-21 15:00:12.675832 internal out 192.168.151.1 -> 192.168.234.11: icmp: host 192.168.166.11 unreachable  2014-05-21 15:00:12.675852 eth0 out 192.168.151.1 -> 192.168.234.11: icmp: host 192.168.166.11 unreachable  

What I see here is that the wrong tunnel end is responding: 192.168.151.1 is the first (of 3) phase2' s and apparently used here instead of 192.168.166.1 which would be the correct gateway. Anybody else caring to reproduce this?

Suggestions; Can you disable icmp messages? ( is thei a global cfg to disable this ) Why not create the vpn a route-based and see if the correct src is sent? ( this is why I never like policy-based vpns )

Thank you both for investigating this yourselves and providing some advice. As far as I can tell from using the Cli and looking through Fortinet' s documentation, the only ICMP facility I can disable are redirects from an interface (within the interface configuration). Nothing has leaped out at me to suggest I can disable all ICMP messages. The Cisco ASA end of the VPN is not in my control so it could take a while to move to a route based VPN (which I' d prefer to use as well). I may be able to test this in a none live environment first though. I' ve managed to get around the issue by creating black hole static routes for the destination IPs in question. The Fortigate does not now respond with ICMP messages to the source IPs. I' ve also requested that the source IPs are stopped from making these communication requests as the destinations are no longer in use. Thanks again.

The Cisco ASA end of the VPN is not in my control so it could take a while to move to a route based VPN (which I' d prefer to use as well). I may be able to test this in a none live environment first though.

FWIW: A route-based vpn has nothing todo or any dependencies on the cisco ASA or the cisco side of things. I would never ever build a policy-based vpn. To be honest every sincee my involvement with netscreen, I' ve never ever built a policy-base vpn ;)

FYI: my test was with a route-based/Interface Mode VPN. This behavior does not depend on the type of VPN then. With all this policy-based VPN bashing, there are situations in which you have to resort to PB-VPN. For instance, to create a VPN when the Fortigate is in Transparent Mode. Sure this is a rare case, 99% of current VPNs out there are probably created in Interface Mode.

it has nothing to do with pb-vpn bashing. if you think about it, the pb-vpn has no interface to route the icmpcode un-reachable back to the sender as what you would expect in a route-based. fwiw: route-base vpn; 0.644066 VPNtun out 1.1.1.1 -> 10.200.6.7: icmp: host 192.168.254.119 unreachable 0.644088 VPNtun out 1.1.1.1 -> 10.200.6.7: icmp: host 192.168.254.119 unreachable 0.644109 VPNtun out 1.1.1.1 -> 10.200.6.7: icmp: host 192.168.254.119 unreachable 0.664401 VPNtun in 10.200.6.7 -> 192.168.254.119: icmp: echo request 1.672752 VPNtun in 10.200.6.7 -> 192.168.254.119: icmp: echo request 2.680879 VPNtun in 10.200.6.7 -> 192.168.254.119: icmp: echo request 3.674061 VPNtun out 1.1.1.1 -> 10.200.6.7: icmp: host 192.168.254.119 unreachable 3.674085 VPNtun out 1.1.1.1 -> 10.200.6.7: icmp: host 192.168.254.119 unreachable 3.674105 VPNtun out 1.1.1.1 -> 10.200.6.7: icmp: host 192.168.254.119 unreachable 7.643822 VPNtun in 10.200.6.7 -> 192.168.254.113: icmp: echo request 8.652970 VPNtun in 10.200.6.7 -> 192.168.254.113: icmp: echo request 9.661025 VPNtun in 10.200.6.7 -> 192.168.254.113: icmp: echo request 10.644067 VPNtun out 1.1.1.1 -> 10.200.6.7: icmp: host 192.168.254.113 unreachable 10.644087 VPNtun out 1.1.1.1 -> 10.200.6.7: icmp: host 192.168.254.113 unreachable 10.644107 VPNtun out 1.1.1.1 -> 10.200.6.7: icmp: host 192.168.254.113 unreachable 10.661794 VPNtun in 10.200.6.7 -> 192.168.254.113: icmp: echo request 11.669028 VPNtun in 10.200.6.7 -> 192.168.254.113: icmp: echo request And this is dropped on the cisco side btw, so the unreachable is never sent to the sender 10.200.6.7 in my case. The cisco vpn proxy-id would not accept these packets due to the source not matching the encryption acl And to be clear the 192.168.254.113 and .119 are non-existing hosts over the vpn on the fortigate. Within the cisco platforms, we can filter and drop unneeded sending of unreachables and/or rate-limit them

Ken, this is not quite the situation the OP is describing. Assume you have a subnet 1.1.1.0/24 behind the remote tunnel end. Remote gateway is 1.1.1.1. Host 1.1.1.100 exists but 1.1.1.200 does not. In this case, ping 1.1.1.200. The ICMP unreachable should be sent back through the tunnel with a source address of 1.1.1.1, the remote end' s gateway. What I can see is that the wrong gateway is responding. What the OP saw is that the remote end' s WAN IP is responding which is way off. Can you confirm the ICMP unreachable behavior with a setting like I described above?

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?

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