On Tue, 2003-09-09 at 15:02, Daniel Hartmeier wrote:
On Tue, Sep 09, 2003 at 11:04:23AM -0500, Steve Mertz wrote:
> Does anyone have any ideas why this is happening? And how to stop it?
I tried to reproduce this, but couldn't. I set up an IP forwarder with
two nics (gem0 10.1.1.10/8, kue0 192.168.1.10/16) and connect a box with
address 192.168.2.6 to the kue0 segment.
My networks were 10.10.10.0/24 and 10.10.11.0/24. Could this be a
factor in why you couldn't reproduce it? Your networks are completely
different where as mine are very similar?
When I send a dhcp query from the client with
cat payload | \
dnet udp sport 68 dport 67 | \
dnet ip proto udp src 0.0.0.0 dst 255.255.255.255 | \
dnet eth type ip src 0:0:39:63:f0:8a dst ff:ff:ff:ff:ff:ff | \
dnet send fxp0
I see it arrive on kue0 on the firewall. But even with pf completely
disabled and IP forwarding turned on, the packet is NOT sent out on
gem0. If I load the rule
block in log quick on kue0 inet proto udp from any to any port 67
and enable pf on the forwarder, I see pf matching the rule and blocking
the packet, logging it as
Sep 09 21:42:14.295462 rule 0/0(match): block in on kue0: 0.0.0.0.68 >
255.255.255.255.67: bootp...
And the packet doesn't appear on gem0, either. Other udp traffic (like
DNS or nc -u) gets forwarded successfully.
> I've attached my pf.conf. If you need more info, please let me know.
> If you would like log files, then let me know what kind, and how to
> obtain them, as I'm new to playing with tcpdump and the like.
The fact that even with pf disabled, the broadcast shouldn't get
forwarded, indicates that it's not a pf problem at all. There's a couple
of possible explanations for the forwarding:
a) do you have bridge enabled (brconfig -a)?
No.
b) do you have any bpf/pcap listeners running on the firewall that
might forward the request? dhcpd, bootp (check inetd.conf) or
dhcrelay might do that, among others. kill any userland process
that isn't required for the test, and repeat.
Nope.
c) can you verify that your second interface is REALLY sending out
the dhcp request? run tcpdump and make sure you're not dumping
_incoming_ packets from other sources.
Yes. If I tcpdump, both nics, I can watch the packets come in on rl0,
go out on rl1, then come back in rl1 and go out rl0.
d) you mentioned specific hardware (openbrick), does it do anything
in hardware that might explain this behaviour? if you repeat the
test with ifconfig down'ed interfaces, do they maybe work as hub
independantly of the OS?
No. It's a PC with 3 onboard nics, nothing really special about it.
e) are you absolutely sure there's nothing else bridging the two
local networks? like a tiny little hub somewhere? :)
I'm quite positive.
I did some more testing. I disabled pf, and did some tests.
1) I tried to connect to the wan from the lan (going through the
firewall) and could not.
2) I could connect to a machine on my lan from the firewall
3) I could connect to a machine on my wan from the firewall.
4) DHCP packets still made it through. As before I could see them
coming in on rl0, go out no rl1, then back through the other way.
Back info: I use to have a SonicWall as our firewall here. And it was
happily working. Then it started to flake out
Bob Beck also tried to reproduce this, and couldn't, either.
Daniel
