Getting "ICMP Host redirect from gateway" response

Hello,

I am connected to a LAN which has addresses in the range
192.168.0.10-192.168.0.253.
The default gw is 192.168.0.254 and is conneted outside to the
internet:
route shows:
....
....
default 192.168.0.254 0.0.0.0 UG 0 0
0 eth0

I want to be able to ping machines and get "ICMP Host redirect from
gateway"
(for learning more about ICMP redirects).
I made some trials but could not achieve this.
Can anybody suggest a senario where as a result of a ping (it can be
of course
to a machine on the internet or a machine in the LAN) I will get
"ICMP Host redirect from gateway" response ?

Regards,
Ian

Am Tue, 29 May 2007 05:12:43 -0700 schrieb (E-Mail Removed):

> Hello,

Hi,

> I am connected to a LAN which has addresses in the range
> 192.168.0.10-192.168.0.253.
> The default gw is 192.168.0.254 and is conneted outside to the
> internet:
> I want to be able to ping machines and get "ICMP Host redirect from
> gateway"
> (for learning more about ICMP redirects).

If 192.168.0.253 has 192.168.0.254 as default gw and your host using
192.168.0.253 as default gw and you ping an external IP which is not
reachable via broadcast (e.g. 172.30.254.1) then you should recive a nice
icmp redirect by the time you ping the external IP.

> Can anybody suggest a senario where as a result of a ping (it can be
> of course
> to a machine on the internet or a machine in the LAN) I will get
> "ICMP Host redirect from gateway" response ?

Keep an eye on
/proc/sys/net/ipv4/conf/all/accept_redirects
/proc/sys/net/ipv4/conf/all/send_redirects

If you don't allow to send icmp redirect then the scenario fails of course.

On 29 May 2007, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed) .com>, (E-Mail Removed) wrote:

>I am connected to a LAN which has addresses in the range
>192.168.0.10-192.168.0.253.
>The default gw is 192.168.0.254 and is conneted outside to the
>internet:

OK

>I want to be able to ping machines and get "ICMP Host redirect from
>gateway"
>(for learning more about ICMP redirects).

0792 Internet Control Message Protocol. J. Postel. September 1981.
(Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950)
(Also STD0005) (Status: STANDARD)

1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995.
(Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated by
RFC2644) (Status: PROPOSED STANDARD)

and from RFC1812, we find

4.3.3.2 Redirect

The ICMP Redirect message is generated to inform a local host that it
should use a different next hop router for certain traffic.

Contrary to [INTRO:2], a router MAY ignore ICMP Redirects when
choosing a path for a packet originated by the router if the router
is running a routing protocol or if forwarding is enabled on the
router and on the interface over which the packet is being sent.

and

5.2.7.2 Redirect

The ICMP Redirect message is generated to inform a local host the it
should use a different next hop router for a certain class of
traffic.

Routers MUST NOT generate the Redirect for Network or Redirect for
Network and Type of Service messages (Codes 0 and 2) specified in
[INTERNET:8]. Routers MUST be able to generate the Redirect for Host
message (Code 1) and SHOULD be able to generate the Redirect for Type
of Service and Host message (Code 3) specified in [INTERNET:8].

followed by about a page of discussion/explanation.

>I made some trials but could not achieve this.

A _host_ redirect (ICMP Type 5 Code 1) would occur when you send traffic
_for_ one of the local hosts (192.168.0.10-192.168.0.253 in your example),
but send it to the default gateway (192.168.0.254) and expect it to
deliver the packet. The gateway will get unhappy, and send the redirect
trying to tell you "don't send it to me - send it directly to the host
which is on this same wire". This occurs when the person who set up the
routing tables made an error. This error is generated when the router
notices that the packet it received on interface $FOO is going to be sent
back out using the same interface. "Why are you wasting _my_ time?".

>Can anybody suggest a senario where as a result of a ping (it can be
>of course to a machine on the internet or a machine in the LAN) I will
>get "ICMP Host redirect from gateway" response ?

