|
OpenBSD Security Functionally paranoid! |
|
Thread Tools | Display Modes |
|
|||
Seperating ALL Wireless traffic from physical LAN with OpenBSD firewall
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 |
|
||||
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.. |
|
|||
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.
|
|
|||
Quote:
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 |
|
||||
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?
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice. |
|
||||
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. |
|
||||
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'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. |
|
|||
Quote:
Quote:
|
|
|||
Quote:
|
|
||||
Quote:
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 |
|
|||
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? |
|
||||
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.
Last edited by jggimi; 24th February 2015 at 12:08 PM. Reason: clarity |
|
||||
Quote:
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).
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice. |
|
||||
Quote:
The security implications when subnetting a broadcast domain are simply:
Last edited by jggimi; 24th February 2015 at 04:21 PM. Reason: clarity, added non-IP datagrams to security list |
|
||||
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).
__________________
Linux/Network-Security Engineer by Profession. OpenBSD user by choice. |
|
|||
Quote:
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 ;-) Last edited by daemonbak; 24th February 2015 at 06:29 PM. Reason: dottin' i's and crossin' t's |
|
||||
Quote:
Quote:
Quote:
Quote:
Last edited by jggimi; 24th February 2015 at 07:20 PM. Reason: typos, and a lot of clarity in the last paragraph. |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Virtual Vs. Physical Interfaces in pf | geppettodivacin | OpenBSD Security | 4 | 4th August 2014 08:25 PM |
Need to move wireless access "inside" the firewall | thefronny | OpenBSD Security | 2 | 13th December 2010 09:01 PM |
OpenBSD firewall with only one physical NIC | idosch | OpenBSD Security | 5 | 25th April 2010 12:11 AM |
Firewall Blocking Good Traffic | plexter | OpenBSD Security | 6 | 8th January 2009 05:58 PM |
import physical freeBSD into VMWARE (ESX) server as a vServer | ccc | FreeBSD General | 6 | 3rd October 2008 07:04 AM |