Ok, first off I'm going to attach a service manifest file for anyone else who
finds this and decides they need to also disable this property.
> svccfg import disable_icmp_redirect.xml
> svcadm enable disable_icmp_redirect
Now, yes I have been watching arp, and yes that MAC address is the mac address
of the windows box, I really do think I have a broken router (having said that
it has always been broken). Obviously something has changed somewhere between
snv_122 and 129, because booting into 122 I don't get the same behaviour (it
ignores the ICMP redirect). I assume somewhere along the line someone has
either:
a. turned on a feature that was always there and disabled, or
b. implemented a new feature to process this stuff, and didnt include any
sanity checking
So I suppose it's up to whoever decides to look at this and how they choose to
look at this. I'm gonna put it in bugzilla so its registered. Really for most
people it won't cause any actual problems (because they don't have buggy
devices on their network), but in terms of security it is an issue.
I'm off to look for firmware updates for my router (although I don't hold much
hope).
As an experiment I duplicated the test on my mac to prove the router is
behaving the same way for that too. The results show the routing tables are
done way differently (and are more complex because there are more interfaces -
including a bunch of vmware ones). I suppose this is expected given its
basically FreeBSD.
> netstat -rn
Routing tables
Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.1.254 UGSc 11 0 en1
127 127.0.0.1 UCS 0 0 lo0
127.0.0.1 127.0.0.1 UH 6 4558 lo0
169.254 link#6 UCS 0 0 en1
172.16.68/24 link#9 UC 0 0 vmnet1
172.16.217/24 link#8 UC 0 0 vmnet8
192.168.1 link#6 UCS 6 0 en1
192.168.1.11 0:23:12:9f:8f:b5 UHLWI 0 0 en1 351
192.168.1.69 127.0.0.1 UHS 0 0 lo0
192.168.1.70 0:19:d1:e7:99:5d UHLWI 0 193 en1
192.168.1.71 0:1c:c0:38:fa:87 UHLWI 0 2408 en1 1159
192.168.1.169 0:1c:c0:c4:6e:44 UHLWI 3 652806 en1 1164
192.168.1.254 0:12:bf:12:a0:32 UHLWI 31 4991 en1 1161
192.168.1.255 ff:ff:ff:ff:ff:ff UHLWbI 0 2 en1
Internet6:
Destination Gateway Flags
Netif Expire
::1 ::1 UH
lo0
fe80::%lo0/64 fe80::1%lo0 Uc
lo0
fe80::1%lo0 link#1 UHL
lo0
fe80::%en1/64 link#6 UC
en1
fe80::21c:c0ff:fec4:6e44%en1 0:1c:c0:c4:6e:44 UHLW
en1
fe80::223:6cff:fe83:702e%en1 0:23:6c:83:70:2e UHL
lo0
ff01::/32 ::1 Um
lo0
ff02::/32 ::1 UmC
lo0
ff02::/32 link#6 UmC
en1
Pinging gives me this output:
> ping activity
PING activity (192.168.1.70): 56 data bytes
36 bytes from router (192.168.1.254): Redirect Host(New addr: 192.168.1.70)
Vr HL TOS Len ID Flg off TTL Pro cks Src Dst
4 5 00 0054 041f 0 0000 3f 01 f3ae 192.168.1.69 192.168.1.70
Request timeout for icmp_seq 0
...
No changes are made to the routing table.
As for the raw snoop:
tcpdump -i en1 -e -XX -n host router or activity
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on en1, link-type EN10MB (Ethernet), capture size 65535 bytes
00:26:06.428430 00:23:6c:83:70:2e > 00:19:d1:e7:99:5d, ethertype IPv4 (0x0800),
length 98: 192.168.1.69 > 192.168.1.70: ICMP echo request, id 24596, seq 0,
length 64
0x0000: 0019 d1e7 995d 0023 6c83 702e 0800 4500 .....].#l.p...E.
0x0010: 0054 041f 0000 4001 f2ae c0a8 0145 c0a8 .t....@......e..
0x0020: 0146 0800 ce2d 6014 0000 4b29 0a1e 0006 .F...-`...K)....
0x0030: 896d 0809 0a0b 0c0d 0e0f 1011 1213 1415 .m..............
0x0040: 1617 1819 1a1b 1c1d 1e1f 2021 2223 2425 ...........!"#$%
0x0050: 2627 2829 2a2b 2c2d 2e2f 3031 3233 3435 &'()*+,-./012345
0x0060: 3637 67
00:26:06.432453 00:12:bf:12:a0:32 > 00:23:6c:83:70:2e, ethertype IPv4 (0x0800),
length 70: 192.168.1.254 > 192.168.1.69: ICMP redirect 192.168.1.70 to host
192.168.1.70, length 36
0x0000: 0023 6c83 702e 0012 bf12 a032 0800 4500 .#l.p......2..E.
0x0010: 0038 1ce1 0000 4001 d950 c0a8 01fe c0a8 .8....@..p......
0x0020: 0145 0501 02ce c0a8 0146 4500 0054 041f .E.......FE..T..
0x0030: 0000 3f01 f3ae c0a8 0145 c0a8 0146 0800 ..?......E...F..
0x0040: ce2d 6014 0000 .-`...
00:26:06.504309 00:12:bf:12:a0:32 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806),
length 60: Request who-has 192.168.1.70 tell 192.168.1.254, length 46
0x0000: ffff ffff ffff 0012 bf12 a032 0806 0001 ...........2....
0x0010: 0800 0604 0001 0012 bf12 a032 c0a8 01fe ...........2....
0x0020: 0000 0000 0000 c0a8 0146 0000 0000 0000 .........F......
0x0030: 0000 0000 0000 0000 0000 0000
You can even see the router is trying to find the missing host.
--
This message posted from opensolaris.org
_______________________________________________
networking-discuss mailing list
networking-discuss@opensolaris.org