You would have to misconfigure the networking configuration. One way to
screw up this way is to provide _host_ routes using a gateway, such as

Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 4198 eth0
192.168.0.10 192.168.0.254 255.255.255.255 UGH 0 0 56 eth0
192.168.0.11 192.168.0.254 255.255.255.255 UGH 0 0 56 eth0
192.168.0.12 192.168.0.254 255.255.255.255 UGH 0 0 56 eth0
default 192.168.0.254 0.0.0.0 UG 0 0 10 eth0

In routing tables, when there are multiple routes to the same place, the
route with more bits in the network mask wins. Metric may also be a factor
and here I've intentionally set the metrics to zero. Note that if there
are two or more routes to the same place, with the same network mask and
the same metric, then the _last_ route specified wins.

Regarding ICMP Redirects, you should be aware that many operating systems
_ignore_ redirects - because this has been used in Denial Of Service
attacks in the past. Really, you shouldn't see them that often anyway, as
this generally occurs because of intentional configuration errors. ICMP
_Network_ Redirections (type 5 code 0) is generally the result of setting
the wrong gateway value in a routing table. An example might be

Destination Gateway Genmask Flags Metric Ref Use Iface
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 89948 eth0
192.168.2.0 192.168.1.6 255.255.255.0 UG 0 0 32165 eth0
127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 388 lo
0.0.0.0 192.168.1.248 0.0.0.0 UG 0 0 2673 eth0

If you sent packets destined for 192.168.2.x to 192.168.1.248 for
forwarding, that router would complain, and tell you to use 192.168.1.6
as the gateway for this route. For this to occur, the mis-configured
host would be lacking the second route, and assume that everything not
local goes to 192.168.1.248.

Old guy

On Tue, 29 May 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <f3hkpp$q08$01$(E-Mail Removed)>, Burkhard Ott wrote:

>schrieb (E-Mail Removed)

>> I want to be able to ping machines and get "ICMP Host redirect from
>> gateway"
>> (for learning more about ICMP redirects).
>
>If 192.168.0.253 has 192.168.0.254 as default gw and your host using
>192.168.0.253 as default gw and you ping an external IP which is not
>reachable via broadcast (e.g. 172.30.254.1) then you should recive a
>nice icmp redirect by the time you ping the external IP.

I suspect you'll get a ICMP Type 3 Code 0 "Network unreachable" rather
than a redirect. Where would you be redirected to? A "redirect" occurs
when the router knows of a "better" route. See section 4.3.3.2
of RFC1812, which begins

4.3.3.2 Redirect

The ICMP Redirect message is generated to inform a local host that it
should use a different next hop router for certain traffic.

and compare that to section 4.3.3.1, the first part of which says

4.3.3.1 Destination Unreachable

If a router cannot forward a packet because it has no routes at all
(including no default route) to the destination specified in the
packet, then the router MUST generate a Destination Unreachable, Code
0 (Network Unreachable) ICMP message.

See also RFC2827 and RFC3704.

1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995.
(Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated by
RFC2644) (Status: PROPOSED STANDARD)

2827 Network Ingress Filtering: Defeating Denial of Service Attacks
which employ IP Source Address Spoofing. P. Ferguson, D. Senie. May
2000. (Format: TXT=21258 bytes) (Obsoletes RFC2267) (Updated by
RFC3704) (Also BCP0038) (Status: BEST CURRENT PRACTICE)

3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola.
March 2004. (Format: TXT=35942 bytes) (Updates RFC2827) (Also
BCP0084) (Status: BEST CURRENT PRACTICE)

>Keep an eye on
>/proc/sys/net/ipv4/conf/all/accept_redirects

Agreed - many O/S ignore them to prevent Denial Of Service attacks

Old guy

Am Tue, 29 May 2007 19:40:11 -0500 schrieb Moe Trin:

