Seperating ALL Wireless traffic from physical LAN with OpenBSD firewall

[daemonbak]

Hi All,

I recently puchased one of the alix boards and an ubiquity AP Pro since both come so highly recommended and must say so for I am happy. However I have a dilemna that I know somewone here must have dealt with. I am currently running Openbsd off a usb drive and using pf as my firewall.

I want to VLAN/seperate/barricade my wireless AP (and all wireless clients) off of my local internet. I would prefer not to use guest access on the AP to accomplish this.

After great deliberation, I realize that my kindle, DS, baby monitor, ipads/iphones and laptop do not need to have accesss to the lan, only web access. The laptop would be the only device that would need lan access on occasion. But when I do need to access the physical lan from the laptop, I have already ran cat5e keystones to every room in the house, so I can just connect to the switch physically and eliminate the need to use the wifi.

This makes it possible (in my mind) to completely seperate the wired lan traffic from the wireless devices/AP. this way if someone compromises my wireless network, they are locked out of my physical lan.

Being that no wireless devices need to be able to communicate with the lan, would using a vlan be the best bet to do this? I know my firewall running obsd pf only has 2 nics. 1 internal to my unmanaged switch and 1 external connected to a p2p microwave transmitter to the ISP. Would I need a third nic to attach the AP to on the firewall itself to have true seperation based on a hardware seperation, or could I just vlan off the ip/mac of the AP and have every device connected to the AP be in that seperate network.

Would this work?

Caveat is that the firewall (alix obesp/pf) will be doing dhcp/dns/nat/etc. So would any divices on that seperate wireless segment still be able to use the DNS and also get an ip from the dhcp server that i have since segemented/vlanned off?

Sorry if this makes little sense. English is improving.

Thanks

[rocket357]

The switch is the biggest concern I can see. If it doesn't handle vlan tagging, this won't work. If it does, read on.

The simplest route is to add your NAT rule to handle !egress for NAT, then have the wireless AP on a separate IP range than the physical NIC. Add pf rules to block traffic from the AP range to the NIC range (no IP on the NIC just yet). Create a vlan on the physical NIC and ensure the NIC is **not** a trunk port, then put an IP from the NIC range on the vlan dev. Last, ensure your local DNS resolver is listening on both the AP ip and the NIC vlan IP, and put two subnet declarations in dhcpd.conf.

You could do full vlan tagging, but I've never tried that on an AP (SEE EDIT BELOW).

In other words:
/etc/hostname.$physnic0:
up

/etc/hostname.vlan2200:
inet 10.0.0.1 255.255.255.0 NONE vlan 2200 vlandev $physnic0

/etc/hostname.$ap0
inet 10.0.1.1 255.255.255.0 NONE

This assumes your lan is 10.0.0.0/24 and your wireless is 10.0.1.0/24. Adjust as needed.

/etc/dhcpd.conf:

  subnet 10.0.0.0 netmask 255.255.255.0 { 
    option domain-name-servers 10.0.0.1;
    option routers 10.0.0.1;
    range 10.0.0.100 10.0.0.250; 
  } 
  subnet 10.0.1.0 netmask 255.255.255.0 { 
    option domain-name-servers 10.0.1.1;
    option routers 10.0.1.1;
    range 10.0.1.100 10.0.1.250; 
  }

DISCLAIMER: written up from memory while at work, based on a significantly more complex configuration on my home network. Verify configuration with man pages!


EDIT: I'm an idiot. Didn't notice that you had a separate AP. This makes it a bit simpler. Create *two* vlans on the physical nic on the internal side, have the AP vlan tag packets with whatever vlan number you choose for wireless, and make sure the physical nic **IS** a trunkport with both vlans allowed. Then put in pf rules to block from vlandev to vlandev. If your AP does DHCP and you're ok with that, use it, otherwise you'll need to turn off dhcp and NAT on the AP so the wireless clients get an IP from the firewall.

[Ajla]

Do you already have the AP? Or will you buy one? If you need to buy one, buy a miniPCI card, pigtail and antenna instead, then use that for the AP on separated IP net from your LAN. That’s the best solution.

But, if you already have your AP and is on very budget to buy a miniPCI card.. here is one solution you can play with. I have run a similar solution for many years ago, but I used freebsd APs and openbsd fw there I had totally control. Consume APs is crap.. So, I don’t know if you can setup this to be secure, it will work.. but the security... You have to test..

