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

[ede_pfau]

Hi, seems to me that the routing is not correct. First of all, there should be a static route on the FGT for SUB1, with the router as the gateway. I don' t know what you do with VIPs (translate SUB1 address into what?) but it should not influence the FGT to drop or not to drop packets to SUB1. The FGT will drop traffic it doesn' t have a route to. For routing, a default route is enough; for firewalling, the destination subnet must be known to the FGT. In your description what happens if a host using an ' unused' SUB1 source IP address makes traffic that reaches no destination, I don' t understand why the FGT would send a ' dest. unreachable' message via it' s default route to the router. Why the FGT, and why to the router? Maybe you can shed some light on this.

[emnoc]

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.

That should be normal. Do you have a network-diagram of what you have? The SUb1 and IPX and all of the other lingo is throwing a cloud of confusion ( at least for me ) of what you have. Include the subnet/mask and gateway with real of fake ip_address. Then we could see a better view of what your saying. If you have VIPs and the appropiate Default Gateway (the router ), then your design should work. An traffic that' s not terminate at the VIP, or originates from the firewall, should be simply discard/ignored. Your network is typical a simple design form what we can tell and shouldn' t be all of that complex.

[nicovpp]

Hello ! Thaks for your answers, but tou are right I wasn' t clear enough. I have made 2 network diagram. One for normal trafic process, and another one concerning the problem of routing for ICMP code 11 ttl exceeded packets. I hope it will be more clear

[nicovpp]

And the diagram for ICMP code 11

[ede_pfau]

This is much clearer now. I' ve re-read RFC3704 to check which device is not behaving correctly ( http://www.ietf.org/rfc/rfc3704.txt ). 1) The router at 10.10.11.1 is not configured correctly. It should drop packets if their source address is known to be coming from an interface which is not the current source interface. For example: the router has static route for the 92.92.92.0 network with a gateway on its internal interface (namely the FGT at 10.10.11.2). Seeing traffic coming in on a different interface but with source addresses from 92.92.92.0 should be dropped silently. 2) The FGT cannot use Strict Reverse Path Forwarding (RPF) as it doesn' t have a route to the 92.92.92.0 subnet. So it cannot determine that this traffic is coming in on the wrong interface and drop it. But the default route back to the router allows it to process the traffic and send an ICMP reply. If the FGT had a route to this subnet pointing to the internal interface then RPF would work and it would drop the traffic. I would check the following, to make sure RPF is enabled: a) RPF might be disabled, on purpose or unadvertedly. Most commonly this is the case if secondary IP addresses are used on interfaces, or asymmetric routing is allowed: conf system settings set allow-subnet-overlap enable set asymroute enable b) the VIP definition(s) comprises a subnet (containing the attacking IP 92.92.92.90) instead of a single IP address (92.92.92.1/32. Then the FGT might exclude that range from RPF - but this is speculative. There is a setting that enforces strict RPF which is disabled by default. The description is incomplete at best, vague or misleading:

 conf sys settings
    set strict-src-check enable
 
 Enable to refuse packets from a source IP range if there is a
 specific route in the routing table for this network (RFC
 3704).

The meaning hopefully is " ...if there is a route AND traffic is coming in not on the source subnet' s interface" . Then RPF makes sense. You can enable this setting and try it out but with caution. Fortinet might have had other intentions in mind with it, and it might block legitimate traffic. I' m curious what you might find out, and whether your configuration is preventing RPF. But really, the FGT cannot be blamed IMO: just using VIPs is not giving RPF enough information. Rather, the next hop router should be re-configured.

[nicovpp]

Thanks for your post. I have read it in details. Concerning your POINT 1 I just want to add a precision in the NOK diagram : The incomming packet on my router has been generated by the router 15.15.15.15 where ttl has expired. The content of the packet is similar to : IP source : 15.15.15.15 IP dest : 92.92.92.90 Contain : ICMP TTL exceeded, original packet was 92.92.92.90 trying to access 100.100.100.100 http://en.wikipedia.org/wiki/ICMP_Time_Exceeded So the trafic arrives to my router like a regular trafic (a router doesn' t maintain a connection table) and the router is (to my mind) configured correctly. Concerning your POINT 2 What is strange is that if I try to make a connection to the unused IP 92.92.92.90 ont port 80, the firewall just drop the packet and doesn' t forward it to its DG. This problem I describe is only appearing for this specific type of trafic (ICMP code 11 with a " steal" source IP taken in my subnet). I was believing, as emnoc said, that the fortigate would simply drop all type of trafic The problem is that my infrastructure is really more complex, and it is not really possible (it would bring many other routing problems and is not maintainable) to make on the FGT a static route poiting to a non existing IP (or assign a public IP of the subnet on an interface, or try a global VIP). I have check RPF status currently in place on my firewall : config system settings set asymroute disable set allow-subnet-overlap disable set strict-src-check disable

[ede_pfau]

True. The attacker' s access router (at his ISP) should have discarded the traffic with the fake source IP.

[nicovpp]

You' re right but which ISP (for public access) check the source IP ? My personnal doesn' t and is not the only one. I have added more informations to my previous post about POINT 2. If you have any other ideas, they are welcome !

[emnoc]

I have to disagree with the following two statements

True. The attacker' s access router (at his ISP) should have discarded the traffic with the fake source IP.

and

1) The router at 10.10.11.1 is not configured correctly. It should drop packets if their source address is known to be coming from an interface which is not the current source interface.