> On Tue, 29 May 2007, in the Usenet newsgroup comp.os.linux.networking, in
> article <f3hkpp$q08$01$(E-Mail Removed)>, Burkhard Ott wrote:
>
>>schrieb (E-Mail Removed)
>
>>> I want to be able to ping machines and get "ICMP Host redirect from
>>> gateway"
>>> (for learning more about ICMP redirects).
>>
>>If 192.168.0.253 has 192.168.0.254 as default gw and your host using
>>192.168.0.253 as default gw and you ping an external IP which is not
>>reachable via broadcast (e.g. 172.30.254.1) then you should recive a
>>nice icmp redirect by the time you ping the external IP.
>
> I suspect you'll get a ICMP Type 3 Code 0 "Network unreachable" rather
> than a redirect. Where would you be redirected to? A "redirect" occurs

No, you'll be redirected because .253 and .254 are reacheable via
broadcast and .253 has .254 as default gw so he should send a redirect
to all hosts (.1-.252) this message. They are also able to reach the
default gw dirrct.

> when the router knows of a "better" route. See section 4.3.3.2
> of RFC1812, which begins
>
> 4.3.3.2 Redirect
>
> The ICMP Redirect message is generated to inform a local host that it
> should use a different next hop router for certain traffic.

Yep, thats how it works.

> and compare that to section 4.3.3.1, the first part of which says
>
> 4.3.3.1 Destination Unreachable
>
> If a router cannot forward a packet because it has no routes at all
> (including no default route) to the destination specified in the
> packet, then the router MUST generate a Destination Unreachable, Code
> 0 (Network Unreachable) ICMP message.

That message could com from .254 if the dest. would not reachable.


>>Keep an eye on
>>/proc/sys/net/ipv4/conf/all/accept_redirects
>
> Agreed - many O/S ignore them to prevent Denial Of Service attacks

Also wrong, not denial of service you could route all packets to your host
if you send a redirect to the hosts, there is a big difference because if
your host act as an router nobody will feel this difference (all requests
will be answered). So now you can sniff for usernameasswd etc.
If you DOS a host/router everybody will send an email to his system
administrator and he will check that in a short time.

Hello,

> >get "ICMP Host redirect from gateway" response ?
>
> You would have to misconfigure the networking configuration. One way to
> screw up this way is to provide _host_ routes using a gateway, such as
>

I tried and succeeded in getting a REDIRECT response, but I still have
a
little question:
I added a route with 192.168.0.10 as a gateway to a local host
(192.168.0.121).
with netmask 255.255.255.255.
192.168.0.10 a linux machine which supports sending redirects and
forwarding.

route -n shows the new entry:
192.168.0.121 192.168.0.10 255.255.255.255 UGH 0 0
0 eth0

I tried PING to 192.168.0.121 and got REDIRECT:

p -v 192.168.0.121 PING 192.168.0.121
(192.168.0.121) 56(84) bytes of data.
>From 192.168.0.10: icmp_seq=1 Redirect Host(New nexthop:
192.168.0.121)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst Data
4 5 00 5400 0000 0 0040 3f 01 22b9 192.168.0.189
192.168.0.121
64 bytes from 192.168.0.121: icmp_seq=1 ttl=64 time=1.52 ms


Running traceroute 192.168.0.121 shows that the packets go directly
to
192.168.0.121 and NOT to 192.168.0.10 as a result from this redirect,
as
expected.
Also following "ping -v 192.168.0.121" does not get
the "HOST REDIRECT" response. However, I expected that
the routing table will be updated as a result and a new entry with the
"D" flag
will be inserted, and it did not happen. The routing table stayed the
same,
as route -n shows. To be more specific:


according to "man route":
Flags: Possible flags include:
D (dynamically installed by daemon or redirect)
M (modified from routing daemon or redirect)
There is an example in chapter 9,
"9.5 ICMP Redirect Errors", of "TCP/IP Illustrated - Volume 1
The Protocols" by W. Richard Stevens.

