On Sat, Sep 13, 2003 at 03:35:30PM +0200, Torsten wrote:
> > > (lan_A)-----( if_A: noIP )-|bridge|-( if_B: ip_B )----(lan_B)
> >
> > > IP datagram from (lan_A) to ip_B
> > > First appearance of the ip datagram within pf is: IN if_B (!)
> > >
> > > IP comes in a ethernet frame with dst mac for if_A and can only arrive
> > > on if_A due cabling.
> >
> > Why would the destination MAC be for if_A? Normal ARP should respond
> > with if_B's MAC over the bridge.
>
> Sorry, i made a typo there. The dst MAC is the MAC of if_B
Why would a frame from lan_A (to anywhere) come in on if_B (and not,
first, on if_A)? That makes no sense, indeed. Either you were not
tcpdumping on if_A correctly, or you were seeing a reply in reverse
direction. A packet from a host on lan_A to ip_B should be seen only
incoming on if_A, then the stack on the bridge will notice that the
destination is itself (if the destination MAC address is that of if_B),
and consume it. There's no reason why it would pass if_B at all.
> [pflog0] 15:09:18.855301 rule 0/0(match): pass in on fxp0: 192.168.0.100 >
> 192.168.0.11: icmp:
> echo request (id:2 seq:2) (ttl 128, id 30640, bad cksum b8fc!)
> [pflog0] 15:09:18.855371 rule 0/0(match): pass out on fxp0: 192.168.0.11 >
> 192.168.0.100: icmp:
This suspicously looks like an out-of-sync kernel/userland, or an older
-current with a bug. pf and pflog headers were changed, and if you
rebuilt a newer kernel but didn't rebuild tcpdump, for instance, you'd
get results like this. Update the entire source tree to one consistant
version, the rebuild the kernel and entire userland, to make sure.
> Why is there no way for gettin the physical interface the packet comes in? this is
> the *only* thing that ain't spoofable.. i would love to filter that in the pf :)
If you update to -current, you can use tags for that. Either bridge or
pf can add a tag ('packet came in on interface fxp0'), and you can
filter based on that tag.
Daniel
