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?

[ede_pfau]

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?

[ede_pfau]

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?

[emnoc]

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 )

[Phil_Lofthouse]

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.

[emnoc]

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 ;)

[rwpatterson]

How you configure the FGT side is independent of the remote end. With proper planning, you could tear down and reconfigure a tunnel from policy based to interface based in minutes...via the CLI, that is.

[ede_pfau]

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.

[emnoc]

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

[ede_pfau]

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?