According to this example, the routing table is added a new entry
after getting such a REDIRECT. This entry has a "D" flag.
....
....
140.252.13.35 140.252.1.183 HGHD 0 2
....


Why this did not happen in my case ? shouldn't the routing table
changed in my case ?

Regards,
Ian

On May 30, 3:39 am, ibupro...@painkiller.example.tld (Moe Trin) wrote:
> On 29 May 2007, in the Usenet newsgroup comp.os.linux.networking, in article
>
> <1180440763.168583.236...@q69g2000hsb.googlegroups .com>, ian...@gmail.com wrote:
> >I am connected to a LAN which has addresses in the range
> >192.168.0.10-192.168.0.253.
> >The default gw is 192.168.0.254 and is conneted outside to the
> >internet:
>
> OK
>
> >I want to be able to ping machines and get "ICMP Host redirect from
> >gateway"
> >(for learning more about ICMP redirects).
>
> 0792 Internet Control Message Protocol. J. Postel. September 1981.
> (Format: TXT=30404 bytes) (Obsoletes RFC0777) (Updated by RFC0950)
> (Also STD0005) (Status: STANDARD)
>
> 1812 Requirements for IP Version 4 Routers. F. Baker, Ed.. June 1995.
> (Format: TXT=415740 bytes) (Obsoletes RFC1716, RFC1009) (Updated by
> RFC2644) (Status: PROPOSED STANDARD)
>
> and from RFC1812, we find
>
> 4.3.3.2 Redirect
>
> The ICMP Redirect message is generated to inform a local host that it
> should use a different next hop router for certain traffic.
>
> Contrary to [INTRO:2], a router MAY ignore ICMP Redirects when
> choosing a path for a packet originated by the router if the router
> is running a routing protocol or if forwarding is enabled on the
> router and on the interface over which the packet is being sent.
>
> and
>
> 5.2.7.2 Redirect
>
> The ICMP Redirect message is generated to inform a local host the it
> should use a different next hop router for a certain class of
> traffic.
>
> Routers MUST NOT generate the Redirect for Network or Redirect for
> Network and Type of Service messages (Codes 0 and 2) specified in
> [INTERNET:8]. Routers MUST be able to generate the Redirect for Host
> message (Code 1) and SHOULD be able to generate the Redirect for Type
> of Service and Host message (Code 3) specified in [INTERNET:8].
>
> followed by about a page of discussion/explanation.
>
> >I made some trials but could not achieve this.
>
> A _host_ redirect (ICMP Type 5 Code 1) would occur when you send traffic
> _for_ one of the local hosts (192.168.0.10-192.168.0.253 in your example),
> but send it to the default gateway (192.168.0.254) and expect it to
> deliver the packet. The gateway will get unhappy, and send the redirect
> trying to tell you "don't send it to me - send it directly to the host
> which is on this same wire". This occurs when the person who set up the
> routing tables made an error. This error is generated when the router
> notices that the packet it received on interface $FOO is going to be sent
> back out using the same interface. "Why are you wasting _my_ time?".
>
> >Can anybody suggest a senario where as a result of a ping (it can be
> >of course to a machine on the internet or a machine in the LAN) I will
> >get "ICMP Host redirect from gateway" response ?
>
> You would have to misconfigure the networking configuration. One way to
> screw up this way is to provide _host_ routes using a gateway, such as
>
> Kernel IP routing table
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 192.168.0.0 0.0.0.0 255.255.255.0 U 0 0 4198 eth0
> 192.168.0.10 192.168.0.254 255.255.255.255 UGH 0 0 56 eth0
> 192.168.0.11 192.168.0.254 255.255.255.255 UGH 0 0 56 eth0
> 192.168.0.12 192.168.0.254 255.255.255.255 UGH 0 0 56 eth0
> default 192.168.0.254 0.0.0.0 UG 0 0 10 eth0
>
> In routing tables, when there are multiple routes to the same place, the
> route with more bits in the network mask wins. Metric may also be a factor
> and here I've intentionally set the metrics to zero. Note that if there
> are two or more routes to the same place, with the same network mask and
> the same metric, then the _last_ route specified wins.
>
> Regarding ICMP Redirects, you should be aware that many operating systems
> _ignore_ redirects - because this has been used in Denial Of Service
> attacks in the past. Really, you shouldn't see them that often anyway, as
> this generally occurs because of intentional configuration errors. ICMP
> _Network_ Redirections (type 5 code 0) is generally the result of setting
> the wrong gateway value in a routing table. An example might be
>
> Destination Gateway Genmask Flags Metric Ref Use Iface
> 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 89948 eth0
> 192.168.2.0 192.168.1.6 255.255.255.0 UG 0 0 32165 eth0
> 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 388 lo
> 0.0.0.0 192.168.1.248 0.0.0.0 UG 0 0 2673 eth0
>
> If you sent packets destined for 192.168.2.x to 192.168.1.248 for
> forwarding, that router would complain, and tell you to use 192.168.1.6
> as the gateway for this route. For this to occur, the mis-configured
> host would be lacking the second route, and assume that everything not
> local goes to 192.168.1.248.
>
> Old guy

