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
