Best/simplest/fastest approach for creating "virtual switch" out

[Bonnie Packet]

Shoot. Forgot to mention the most important user advantage of the current s=
etup: since there's only one physical interface on the firewall handling al=
l the (aggregated by the switch) wireless traffic, everyone can use that in=
terface's IP as the same gateway address, no matter which AP they connect t=
o.

Any other solution has to keep that kind of single-address happiness so it'=
s transparent to the users no matter how many APs we have. Figure that's no=
t hard, but necessary to mention. Tanks.

[Karl O. Pinc]

The question is how best to create a "virtual switch" out of em2 and
em3,
I'd love some advice on what the "best" way to accomplish this is.
("Best" =
in my particular case means first, lowest total firewall cpu cost to
route/=
filter; second, lowest PF ruleset complexity; and third, lowest
network tr=
affic [ie, no packets going out ports that will just drop them
anyways]. An=
d I guess fourth, future lexibility in case I need to add a third or
fouth =
damn access point...)

Um, given these requirements, a physical switch would seem to be
optimal. (Of course this is the lazy way out, but
this way there's absolutely no danger of burning out
any precious brain cells from design-fatigue. ;-)




Karl <***@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

[Karl O. Pinc]

Post by Karl O. Pinc
Um, given these requirements, a physical switch would seem to be
optimal. (Of course this is the lazy way out, but
this way there's absolutely no danger of burning out
any precious brain cells from design-fatigue. ;-)

Note that the above reply is a bit snarky. If you want
to avoid extra hardware there's surely a "best" way
to do it. I'm not paying enough attention to think
what it might be. Thinking out loud
(my having forgotten your requirements) is to use
a separate network for your access points. You
could deliver them dhcp, etc. You could frob
the soekris arp table so that the gateway IP
address is reachable by all ports with access
points plugged in. (Something avoided
by bridging....?) Then your pf rules would filter
by network. Of course you'd have to setup
routing tables for the wireless networks
and I can't remember if you're looking for handover
to pass a roaming device from one to the next.

Perhaps not the most general solution.....

All the same, spending the time to engineer
something sounds like it might not be cost effective,
interesting as it may be to find a way to do it
"right".


Karl <***@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

[Karl O. Pinc]

Come to think of it you wouldn't need to frob
the arp tables since I presume the gateway is
all on the soekris. And with proper dhcp
configuration you could just frob the gateway
address supplied to each access point.

Post by Karl O. Pinc

Post by Karl O. Pinc
Um, given these requirements, a physical switch would seem to be
optimal. (Of course this is the lazy way out, but
this way there's absolutely no danger of burning out
any precious brain cells from design-fatigue. ;-)

Note that the above reply is a bit snarky. If you want
to avoid extra hardware there's surely a "best" way
to do it. I'm not paying enough attention to think
what it might be. Thinking out loud
(my having forgotten your requirements) is to use
a separate network for your access points. You
could deliver them dhcp, etc. You could frob
the soekris arp table so that the gateway IP
address is reachable by all ports with access
points plugged in. (Something avoided
by bridging....?) Then your pf rules would filter
by network. Of course you'd have to setup
routing tables for the wireless networks
and I can't remember if you're looking for handover
to pass a roaming device from one to the next.
Perhaps not the most general solution.....
All the same, spending the time to engineer
something sounds like it might not be cost effective,
interesting as it may be to find a way to do it
"right".
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

Karl <***@meme.com>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein

[Daniel Hartmeier]

Yes, bridge between em2 and em3.

Assign the IP (used as gateway by the clients) to bridge0.

You'll have to duplicate the MAC filter rules per interface.

The pf rules need to match both interfaces with 'on { em2 em3 }',
and floating state-policy (default) will simply work. No increase in
complexity there.

If you dislike the syntax there, you can use an interface group, but
it's purely cosmetical.

HTH,
Daniel

[Stuart Henderson]

Post by Daniel Hartmeier
Yes, bridge between em2 and em3.
Assign the IP (used as gateway by the clients) to bridge0.

This isn't possible on OpenBSD, you either need to put the IP on one
real interface (then it may go down if the port is down), or bridge a
vether with it (http://www.openbsd.org/faq/faq6.html#Bridge, but you
will end up with made-up MAC addresses on the wire that way).

iirc NetBSD has changed their bridge(4) to allow an address directly
configured on it.

Post by Daniel Hartmeier
You'll have to duplicate the MAC filter rules per interface.
The pf rules need to match both interfaces with 'on { em2 em3 }',
and floating state-policy (default) will simply work. No increase in
complexity there.
If you dislike the syntax there, you can use an interface group, but
it's purely cosmetical.
HTH,
Daniel