On Wed, 30 May 2007, in the Usenet newsgroup comp.os.linux.networking, in
article <f3j6cq$9t5$(E-Mail Removed)>, Burkhard Ott wrote:

>Am Tue, 29 May 2007 19:40:11 -0500 schrieb Moe Trin:

>> Burkhard Ott wrote:

>>> If 192.168.0.253 has 192.168.0.254 as default gw and your host using
>>> 192.168.0.253 as default gw

>> I suspect you'll get a ICMP Type 3 Code 0 "Network unreachable" rather
>> than a redirect. Where would you be redirected to? A "redirect" occurs
>
>No, you'll be redirected because .253 and .254 are reacheable via
>broadcast and .253 has .254 as default gw so he should send a redirect
>to all hosts (.1-.252) this message.


Yes, I missed the .253 vs .254 - you are correct about a redirect here.
The "Network unreachable" will be generated by the first host that
realizes that's an RFC3330 address. Why do you think that ALL hosts
would receive and act on the redirect? The error is a unicast message,
not a broadcast.

>> Agreed - many O/S ignore them to prevent Denial Of Service attacks
>
>Also wrong, not denial of service you could route all packets to your host
>if you send a redirect to the hosts, there is a big difference because if
>your host act as an router nobody will feel this difference (all requests
>will be answered). So now you can sniff for usernameasswd etc.
>If you DOS a host/router everybody will send an email to his system
>administrator and he will check that in a short time.

No, I said Denial Of Service, and I meant it. This has been used by windoze
hax0r kiddiez since they discovered networking in 1995/6 to knock their
"friends" off the Internet for some period of time (in the case of win95,
until it blue screened, and the kid had to reboot).

Old guy

On 30 May 2007, in the Usenet newsgroup comp.os.linux.networking, in article
<(E-Mail Removed). com>, (E-Mail Removed) wrote:

>I tried and succeeded in getting a REDIRECT response, but I still have
>a little question:
>I added a route with 192.168.0.10 as a gateway to a local host
>(192.168.0.121). with netmask 255.255.255.255.
>192.168.0.10 a linux machine which supports sending redirects and
>forwarding.
>
>route -n shows the new entry:
>192.168.0.121 192.168.0.10 255.255.255.255 UGH 0 0 0 eth0
>
>I tried PING to 192.168.0.121 and got REDIRECT:

OK

>Running traceroute 192.168.0.121 shows that the packets go directly
>to 192.168.0.121 and NOT to 192.168.0.10 as a result from this redirect,
>as expected. Also following "ping -v 192.168.0.121" does not get
>the "HOST REDIRECT" response. However, I expected that the routing table
>will be updated as a result and a new entry with the "D" flag will be
>inserted, and it did not happen. The routing table stayed the same,
>as route -n shows.

