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

Re: PF, Bridge, and IP on bridged interface [more]



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