Routers, unless configured for RPF checks, don' t care about the SRC_address. All route decision are based from a DST_Address. f.g I could go to my home and generate traffic w/ a src of 92.92.92.0/24 network and my router or ISP router wouldn' t care ( and yes my ISP don' t have RPF checks enable or unicast-verification enabled ) What' s probably happening; someone , some where, has hijack the OP address or has something misconfigured. So the returning TTL expired messages ( icmp type11 ) is coming to your FGT, and it' s doing it' s job by dropping this traffic This is not nothing to be alarmed about ( imho ), cause the FW is aware and knows it didn' t allow that traffic outbound or doesn' t have the resulting session state. If it' s a big concern you have 2 choices to squash this to some degree, both are easy to do on a cisco router btw; 1> ( the most easiest ), is to enable unicast verification aka RPF checks ! ! int gi 0/1 ip verify unicast source ! ! end 2> option #2; if unicast verifiy is not a support feature, is to apply a ACL on the internet facing interface to drop these packets and at the same time, drop any " martians" . e.g ! ! ip access-list ext blackholes ! remark define any src that matches my networks deny ip 92.92.92.0 0.0.0.255 any remark define any thing that starts with 0.0.0.0 as a source cause we know this can' t be good ;) deny ip 0.0.0.0 0.255.255.255 any ! remark define any 127 networks that are sourced deny ip 127.0.0.0 0.255.255.255 any remark define any AIPA address deny ip 169.254.0.0 0.0.255.255 any remark drop any rfc1918 address ( no way these should be on the network but people do leak them ) deny ip 10.0.0.0 0.255.255.255 any deny ip 172.16.0.0 0.15.255.255 any deny ip 192.168.0.0 0.0.255.255 any remark whenever you are done include a permit any permit ip any any ! or even more tighter ! permit ip any 92.92.92.0 0.0.0.255 ! ! you get the picture now ? ! At the minimum I do the above networks plus the mcasts range and some of the BOGON like the; 1net , experiment network 192.0.2.0,etc.... In some cases, where I don' t have access to my upstream router, I craft a acl on the firewall that does the same. for an update BOGON list of src_address that should never apper on the wire, follow this link http://www.team-cymru.org/Services/Bogons/bogon-dd.html If your in a cisco environment a few website have downloadable ACL that you can just plug-in play or append to your own custom lists. Same for if your running linux iptables or similar dvices. Good luck