[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: pf between two lans and passing dhcp through



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.
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)?
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.
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.
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?
e) are you absolutely sure there's nothing else bridging the two
   local networks? like a tiny little hub somewhere? :)
Bob Beck also tried to reproduce this, and couldn't, either.
Daniel