Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
On Wed, Feb 13, 2002 at 03:57:33PM -0800, Terry Lambert wrote: Ruslan Ermilov wrote: On Wed, Feb 13, 2002 at 10:50:13AM -0500, Garrett Wollman wrote: On Wed, 13 Feb 2002 11:03:47 +0200, Ruslan Ermilov [EMAIL PROTECTED] said: Please test with and without this patch. I continue to believe that this should be done by fixing the routing, not by adding additional hacks to the already-bloated ip_output() path. BSD always had these hacks (rfc1122 requirements) in in_canforward(). RFC1122 requires the host to not send 127/8 addresses out of loopback, whether or not its routes are set up correctly. I pretty much agree with Garrett on this one. Loopback is a special critter; it has all sorts of requirements, like not ARP'ing for addresses configured on it (otherwise FreeBSD is not usable for DSR, which I think it currently is not), etc.. Heh? Without my patch: # ifconfig rl0 inet rl0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet 192.168.4.115 netmask 0xff00 broadcast 192.168.4.255 inet 127.0.0.2 netmask 0xff00 broadcast 127.255.255.255 # ping 127.0.0.3 # tcpdump -n net 127 tcpdump: listening on rl0 10:29:12.685957 arp who-has 127.0.0.3 tell 127.0.0.2 ^C 2480 packets received by filter 0 packets dropped by kernel It looks to me that this should be handled some place other than ip_output(). Perhaps you don't realize that we can't fix this with just routing because we are also not allowed to send out packets originated from loopback network, like: ping -s 127.1 1.2.3.4 telnet -S 127.1 1.2.3.4 Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
On Thu, 14 Feb 2002 11:09:41 +0200, Ruslan Ermilov [EMAIL PROTECTED] said: ping -s 127.1 1.2.3.4 telnet -S 127.1 1.2.3.4 If someone explicitly overrides source-address selection, they are presumed to know WTF they are doing, and the kernel should not be trying to second-guess them. -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
[Redirected to -net] On Thu, Feb 14, 2002 at 11:39:37AM -0500, Garrett Wollman wrote: On Thu, 14 Feb 2002 11:09:41 +0200, Ruslan Ermilov [EMAIL PROTECTED] said: ping -s 127.1 1.2.3.4 telnet -S 127.1 1.2.3.4 If someone explicitly overrides source-address selection, they are presumed to know WTF they are doing, and the kernel should not be trying to second-guess them. That someone could be a bad guy playing dirty games with your box and certainly knowing what he's doing. :-) So far, noone gave me a real example where using of net 127 outside loopback would be useful. If there such an example exists, we should wrap all three checks into a sysctl, including ip_input(), ip_output(), and in_canforward() parts, where ip_input() exists for almost a year, and in_canforward() existed since 1987. -- Ruslan, who just wants a consistency here. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
On Wed, Feb 13, 2002 at 10:50:13AM -0500, Garrett Wollman wrote: On Wed, 13 Feb 2002 11:03:47 +0200, Ruslan Ermilov [EMAIL PROTECTED] said: Please test with and without this patch. I continue to believe that this should be done by fixing the routing, not by adding additional hacks to the already-bloated ip_output() path. BSD always had these hacks (rfc1122 requirements) in in_canforward(). RFC1122 requires the host to not send 127/8 addresses out of loopback, whether or not its routes are set up correctly. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
On Wed, 13 Feb 2002 17:58:51 +0200, Ruslan Ermilov [EMAIL PROTECTED] said: RFC1122 requires the host to not send 127/8 addresses out of loopback, whether or not its routes are set up correctly. As we have already seen, there is not consensus on this particular issue, or on the general issue of how much of 1122 we should pay attention to at all. (Are you going to implement multiple default routes as well?) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
Ruslan Ermilov wrote: On Wed, Feb 13, 2002 at 10:50:13AM -0500, Garrett Wollman wrote: On Wed, 13 Feb 2002 11:03:47 +0200, Ruslan Ermilov [EMAIL PROTECTED] said: Please test with and without this patch. I continue to believe that this should be done by fixing the routing, not by adding additional hacks to the already-bloated ip_output() path. BSD always had these hacks (rfc1122 requirements) in in_canforward(). RFC1122 requires the host to not send 127/8 addresses out of loopback, whether or not its routes are set up correctly. I pretty much agree with Garrett on this one. Loopback is a special critter; it has all sorts of requirements, like not ARP'ing for addresses configured on it (otherwise FreeBSD is not usable for DSR, which I think it currently is not), etc.. It looks to me that this should be handled some place other than ip_output(). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
Garrett Wollman wrote: On Wed, 13 Feb 2002 17:58:51 +0200, Ruslan Ermilov [EMAIL PROTECTED] said: RFC1122 requires the host to not send 127/8 addresses out of loopback, whether or not its routes are set up correctly. As we have already seen, there is not consensus on this particular issue, or on the general issue of how much of 1122 we should pay attention to at all. (Are you going to implement multiple default routes as well?) Actually, that's been a sore point in three commercial projects (so far), so it's probably not a good example. 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: rdr 127.0.0.1 and blocking 127/8 in ip_output()
On Wed, Feb 13, 2002 at 11:03:47AM +0200, Ruslan Ermilov wrote: Hi! Please test with and without this patch. Hmm. I'm having a little trouble testing this on -CURRENT. As a first step, I just deleted all of the 127/8 blocking code in ip_output.c, and tried to do a rdr to 127.0.0.1. First, make sure the stops on outging 127/8 are really gone, bubbles# ping 127.0.0.2 PING 127.0.0.2 (127.0.0.2): 56 data bytes ^C --- 127.0.0.2 ping statistics --- 2 packets transmitted, 0 packets received, 100% packet loss bubbles# And I see, bubbles# tcpdump 'net 127.0.0.0/8' tcpdump: listening on ep0 15:46:29.954112 bubbles 127.0.0.2: icmp: echo request 15:46:30.964695 bubbles 127.0.0.2: icmp: echo request ^C 46 packets received by filter 0 packets dropped by kernel bubbles# OK, all great. So I fire up ipnat(1), bubbles# cat ipnat.rules # $Id$ # # Testing IPFilter interaction with loopback rdr ep0 192.168.64.20/32 port 23 - 127.0.0.1 port 2323 tcp bubbles# ipnat -C -f ipnat.rules 1 entries flushed from NAT list bubbles# ipnat -l List of active MAP/Redirect filters: rdr ep0 192.168.64.20/32 port 23 - 127.0.0.1 port 2323 tcp List of active sessions: bubbles# ipfstat -io pass out from any to any pass in from any to any bubbles# And I start a listener on 2323, $ nc -l -p 2323 And from another host, $ telnet bubbles 23 Trying 192.168.64.20... telnet: connect to address 192.168.64.20: Operation timed out telnet: Unable to connect to remote host That is, it doesn't work. However, bubbles# ipnat -l List of active MAP/Redirect filters: rdr ep0 192.168.64.20/32 port 23 - 127.0.0.1 port 2323 tcp List of active sessions: RDR 127.0.0.1 2323 - - 192.168.64.20 23[192.168.64.60 1099] ipnat(1) is working. Where are the packets going? I couldn't find any being blocked or in the netstat statistics. Now, to see if this works at all, I change the ipnat.rules, bubbles# cat ipnat.rules # $Id$ # # Testing IPFilter interaction with loopback rdr ep0 192.168.64.20/32 port 23 - 192.168.64.20 port 2323 tcp bubbles# ipnat -C -f ipnat.rules 1 entries flushed from NAT list bubbles# Now I try, $ telnet bubbles 23 Trying 192.168.64.20... Connected to bubbles.cjclark.org. Escape character is '^]'. And it works fine, bubbles# ipnat -l List of active MAP/Redirect filters: rdr ep0 192.168.64.20/32 port 23 - 192.168.64.20 port 2323 tcp List of active sessions: RDR 192.168.64.20 2323 - - 192.168.64.20 23[192.168.64.60 1100] RDR 127.0.0.1 2323 - - 192.168.64.20 23[192.168.64.60 1099] bubbles# So at least in -CURRENT, did this 127.0.0.1 redirect doesn't seem to work even if you remove the code from ip_output.c completely. I'll give -STABLE a try, but these IPFilter people will have the same problem when 5.0-RELEASE comes around if my tests are accurate. -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