But if you can:
1) Buy a miniPCI card, pigtail and antenna and use that. (You can take a old miniPCI card from an old laptop), or
2) Many AP:s (not the cheap one) have VLAN support. Or
3) This experimental virtual solution below

This is one crapy setup, directly of my head.. I haven’t test it, so you have to play with it.
I know that the solution works, with security in mind, but, as I said before, with freebsd APs and openBSD fw there I could block and fix things. You can’t do that with cheap APs. Ok? This is all depending of how good you AP is to block networks segment.


This is NOT a how to..!!

vr0 is your WAN port to you ISP, thin you run DHCP on that.
vr1, put that card to ”up” in the hostname.vr1.

Make hostname.vether0 and put your LAN IP there
inet 192.168.1.1 255.255.255.0 NONE

Make hostname.vether1 and put your AP IP there. BUT use netmask/32
inet 192.168.2.1 255.255.255.255 NONE

Bridge: vether0 vether1 and vr1

rc.conf.local: dhcpd_flags="vether0”

DHCP:
subnet 192.168.1.1 netmask 255.255.255.0 {
option domain-name-servers 192.168.1.1 (or you );
option routers 192.168.1.1;
range 192.168.1.100 192.168.1.200;
}

And put up the fw as a normal router firewall.

On your AP. Put fixed IP address 192.168.2.2, DNS etc. Start DHCP server in it, and here the tricky part (all depending on you AP, if this will work at all). Block all of you internal LAN! Security reason.
In this solution you can’t get access from wifi to LAN, but only if you can block the traffic in the AP. This is not a nice solution, i works, but not nice.. The security.. well... not 100% if I say so...
If I can’t block things in the AP, I would NEVER use this in public!

In my FreeBSD APs (that was in public) I had a netmask /32, pf to block everything on LAN and Wifi LAN, other IPs etc. etc. I block everything! I just pass that the clients was authorized to, and forced all traffic to AP router IP via ssh. In that way, no one on the wifi could get access to LAN, not mix with ssh tunnel, not do any MItM attack on LAN etc. No access at all, just pass through what I decide. Good security, but stupid setup today... But that was what I had to do back then. I was like you no nic available.

=======

But in you case... all depending on you LAN computers. This is maybe the best one, no, the miniPCI card is the best...

But, to have the security there... all depending on your LAN computers is to have on normal LAN, both to LAN and Wifi (same IP segment). Wifi traffic pass as normal, but all your LAN computer use an ssh proxy there all traffic pass through and block everything else. In this way no one on the wifi can get access on your LAN traffic, and they connect normally. This is the was I would go IF; my budget to buy a miniPCI card is not there or my AP can’t handle VLAN. But... in this solution, all your LAN computers have to handel a ssh tunnel to your fw and block everything else. If they can’t... well this is not an option..

[daemonbak]

Originally Posted by Ajla

Do you already have the AP? Or will you buy one? If you need to buy one, buy a miniPCI card, pigtail and antenna instead, then use that for the AP on separated IP net from your LAN. That’s the best solution.

I was going to make it an all in one box but everywhere I looked popular consensus was that buy a purpose built AP instead of making your own. So I bought the soup of the day which seems to be the ubiquity line of AC-Pro dual band.

[daemonbak]

Originally Posted by rocket357

EDIT: I'm an idiot. Didn't notice that you had a separate AP. This makes it a bit simpler. Create *two* vlans on the physical nic on the internal side, have the AP vlan tag packets with whatever vlan number you choose for wireless, and make sure the physical nic **IS** a trunkport with both vlans allowed. Then put in pf rules to block from vlandev to vlandev. If your AP does DHCP and you're ok with that, use it, otherwise you'll need to turn off dhcp and NAT on the AP so the wireless clients get an IP from the firewall.

Just to add info, the unmanaged switch is a gigabit netgear GS switch.

I could do this on the 1 internal nic itself?

This quoted section sounds promising, but i'll be honest, it is a little confusing. Could you go into more detail or point me where to learn how to do this?

Thanks for neing awesome

