Messages in this thread | | | From | kutek@raven ... | Date | Thu, 9 Jul 1998 10:47:39 -0400 | Subject | further problems in the linux firewall |
| |
Continuing with the further adventures of No Root Daemon Man and the Evil ipfwadm udp bug:
to recap: transparent proxying is broken for udp in kernel 2.0.34(but works for tcp). with a rule like the following:
ipfwadm -I -P -i accept -r 1153 -S 127.0.0.1/32 -D 127.0.0.1/32 53
info coming from the daemon sitting on port 1153 ( named) is seen by the net app (ftp, telenet etc) making a dns request to port 53 as coming from port 1153 rather than 53 as would be expected.these net apps ( aside from nslookup) don't like this at all and cannot receive the dns info from the 1153 port.
well since the -b option didn't affect the situation i tried to add another rule to redirect port 1153 back to 53 like this:
ipfwadm -I -P udp -i accept -r 53 -S 127.0.0.1 1153 -D 127.0.0.1
i know i know, this looks like a loop, and not only did the net apps not like it, neither did nslookup. so i deleted the rule with
ipfwadm -I -P udp -d accept -r 53 -S 127.0.0.1 1153 -D 127.0.0.1/32
after making attempts at ftp and nslookup, which did not work. I then listed the input firewall rules with ipfwadm -I -l wherein i see the following surprising result:
BEFORE the deletion: acc/r udp 127.0.0.1 127.0.0.1 1153 -> * => 53 acc/r udp 127.0.0.1 127.0.0.1 * -> 53 => 1153
AFTER the deletion:
acc udp 0.0.0.0/0 208.199.64.101 53 -> 1053 acc/r udp 127.0.0.1 127.0.0.1 * -> 53 => 1153
!!!!!
a new rule pops out of nowhere, and it is real since it can be deleted with ipfwadm -I -P - d accept -S 0/0 53 -D 208.199.64.101/32 1053 without the kernel complaining about invalid setsockopts.
note that if no attempt is made to access dns ,the phantom rule does not appear after the deletion.further, no rule for udp specifies the IP address that appears in the phantom rule (which happens to be the real current ppp ip address)
originally i had named talking to the root servers via port 1053, but when i changed that to 1253, the port 1053 artifact rule still appeared.
this seems to indicate deeper problems with the firewall code than previously suspected.
I note that debian has replaced ipfwadm with ip chains, but i am not enthusiastic about switching over...but does anyone have any comments on ip chain functionality? can someone using it please try to redirect udp and see if it has the problem ipfwadm has? thanks.
fractoid
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |