ICMP exceeded routing problem

[nicovpp]

IF this 1st post is not clear, please go to network diagram below Hello, I would like to understand a strange behaviour that occured on fortigate (version 4.0 & 4.0 MR2) : In my infrastructure I do have a router which is routing in static mode a public subnet (let' s call it SUB1) to my fortigate. On this fortigate I have configure several VIP. My DG is the router. For normal trafic (http ftp request...) if the requested IP is in SUB1 but not configured as a VIP, the firewall doesn' t answer the request and drop the packet. What gives me problem is the behaviour that I have found for ICMP code 11 TTL exceeded. Indeed if someone " steal" an unused IP address of SUB1 as its source IP to reach IPX and that the TTL of the packet expires in transit, an answer is sent back to my fortigate. When receiving an ICMP ttl exceeded packet for a destination to SUB1 (not used as a VIP), the fortigate doesn' t drop the packet, but send it back to my router (using it' s default gateway), and then the router resend it back to the firewall and so on. Does someone know if there is a way to avoid this behaviour (and simply drop the packet) Thanks

[nicovpp]

Hello !

So the returning TTL expired messages ( icmp type11 ) is coming to your FGT, and it' s doing it' s job by dropping this traffic

That is what I would expect, but no, the fortigate doesn' t drop this particular type of trafic nut returns it to its default gateway (the router). For all other type of trafic I' ve tested (tcp / udp / icmp other types), the fortigate indeed drop trafic.

1> ( the most easiest ), is to enable unicast verification aka RPF checks

Enabling unicast verification at the router would not solve this problem, as the incoming packet is coming from IP 15.15.15.15 to IP 92.92.92.90 and is (and will always be) a right formed packet at the router level. With ACL on my router I can drop icmp type11 packets but this would mean that traceroute would not work any longer. If the fortigate isn' t able to drop these packets I should maybe think of it

[ede_pfau]

@nicovpp: I would file a support case with Fortinet to make them aware of this. IMHO it' s a bug, and if Fortinet thinks it' s not it would be interesting to hear why not. @emnoc: I still think that the border router at the remote ISP should implement RPF. I estimate that a huge portion of these routers are Cisco models, and you showed how easy it is to implement RPF. Of course it' s not mandatory to filter but it' s a best practise to quench fake source address exploits. And as this special kind of traffic generates senseless round-trip traffic on the customer' s side it would be reasonable to implement RPF.

[nicovpp]

Done :) I have opened a ticket at support and will keep you informed about the resolution Thanks for your answers

[emnoc]

Enabling unicast verification at the router would not solve this problem, as the incoming packet is coming from IP 15.15.15.15 to IP 92.92.92.90 and is (and will always be) a right formed packet at the router level. With ACL on my router I can drop icmp type11 packets but this would mean that traceroute would not work any longer. If the fortigate isn' t able to drop these packets I should maybe think of it

So if that' s the case, than what is your concern? The firewall is doing it' s job and will maintain state. You should not need to enable icmp diagnostic packets imho.

I still think that the border router at the remote ISP should implement RPF. I estimate that a huge portion of these routers are Cisco models, and you showed how easy it is to implement RPF. Of course it' s not mandatory to filter but it' s a best practise to quench fake source address exploits. And as this special kind of traffic generates senseless round-trip traffic on the customer' s side it would be reasonable to implement RPF.

best practices and what really happens, is a far stretch at best. If all CE devices supported rpf checks and implemented them, then the internet would be way much safer and intentional or un-intentional leakage would not happen. But that is not going to happen in today' s internet and nor would I expect the ISP to enable RPF checks for validation of source address [:' (]