On Mon, Mar 12, 2001 at 10:14:17PM -0400, Peter Cordes wrote:
...
> Arggghh! Sorry, you're right. I was pretty sure that linux checked the
> dest of packets before accepting them, so I guess my brain decided to read
> it wrong and think you were talking about what I expected you to be a
> talking about :(
>
> I decided to check this out, partly since I owe you one for being an idiot
> and not listening to what you told me twice!
I know you don't owe me one, but the original question has boggered me
for sometime, and I can't find the anwser myself, and now you really
got me confused with this llama and bigfoot example, so _please_ bear
with me and explain what you wanted to show that does or doesn't work.
For now I guess you wanted to check that Linux *does* filter on packet
*destinations* , but I can't follow the example. To be honest, I don't
see how Linux could filter those out at all, as destination addresses
are used to route, and what's wrong with routing to a local net? Unless
you specify somewhere that local addresses aren't allowed on a specific
interface, and I know of non such parameter to the linux routing code
(but he, I know nothing of that code, tried to read it once and failed:)
[[ I leave the rest of your message in, to make it easier to explain :]]
> llama is 10.0.0.1, MAC 00:00:92:96:51:C0.
> bigfoot is 10.0.0.4, MAC 00:05:02:D4:B7:0A.
>
> On bigfoot, I used arp -s to point a nonexistant IP to the same MAC
> address as llama, a linux machine running 2.2.18.
>
>
> bigfoot:~# arp
> Address HWtype HWaddress Flags Mask Iface
> 10.0.0.10 ether 00:00:92:96:51:C0 CM eth0
> llama ether 00:00:92:96:51:C0 C eth0
>
> bigfoot:~# nc 10.0.0.10 25
> (UNKNOWN) [10.0.0.10] 25 (smtp) : No route to host
>
>
> before attempting the connection, I did:
> llama:~# tcpdump -p -e -n -i eth1 port ! ssh
> tcpdump: listening on eth1
> 22:03:23.249795 0:5:2:d4:b7:a 0:0:92:96:51:c0 0800 74: 10.0.0.4.3641 >
> 10.0.0.10.25: S 1026521176:1026521176(0) win 5840 <mss 1460,sackOK,timestamp
> 59103824 0,nop,wscale 0> (DF)
> 22:03:23.250230 0:0:92:96:51:c0 0:5:2:d4:b7:a 0800 102: 10.0.0.1 > 10.0.0.4:
> icmp: redirect 10.0.0.10 to host 10.0.0.10 [tos 0xc0]
> 22:03:23.250502 0:0:92:96:51:c0 ff:ff:ff:ff:ff:ff 0806 42: arp who-has
> 10.0.0.10 tell 10.0.0.1
> 22:03:24.243578 0:0:92:96:51:c0 ff:ff:ff:ff:ff:ff 0806 42: arp who-has
> 10.0.0.10 tell 10.0.0.1
> 22:03:25.243324 0:0:92:96:51:c0 ff:ff:ff:ff:ff:ff 0806 42: arp who-has
> 10.0.0.10 tell 10.0.0.1
> 22:03:26.243237 0:0:92:96:51:c0 0:5:2:d4:b7:a 0800 102: 10.0.0.1 > 10.0.0.4:
> icmp: host 10.0.0.10 unreachable [tos 0xc0]
>
> Notice that with the interface not in promiscuous mode (-p), tcpdump still
> received the SYN packet, but the kernel didn't start a connection. exim is
> listening on *:25, (i.e. INADDR_ANY, not the interface addresses).
> nc 10.0.0.1 25 connects to exim normally.
>
> It's not so easy to check what happens if you send a packet with a
> destination in 127.0.0.0/8, but I'd be surprised if it was accepted.
--
groetjes, carel
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]