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

Re: pf between two lans and passing dhcp through

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, kue0 and connect a box with
    address to the kue0 segment.
My networks were and  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 dst | \
            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: >  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.
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.