[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?

[jggimi]

Hello, and welcome. rocket257 echoed what I wanted to post when I saw this thread begin yesterday. Which was, "Do you have a managed switch?"

Unmanaged switches don't have VLAN capability, because the management tools are used to map the VLANs to physical ports. The management interface is where the admin does this. It can be telnet, ssh, http, https, ... and for some low-end product lines, sometimes called "smart" rather than "managed" switches, custom Windows applications from the switch vendor.

The key when shopping for a switch is to look for "802.1Q" among the standards listed on the switch specs list. That's the IEEE standard that won the standards war for VLAN infrastructure.

[jggimi]

I just ordered a low-end managed switch for my home network yesterday.

VLANs will allow me to (initially) reduce consumption of cables, switches, and NICs, and allow increased operational flexibility.

• I will be able to eliminate an on-premise VPN and replace it with a VLAN.
• I'll be able to repurpose those now-unused switches in locations with multiple devices.
• This low-end switch does static link aggregation trunking so I might be able to increase effective bandwidth on my routers by doing simple round-robin aggregation with trunk(4).

I'll have to test trunking carefully. The switch does not claim to be 802.3ad-compliant, which the man page says is necessary for static trunking in the CAVEATS section. However, the vendor's failure to mention 802.3ad explicitly may just be to avoid any misunderstanding. 802.3ad is also the LACP dynamic aggregation trunking standard.

[daemonbak]

Originally Posted by jggimi

I just ordered a low-end managed switch for my home network yesterday.

VLANs will allow me to (initially) reduce consumption of cables, switches, and NICs, and allow increased operational flexibility.

• I will be able to eliminate an on-premise VPN and replace it with a VLAN.
• I'll be able to repurpose those now-unused switches in locations with multiple devices.
• This low-end switch does static link aggregation trunking so I might be able to increase effective bandwidth on my routers by doing simple round-robin aggregation with trunk(4).

I'll have to test trunking carefully. The switch does not claim to be 802.3ad-compliant, which the man page says is necessary for static trunking in the CAVEATS section. However, the vendor's failure to mention 802.3ad explicitly may just be to avoid any misunderstanding. 802.3ad is also the LACP dynamic aggregation trunking standard.

How does this relate to the OP?

Originally Posted by jggimi

Hello, and welcome. rocket257 echoed what I wanted to post when I saw this thread begin yesterday. Which was, "Do you have a managed switch?"

Unmanaged switches don't have VLAN capability, because the management tools are used to map the VLANs to physical ports. The management interface is where the admin does this. It can be telnet, ssh, http, https, ... and for some low-end product lines, sometimes called "smart" rather than "managed" switches, custom Windows applications from the switch vendor.

The key when shopping for a switch is to look for "802.1Q" among the standards listed on the switch specs list. That's the IEEE standard that won the standards war for VLAN infrastructure.

see the original post. it specifically mentions an unmanaged switch

[daemonbak]

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?

you rock. Let me reread this when not under a deadline and get back to you. but this looks like it's gonna have some great info.

[jggimi]

Originally Posted by daemonbak

see the original post. it specifically mentions an unmanaged switch

Thank you, I'd missed that.

Your unmanaged switch may not pass any VLAN tagged frames, depending on what standards it adheres to.

Examples of both possibilities:

https://supportforums.cisco.com/disc...managed-switch

https://supportforums.cisco.com/disc...managed-switch

[azarian]

What about a simpler approach like splitting your c class subnet into two with a /25 network.

Wired lan clients get dhcp in the range of 192.168.0.1 - 192.168.0.126
Wireless clients get dhcp in the range of 192.168.0.129 - 192.168.0.254
Obviously 127 and 255 would be reserved for broadcast

Would that work for his goals?

[jggimi]

If I understood the OP's requirements -- and history shows I don't always -- there is a security requirement. Subnetting a broadcast domain is a logical separation; it can be useful for addressing or policy governance but not for security.

[rocket357]

Originally Posted by azarian

What about a simpler approach like splitting your c class subnet into two with a /25 network.

As already pointed out by jggimi, this is close, but not quite what the OP is asking for. You can definitely do this, but nothing is stopping the subnets from communicating with each other. OP wanted to restrict wireless clients from reaching LAN clients. A vlan solution would take this a step further and introduce the L3 connectivity restriction (connections between subnets would have to occur via a router (i.e. OPs firewall), not a switch), which allows firewall rules to define what (if any) communications are allowed between subnets.

In the near term, the fastest solution is probably to stick a NIC in the firewall and hang the AP off of that, since the OPs switch is not vlan-aware (that has been confirmed, at least).

[jggimi]

Originally Posted by rocket357

...connections between subnets would have to occur via a router ...

That's also true for IP datagrams when subnetting the broadcast domain. Traffic betwen subnets must be routed.

The security implications when subnetting a broadcast domain are simply:

• Broadcast frames are broadcast on all subnets
• Any device can communicate on another subnet by defining an IP address within its range.
• Non-IP traffic can be sent directly between devices.

[rocket357]

Right. Perhaps I didn't word that quite as concisely as I thought I did. There are ways to circumvent the subnetting without vlans, hence, traffic *could* transfer via switching and not routing. With vlans, traffic is *required* to traverse a router. Sorry for any lack of clarity (haven't had my coffee yet heh).

