Originally Posted by rocket357
I was thinking about writing up a blog post on it, but I haven't had time yet.
Think of vlans like this:
Regular tcp packet header layout (ipv4):
[ethernet][ip][tcp]
The ethernet frame contains the MAC of the destination system. The IP header contains the src/dst ip addresses, and the tcp header contains the sequence numbers, tcp flags, etc...
The first thing a machine does before it sends a packet to an IP is check if the IP is within its subnet (i.e. the local machine is 192.168.1.34 (in 192.168.1.0/24, for instance), and it's sending to 192.168.1.127. That falls within the "local" subnet, so it arps "who has 192.168.1.127?" and (hopefully) gets a response from 192.168.1.127 "I'm at $MAC_ADDR". It then builds an ethernet frame that has the MAC of the local machine containing an ip header that has 192.168.1.127. The frame would hit the switch, and the switch would relay the frame to the port that has MAC.
If instead it were sending to, say, 172.16.12.45, it would realize that IP does not fall within the local subnet, so it would construct the ethernet frame with its *gateways* MAC, but the IP header would have dest ip 172.16.12.45 (and, if required, it would arp for the gateways MAC first). The switch would forward the frame to the port of the gateway MAC, and the gateway would check its routing table for the network that 172.16.12.45 resides in, and forward it there. If the gateway does not have a route specifically for that network, it forwards the packet it its upstream default gateway (if configured).
Ok, so basically a vlan is a number between 1 and 4096 that is embedded in the ethernet header. A vlan-aware switch will *only* send vlan tagged frames to ports that allow that vlan (in essence dividing the switch up into "virtual LANs"). vlans can be distributed across multiple switches, too. If a switch is *not* vlan-aware, it will broadcast packets if it does not have a usable arp entry for the MAC of the packet, which defeats the purpose of vlans.
So, to construct a usable config, you *must* have a vlan-aware switch. Once you do, you can configure the vlan info on the switch (i.e. what ports can carry what vlan-tagged packets). You can also configure trunk ports, which are ports that can carry multiple vlans. On the OpenBSD side, you can bring up an interface that is plugged into a trunk port on the switch, then create /etc/hostname.vlan# interfaces (per above) and "sh /etc/netstart vlan#" to bring up the vlan interfaces. Anything sent from OpenBSD to the switch via a vlan interface will be tagged with the vlan number of the vlan interface it went out on (and vice-versa, anything incoming will be picked up by the vlan interface for the matching vlan number). So you can literally tcpdump -i vlan2100 and *only* see vlan 2100 traffic =)
Once that's done, you simply have to configure another switch port for the wireless's vlan number, and plug the AP into that. Any of your local machines can be plugged into ports that are configured for your LAN vlan. The AP packets will have to go from the AP to the switch then up to the firewall, where you could (if you wanted) put firewall rules in place to allow the traffic to go to the LAN vlan. If that were the case, the packet would go back out on the LAN vlan interface to the switch, and from there it would only be able to go out on LAN vlan tagged ports (i.e. not the AP's port).
Any of this can be NAT'd to the internet, but as long as you have something like "block on vlan$LAN from any $wireless_subnet", the wireless would not be able to touch the LAN subnet.
Does that help?
|