I want to thank the people who have responded recommending authpf. That seems
like a nice add-on, as it will allow me to block all access to the LAN from
wireless clients until they have logged in to the router. It's a trade-off, of
course, as I had not intended to allow wireless clients SSH access to the
router in the first place, but ultimately, it's probably better to initially
"trust" in the security of SSH on OpenBSD than to trust the security of the
services from the LAN. (Of course, I'll have to write a background task for
the wireless clients that uses auth keys and logs them in automatically so the
wireless users don't have to "know" about the authorization step, but...)
As nice as authpf is, it won't solve my initial problem, which was this:
In the simplest terms, I need a way to allow "autodiscovery" mechanisms to work
between the wireless clients and the LAN. This involves such things as
Zeroconf/Rendevous -- broadcast and multicast packets traveling from one subnet
to the other. How do I accomplish that?
My first instinct was to configure the router to know that the subnets were
192.168.1.1/25 and 192.168.1.129/25, and to configure the clients to think that
they were 192.168.1.1/24. However, OpenBSD still failed to forward multicast
packets, and, to make matters worse, would not proxy ARP.
Thus, I presumed bridging le0 and le2 would help. It did, in that it passed
ARP through. But once I brought up the bridge, all of my pf rules started
failing, thinking that traffic that actually came in on le0 was coming in on
le2.
So, my questions, perhaps better stated this time:
1. Is the "/24 /25 network fake" subnetting scheme a filthy hack that will
never work properly?
2. If I configure the LAN and wireless clients to know that they are on
separate subnets, how do I make OpenBSD forward multicast packets between the
two, so that autodiscovery features work across subnets?
3. Even if I don't use it in the end, I'm still curious: why do all of my pf
rules go south when I bring up the bridge? That is, why, after a `brconfig
bridge0 up,` do packets physically arriving on le0 appear to be from le2, and
get blocked by rules for le2?
Thanks,
Jim
-------------- Original message --------------
> Hello,
>
> from my experience I would handle the WLAN as a DMZ with an extra subnet
> and pf-rules. To temporarily change access you could use authpf. That
> works well for me. A bridge is not the right solution for you.
>
> named: you are probably missing an entry for le2 in your configuration
> for named.
>
> regards
>
> Stefan Kell
>
> On Wed, 2 Feb 2005, Jim Fron wrote:
>
> > I have an OpenBSD/Sparc box that I'm using for NAT at home. le0 is
> > the LAN, le1 is the cablemodem.
> >
> > I recently purchased a wireless AP, and would like to add that to
> > the internal network. However, I am paranoid, and, even though I've
> > enabled WPA and hardware address restriction on the AP, I still
> > don't want to just plug it right in to the switch on the LAN. I'd
> > like to be able to restrict access to machines on the LAN to certain
> > services. Also, the OpenBSD box is currently accessible to the LAN
> > in an unrestricted manner -- if anyone has gained physical access to
> > my LAN, well, it's far too late for PF to help :-)
> >
> > I want to restrict access to the wireless AP to DNS and routing
> > services only.
> >
> > <>
> >
> > However, I additionally want things like iTunes autodiscovery (244.x
> > broadcasts) to work between the LAN and AP. I've looked briefly
> > into proxy ARP and mrouted, and it seemed that the way to go about
> > this is really just to bridge le0 and le2, and use pf to restrict as
> > much as possible between the two addresses...
> >
> >
> > # le0 is the internal wired LAN
> > # le1 is the external internet
> > # le2 is the internal wireless AP
> > #
> > # Goals:
> > #
> > # Perform NAT for both internal networks to the outside world
> > # Bridge LAN and wireless AP to provide certain "broadcast-based"
> > # services (Rendezvous/Zeroconf) the impression that they
> > # span the network
> > # Provide DNS service to LAN and wireless
> > # Provide "full" internet functionality to LAN and wireless
> > # Provice "full" access to machines on the wireless from the LAN
> > # Provide "limited" services on LAN machines to wireless clients
> > # Protect the router, LAN, and AP from the internet
> > # Protect the router and LAN from the wireless
> > #
> > # Architecture:
> > #
> > # Sub-net 192.168.1.x, the lower 128 to the LAN, the upper to the
> > # wireless, but configure clients on each with a 255.255.255.0
> > # netmask. This will result in clients that all believe they
> > # have the same network number and broadcast address.
> > #
> > # Bridge wireless and LAN interfaces
> > #
> > # Router provides "default-route" and DNS to each interface on its
> > # respective network number (i.e. 192.168.1.1 and 192.168.1.129)
> > #
> > # /etc/hostname.le0
> > # inet 192.168.1.1 255.255.255.128 192.168.1.255
> > #
> > # /etc/hostname.le1
> > # dhcp NONE NONE NONE
> > #
> > # /etc/hostname.le2
> > # inet 192.168.1.129 255.255.255.128 192.168.1.255
> > #
> > # /etc/bridgename/bridge0
> > # add le0 add le2 up
> >
> > Each internal subnet client has a 255.255.255.0 mask so that their
> > broadcast addresses will be the same, and so that they all think
> > that LAN and wireless AP are one big happy subnet.
> >
> > Thus, until I bring up bridge0 (or some other form of proxy ARP),
> > LAN machines cannot ping AP machines, and vice versa, because
> > OpenBSD does not proxy ARP by default, even though it knows that
> > they are actually subnetted /25.
> >
> > However, when I bring up brige0, everything falls apart. My LAN and
> > AP machines can ping each other, but the LAN can no longer connect
> > to the outside world. Why?...
> >
> > from pflog:
> >
> > [date] rule 13/0(match): block in on le2: 192.168.1.9 > 192.168.1.1:
> > icmp: echo request (id:08ee seq:1) (ttl 64, id 51788)
> >
> > What's the rule blocking this? Well, here are the rules leading up to
> > it:
> >
> > @0 pass out quick on lo0 all
> > @1 pass in quick on lo0 all
> > @2 pass in quick on le0 from to
> > @3 pass in quick on le0 inet from to [EXTERNAL INTERFACE ID
> > REDACTED]
> > @4 pass in quick on le0 from to
> > @5 pass in quick on le0 from to
> > @6 pass in quick on le0 from to
> > @7 block return in log quick on le0 from any to
> > @8 pass in quick on le0 from to any
> > @9 pass in quick on le2 inet proto icmp from to any icmp-type
> > echoreq
> > @10 pass in quick on le2 inet proto icmp from to any icmp-type
> > echorep
> > @11 pass in quick on le2 inet proto icmp from to any icmp-type
> > timex
> > @12 pass in quick on le2 inet proto icmp from to any icmp-type
> > unreach
> > @13 block return in log quick on le2 inet proto icmp all
> >
> > is 192.168.1.1/25
> > is 192.168.1.129/25
> > is { 192.168.1.1, 192.168.1.129 }
> > -- the router IP addresses for le0 and le2, respectively
> > is { 224.0.0.0/4 }
> > is the list if RFC 1819 non-routable IP's, plus 127.0, etc.
> >
> > 192.168.1.9 is connected to le0, the LAN. It's traffic is blocked
> > by a rule for inbound traffic on le2.
> >
> > From this, I deduce that:
> >
> > - the bridging operates before pf sees the traffic
> > - the pass-in rules on le0 are not acting on this ping:
> > @0-3 -- not applicable
> > @4 -- pass in quick on le0 from a LAN address to a router
> address,
> > which allows 192.168.1.9 to ping 192.168.1.1 when
> bridge0
> > is down, is NOT passing this ping.
> > - the traffic from le0 appears to be originating from le2 when
> > bridge0 is up.
> >
> > So, questions:
> >
> > Do I simply need to "swap" my rules so that traffic in on le2 is
> > subject to the rules that used to apply to le0, and vice versa?
> > That is, does the interface for traffic on le0 become le2, and le2
> > become le0 when the bridge is up? This seems to be a bad use of
> > terminology, as the traffic is still physically inbound on le0 and
> > outbound on le2.
> >
> > If not, does bridging the two networks mean that I can't restrict
> > access to the router differently for each interface? That is, do
> > le0 and le2 effectively become "one" interface to pf, and rules that
> > apply to one, apply to the other? If this is the case, why didn't
> > my 'pass in quick on le0' rule work?
> >
> > Is bridging the correct way to go about doing this, or should I stop
> > trying to use bridge0 and use static arp entries to do Proxy ARP and
> > mrouted to forward multicast packets (if indeed those are the correct
> > tools)?
> >
> > Is it true, as I have read, that only inbound rules will work in pf
> > on the bridged interfaces? (Yes, I suppose I could just test this,
> > and probably will, but I'm asking any way.)
> >
> >
> >
> > Also, a BIND question: wireless AP clients are not getting DNS from
> > the router. Doesn't matter if bridge0 is up or down. With bridge0
> > down, machines on the LAN subnet, using 192.168.1.1 as their DNS
> > server are able to get DNS, but AP clients using 192.168.1.129 as
> > their DNS server return "can't find server name for address
> > 192.168.1.129."
> >
> > Where, in the (OBSD 3.5) BIND config files do I need to add an
> > entry (and how) so that it doesn't fail PTR for 192.168.1.129?
> >
> >
> > Thanks,
> > Jim
