--- Daniel Hartmeier <[EMAIL PROTECTED]> schrieb: > 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.
I did run tcpdump -nevvi <if> for the logs.
Apart from the tcpdump output i got a PF rule for only allowing ssh access to
the bridge box coming IN fxp0 .. needless to say, it works also when i connect via IN
fxp1 :O
Thats exactly what i want to prevent :)
>
> > [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.
I did remove the leading date info on the pflog lines
The box is installed from ftp server and i have cvsup'ed sys and src with the stable
tag
and did compile and install new kernel, rebooted and did a make build inside /usr/src
>From the file creation dates i would say it's all up-to-date
>
> > 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.
That is the thing i don't believe will work as the packet is *not* going through the
bridge.
I tried to block the MAC adress of IF_B on the bridge's member IF_A but ip is still
coming in IF_B
> Daniel
Thank you for the ongoing support.
erpel23
__________________________________________________________________
Gesendet von Yahoo! Mail - http://mail.yahoo.de
Logos und Klingelt�ne f�rs Handy bei http://sms.yahoo.de
