ICMP Redirect on Resolvers
Hello everybody, I have two DNS Server (resolver) running on FreeBSD 9.0, I always see in console messages like this: icmp redirect from 192.168.140.36: 192.168.179.80 => 192.168.140.254 and lots of messages like this, mostly ip addresses not belong to me, and some times these resolvers stop working. My question is what are these messages? why they only shown in console of these servers not others? And are they cause the problems like stopping working for server/services? Thanks -- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90
On 6 Apr 2013, at 06:36, Shahab Vahabzadeh <sh.vahabzadeh@gmail.com> wrote:
I have two DNS Server (resolver) running on FreeBSD 9.0, I always see in console messages like this:
icmp redirect from 192.168.140.36: 192.168.179.80 => 192.168.140.254
You probably configured the wrong default router address or netmask. Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/
icmp redirect from 192.168.140.36: 192.168.179.80 => 192.168.140.254
The host attempted to send a packet to 192.168.179.80 via 192.168.140.36. 192.168.140.36 forwarded the packet to 192.168.140.254 according to its routing table, but is advising you (and the kernel has added to the routing table) that in the future you reach 192.148.179.80 via 192.168.140.254, not via 192.168.140.36. --- () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
-----Original Message----- From: Shahab Vahabzadeh [mailto:sh.vahabzadeh@gmail.com] Sent: Friday, 05 April, 2013 23:36 To: nanog@nanog.org Subject: ICMP Redirect on Resolvers
Hello everybody, I have two DNS Server (resolver) running on FreeBSD 9.0, I always see in console messages like this:
icmp redirect from 192.168.140.36: 192.168.179.80 => 192.168.140.254
and lots of messages like this, mostly ip addresses not belong to me, and some times these resolvers stop working. My question is what are these messages? why they only shown in console of these servers not others? And are they cause the problems like stopping working for server/services? Thanks
-- Regards, Shahab Vahabzadeh, Network Engineer and System Administrator
Cell Phone: +1 (415) 871 0742 PGP Key Fingerprint = 8E34 B335 D702 0CA7 5A81 C2EE 76A2 46C2 5367 BF90
On 4/6/13, Keith Medcalf <kmedcalf@dessus.com> wrote:
Although spoofed ICMP redirects mightalso be abused to intercept/quietly sniff traffic on a switched LAN; The default gateway responding with a redirect in that situation is the normal case where you expect to receive an ICMP redirect. ; in that particular case ICMP redirect improves matters, by directing clients to send their packets directly to that other router on that LAN, thus eliminating one router hop for future packets to that destination IP address (until the destination IP address' redirect entry gets aged out in the sending host's route cache), which is the whole point of ICMP redirects. However... routes are better than redirects. An ICMP redirect applies to only one IP address that is redirected, so if you made heavy use of that functionality (eg Large LANs, with this) -- many table entries could be spent on the redirects; an actual route on the host is much better than relying on ICMP redirects for providing more deterministic behavior while still avoiding suboptimal routing, because only a small number of table entries are required on the hosts (entry per network). It's not an ideal situation, to have a large number of hosts reached through an ICMP redirect; in the ideal situation, you design networks so that you don't route traffic across a LAN network to a next hop IP address that also contains end hosts, instead, give routers dedicated 'links' or 'LANs', where the other endpoints are routers only (and route to next hops on those networks, instead of end-host LANs), or else: at least populate the routing tables of end hosts on any LAN you route through (using static routes, or a routing protocol on the servers), so that you aren't carrying around ICMP redirects. Failing all that, if the LANs are large, and a large number of ICMP redirects would occur, it may be preferrable to turn ICMP redirects off for those LANs on their routers
icmp redirect from 192.168.140.36: 192.168.179.80 => 192.168.140.254
The host attempted to send a packet to 192.168.179.80 via 192.168.140.36. 192.168.140.36 forwarded the packet to 192.168.140.254 according to its routing table, but is advising you (and the kernel has added to the routing table) that in the future you reach 192.148.179.80 via 192.168.140.254, not via 192.168.140.36.
-- -JH
On Apr 6, 2013 3:13 AM, "Jimmy Hess" <mysidia@gmail.com> wrote:
Failing all that, if the LANs are large, and a large number of ICMP redirects would occur, it may be preferrable to turn ICMP redirects off for those LANs on their routers
What would break if u dropped all ICMP packets with redirects on public facing boxes?
On Sat, 06 Apr 2013 10:38:06 -0400, shawn wilson said:
What would break if u dropped all ICMP packets with redirects on public facing boxes?
Presumably nothing, as long as you guaranteed that your IP address, netmask, and routes actually match the reality of your network configuration. In that case, you shouldn't see any valid ICMP redirects. They're there mostly so things kind-of-sort-of work even if you botch it (so for instance, even if you whiff your default route accidentally, you can still ssh in from Tokyo and fix it).
On 4/6/13, Valdis.Kletnieks@vt.edu <Valdis.Kletnieks@vt.edu> wrote:
On Sat, 06 Apr 2013 10:38:06 -0400, shawn wilson said:
case, you shouldn't see any valid ICMP redirects. They're there mostly so
things kind-of-sort-of work even if you botch it (so for instance, even if you whiff your default route accidentally, you can still ssh in from Tokyo and fix > it).
For ICMP redirects to do anything useful, a valid route has to actually be there already, on the default gateway.... Perhaps you are thinking of proxy arp? :) -- -JH
On Apr 6, 2013, at 16:03 , Valdis.Kletnieks@vt.edu wrote:
On Sat, 06 Apr 2013 10:38:06 -0400, shawn wilson said:
What would break if u dropped all ICMP packets with redirects on public facing boxes?
Presumably nothing, as long as you guaranteed that your IP address, netmask, and routes actually match the reality of your network configuration. In that case, you shouldn't see any valid ICMP redirects. They're there mostly so things kind-of-sort-of work even if you botch it (so for instance, even if you whiff your default route accidentally, you can still ssh in from Tokyo and fix it).
Not entirely true. They also cover the case where there are two (or more) routers on the network and you don't want to have to configure more specific routes on all your workstations. For example, network B has routers [A] and [C]. Router [A] leads to the internet. Router [C] leads to networks R, S, T, and U. Hosts on network B can be configured with default->[A] and as long as [A] and [C] have proper routing information via IGP, BGP, and/or static routing including all of the more specifics, then [A] can send back redirects to hosts on network B when they try to reach networks {R,S,T,U}. If you block ICMP redirects, then you won't break anything, but you will increase the traffic load on network B and router [A] as it will hairpin all of the traffic from those hosts to {R,S,T,U}. Owen
On Sun, 07 Apr 2013 12:25:30 -0700, Owen DeLong said:
Presumably nothing, as long as you guaranteed that your IP address, netmask, and routes actually match the reality of your network configuration.
They also cover the case where there are two (or more) routers on the network and you don't want to have to configure more specific routes on all your workstations.
As I said - if your config (including routes) matches your network reality. Note that the rest of your comment addresses the case where your initial config doesn't match reality...
On Apr 7, 2013, at 18:47 , Valdis.Kletnieks@vt.edu wrote:
On Sun, 07 Apr 2013 12:25:30 -0700, Owen DeLong said:
Presumably nothing, as long as you guaranteed that your IP address, netmask, and routes actually match the reality of your network configuration.
They also cover the case where there are two (or more) routers on the network and you don't want to have to configure more specific routes on all your workstations.
As I said - if your config (including routes) matches your network reality. Note that the rest of your comment addresses the case where your initial config doesn't match reality...
Not true. Reality is that the default router configured on the hosts is capable of getting the packets delivered. It's not optimal, but it is reality. Owen
participants (7)
-
Jimmy Hess -
Keith Medcalf -
Owen DeLong -
Shahab Vahabzadeh -
shawn wilson -
Tony Finch -
Valdis.Kletnieks＠vt.edu