[jggimi]

You've TL;DRed that brilliantly. Now go reduce the blood levels in your caffeine system.

[rocket357]

That's what I love about this forum. You guys really know how to call someone out (politely) on ambiguity =)

[daemonbak]

Originally Posted by azarian

What about a simpler approach like splitting your c class subnet into two with a /25 network.

Wired lan clients get dhcp in the range of 192.168.0.1 - 192.168.0.126
Wireless clients get dhcp in the range of 192.168.0.129 - 192.168.0.254
Obviously 127 and 255 would be reserved for broadcast

Would that work for his goals?

This sounds like a valid workaround, however i still see the issues of being able to talk to each subnet, which won't work with the total separation of the two.

Could I combine the vlan on the one single nic card and use the subnetting azarian suggested?

Another question I am still a little confused about is. Can I really have 2 vlans on that single nic? Would that slow down the network/wan speed or are there any other gotchas that would say, don't do this! Instead just figure out how to sandwitch another nic card in there. That would make 3 nics (1 to cable modem, one to lan side unmanaged switch and one to the AP direct).

Or as described in my first post, is it possible to do it with the vlan on that single nic and subnetting and get great results.

or am I just not getting it?

Thanks

Also, get some coffee rocket357 ;-)

[jggimi]

Originally Posted by daemonbak

Could I combine the vlan on the one single nic card and use the subnetting azarian suggested?

I'm not sure I understand the question.

• NICs that support VLAN tagging will accept the extended Ethernet frames that include tags. These Etehrnet frames are 4 bytes longer than "untagged" Ethernet frames. Those 4 bytes are the additional overhead introduced by VLANs. There's yet another standard for VLANs within VLANs, ("Q-in-Q", 802.1ad) that add a total of 8 bytes to the Ethernet frames.
• Managed switches can be configured to map physical ports to specific VLANs. Ports can be "untagged" and assigned only to a specific VLAN, or they can be "tagged" and support multiple VLANs. Your routers and servers may be connected to the latter, your end-user devices would be connected to the former.
• Unmanaged switches may have problems with tagged packets, as mentioned above. It might not be obvious, because if they do support them, it would be as passthrough devices. The reason they may fail to manage them is that they need to both handle the larger frame size, and they need to recognize the tags in the frame headers.

Another question I am still a little confused about is. Can I really have 2 vlans on that single nic?

On OpenBSD, you can have 256 VLANs per NIC. Your VLAN network may have 4,095 VLANs. That's not always enough, especially for large ISPs, which is why there is Q-in-Q.

Would that slow down the network/wan speed or are there any other gotchas that would say, don't do this! Instead just figure out how to sandwitch another nic card in there. That would make 3 nics (1 to cable modem, one to lan side unmanaged switch and one to the AP direct).

The purpose of VLANs is to provide the equivalent of additional NICs and cables, virtually. The performance overhead is 4 bytes per frame for 802.1Q tagging.

Or as described in my first post, is it possible to do it with the vlan on that single nic and subnetting and get great results.

As with physical NICs, each VLAN is its own broadcast domain and should be assigned to its own unique subnet, unless you are implementing bridge(4) or carp(4) solutions. You might configure multiple subnets on a VLAN as azarian first mentioned; this would typically be due to running out of addresses on a subnet before running out of connectivity requirements there. The same as with any physical LAN.