I'm copying both pf and [EMAIL PROTECTED] It's looking as though I may
have to take this to a Sparc specific forum, though. Unless someone
can offer an explanation of what I'm seeing, I'm starting to suspect
Sparc/SBUS-specific programming here.
1b. bridge (4), and all of the literature I can find online says
that frames on the bridge will pass through pf twice.
"Bridged frames pass through pf(4) twice. They can be filtered
on any interface, in both directions."
-> They do not appear to do so. They appear to pass through pf only
once.
That is, they pass in once and out once, exactly as they do when
routing between two Subnets in an unbridged configuration.
That sentence is meant to explain exactly that there's no difference
between bridging and IP forwarding regarding pf, that pf sees the same
packet twice, once incoming on an interface, once outgoing on another
interface, that's twice.
The reason why it's mentioned is that some OS / packet filter
combinations don't work this way.
Ah. That makes sense, then. I was confused, probably by the fact that
my other problem makes it appear as though the packets are going in and
out on both le0 and le2...
2b. traffic from the LAN to the router appears to come from the
wrong interface
I suspect that if I can solve this one, it will go a great way toward
explaining my issues with bridge tagging...
You might want to run tcpdump -nvvvei <if> on the two interfaces
directly and check the MAC addresses printed. pf will see the same
frames on the same interfaces as you see with tcpdump on the
interfaces.
If a frame really comes in on the wrong interfaces, and tcpdump shows
that, you can be pretty sure that, for whatever reason, the frame
really
did arrive on that interface. The explanation must be found somewhere
in
your network or cabling.
If the frames are coming in on the wrong physical device, then its a
Sun SBUS problem, because it's not happening OUTSIDE the box. le2 has
cat5 running to a hub. That hub currently, for testing purposes, has
only 2 cables connected to it: the one that goes to le2, and the one
that is connected to a laptop I'm using for test purposes. The
ethernet card is this laptop's ONLY interface (it has no wireless), so
there's no way these packets are getting routed through by some other
means...
sudo tcpdump -nvvvei le0 icmp
08:13:01.713967 0:a:95:79:cb:8a 8:0:20:77:a4:79 0800 98: 192.168.1.9 >
192.168.1.1: icmp: echo request (id:124b seq:7) (ttl 64, id 12065)
08:13:01.714362 8:0:20:77:a4:79 0:a:95:79:cb:8a 0800 98: 192.168.1.1 >
192.168.1.9: icmp: echo reply (id:124b seq:7) (ttl 255, id 6392)
08:13:02.714094 0:a:95:79:cb:8a 8:0:20:77:a4:79 0800 98: 192.168.1.9 >
192.168.1.1: icmp: echo request (id:124b seq:8) (ttl 64, id 12067)
08:13:02.714410 8:0:20:77:a4:79 0:a:95:79:cb:8a 0800 98: 192.168.1.1 >
192.168.1.9: icmp: echo reply (id:124b seq:8) (ttl 255, id 23496)
sudo tcpdump -netttvvv -r /var/log/pflog
Feb 17 08:13:01.714093 rule 3/0(match): pass in on le2: 192.168.1.9 >
192.168.1.1: icmp: echo request (id:124b seq:7) (ttl 64, id 12065)
Feb 17 08:13:01.714291 rule 4/0(match): pass out on le0: 192.168.1.1 >
192.168.1.9: icmp: echo reply (id:124b seq:7) (ttl 255, id 6392)
Feb 17 08:13:02.714210 rule 3/0(match): pass in on le2: 192.168.1.9 >
192.168.1.1: icmp: echo request (id:124b seq:8) (ttl 64, id 12067)
Feb 17 08:13:02.714339 rule 4/0(match): pass out on le0: 192.168.1.1 >
192.168.1.9: icmp: echo reply (id:124b seq:8) (ttl 255, id 23496)
Yeah, a live tcpdump shows the packets on the correct interface. pflog
shows them being caught by rules for the wrong interface.
As for outgoing packets from the bridge itself, they should pass out
through the appropriate interface in both cases, assuming the bridge
has
learned that the destination MAC address is reachable through a
particular interface. When you first ping an unknown destination, the
stack will do an ARP lookup to find the destination MAC address for the
IP address. When the peer replies ARP, the bridge learns which
interface
that MAC address is reachable through, so the first ICMP echo request
will already pass out through the appropriate interface only.
Well, from a live tcpdump, it looks as though it's learned correctly:
$ sudo tcpdump -netttvvvi le0 icmp
tcpdump: listening on le0
Feb 17 08:24:37.390382 8:0:20:77:a4:79 0:a:95:79:cb:8a 0800 98:
192.168.1.1 > 192.168.1.9: icmp: echo request (id:3a42 seq:14) (ttl
255, id 22077)
Feb 17 08:24:37.390795 0:a:95:79:cb:8a 8:0:20:77:a4:79 0800 98:
192.168.1.9 > 192.168.1.1: icmp: echo reply (id:3a42 seq:14) (ttl 64,
id 14048)
Feb 17 08:24:38.400368 8:0:20:77:a4:79 0:a:95:79:cb:8a 0800 98:
192.168.1.1 > 192.168.1.9: icmp: echo request (id:3a42 seq:15) (ttl
255, id 27704)
Feb 17 08:24:38.400775 0:a:95:79:cb:8a 8:0:20:77:a4:79 0800 98:
192.168.1.9 > 192.168.1.1: icmp: echo reply (id:3a42 seq:15) (ttl 64,
id 14053)
Unfortunately:
$ sudo tcpdump -netttvvv -r /var/log/pflog
Feb 17 08:24:37.390305 rule 4/0(match): pass out on le0: 192.168.1.1 >
192.168.1.9: icmp: echo request (id:3a42 seq:14) (ttl 255, id 22077)
Feb 17 08:24:37.390917 rule 3/0(match): pass in on le2: 192.168.1.9 >
192.168.1.1: icmp: echo reply (id:3a42 seq:14) (ttl 64, id 14048)
Feb 17 08:24:38.400290 rule 4/0(match): pass out on le0: 192.168.1.1 >
192.168.1.9: icmp: echo request (id:3a42 seq:15) (ttl 255, id 27704)
Feb 17 08:24:38.400898 rule 3/0(match): pass in on le2: 192.168.1.9 >
192.168.1.1: icmp: echo reply (id:3a42 seq:15) (ttl 64, id 14053)
Jim