I can't say - you'd have to look at the kernel source (depending, this
should be in /usr/src/linux/net/ipv4/* somewhere). I'm not exactly sure
the D flag is implemented in modern kernels. I'd also be looking at the
ARP cache.

>There is an example in chapter 9,
>"9.5 ICMP Redirect Errors", of "TCP/IP Illustrated - Volume 1
>The Protocols" by W. Richard Stevens.

Yes, but what operating system? (Host "solaris" was running am ear;y
version of Solaris 2.2. One of the nice things about "TCP/IP Illustrated"
was that Stevens had a bunch of contemporary systems running various
O/S so you could see the differences. But it was written in 1994, and
Linux wasn't all that common at the time. SLS, Slackware, Yggdrasil,
even an early Debian were available, but that was either an 0.99* or
early 1.0.x kernel.)

Old guy

Am Wed, 30 May 2007 20:10:00 -0500 schrieb Moe Trin:

> Yes, I missed the .253 vs .254 - you are correct about a redirect here.
> The "Network unreachable" will be generated by the first host that
> realizes that's an RFC3330 address. Why do you think that ALL hosts
> would receive and act on the redirect? The error is a unicast message,
> not a broadcast.

Yes, didn't wrote that they would get a broadcast message, did I?
The answer receives the host which sent the icmp echo reply, but hte
redirect comes only to those hosts which are in the same network
(192.168.0.0/24 that means .1 to 254)
If you take a host which is outside of that network you won't get a
redirect, because here it doesn't matter who is the router as far he has
access to the other network.
e.g. .253 has a second interface (or vlan) and now the ip 10.10.10.1 ping
192.168.0.1 then he will not get a redirect.
Maybe I wrote a little confusing, english isn't my native language sorry
for that.

> No, I said Denial Of Service, and I meant it. This has been used by windoze
> hax0r kiddiez since they discovered networking in 1995/6 to knock their
> "friends" off the Internet for some period of time (in the case of win95,
> until it blue screened, and the kid had to reboot).
No you are wrong, they use packet fragmentation, if your icmp packet size
to big then it'll be fragmented, the made the packetsize so that the
packet after reassembling has had a size larger than 65535 and that was
the reason that the kernel couldn't handle and the bluescreen appeared.
Even Linunx and BSD had the problem but they fixed it in one night and
after patching the kernel all was fine.
M$ did that very late and so came lot's of messages about that thing, the
icmp redirect should be have the same size every time.
cya

Am Wed, 30 May 2007 20:10:50 -0500 schrieb Moe Trin:

> I can't say - you'd have to look at the kernel source (depending, this
> should be in /usr/src/linux/net/ipv4/* somewhere). I'm not exactly sure
> the D flag is implemented in modern kernels. I'd also be looking at the
> ARP cache.
e.g:
/proc/sys/net/ipv4/conf/eth0/send_redirects
/proc/sys/net/ipv4/conf/eth0/secure_redirects
/proc/sys/net/ipv4/conf/eth0/accept_redirects
/proc/sys/net/ipv4/conf/lo/send_redirects
/proc/sys/net/ipv4/conf/lo/secure_redirects
/proc/sys/net/ipv4/conf/lo/accept_redirects
/proc/sys/net/ipv4/conf/default/send_redirects
/proc/sys/net/ipv4/conf/default/secure_redirects
/proc/sys/net/ipv4/conf/default/accept_redirects
/proc/sys/net/ipv4/conf/all/send_redirects
/proc/sys/net/ipv4/conf/all/secure_redirects
/proc/sys/net/ipv4/conf/all/accept_redirects
/proc/sys/net/ipv4/route/redirect_silence
/proc/sys/net/ipv4/route/redirect_number