Skip to main content
nicovpp
nicovpp
New Member
October 13, 2011
Question

ICMP exceeded routing problem

  • October 13, 2011
  • 13 replies
  • 27673 views
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

    13 replies

    Show previous replies
    ede_pfau
    SuperUser
    ede_pfau
    SuperUser
    October 17, 2011
    @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
    nicovppAuthor
    New Member
    October 17, 2011
    Done :) I have opened a ticket at support and will keep you informed about the resolution Thanks for your answers
    emnoc
    emnoc
    New Member
    October 17, 2011
    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 [:' (]
    Terms & ConditionsAccessibility statement