Wireless card compatibility with pfsense



  • I want to build a pfsense box and use it to isolate a wired and wireless network.  I was thinking of this mobo and wifi card:

    Intel Ultimate N 633ANHMW (http://www.newegg.com/Product/Product.aspx?Item=N82E16833106062)
    Intel DN2800MT Mini-ITX (http://www.mini-box.com/Intel-DN2800MT-Mini-ITX-Motherboard)

    I was wondering (since I'm not the smartest on wireless cards) if pfsense will be able to use this card as the wireless network for other devices?  Or do I need some specific kind of card for that?



  • You might find the Intel D2500CCE more suitable in that it has two Intel NICs on board. However you probably need to use a recent pfSense 2.1 snapshot build to get a workable video console. This is discussed in a number of posts in the pfSense forums.

    I presume you want pfSense to act as an Access Point in which case you should not use the Intel card since the FreeBSD man page (http://www.freebsd.org/cgi/man.cgi?query=iwn&apropos=0&sektion=0&manpath=FreeBSD+8.3-RELEASE+and+Ports&arch=default&format=html ) doesn't say it supports AP mode. You should probably choose an Atheros based card but I am unable to recommend a particular card since the one I use has been unavailable retail for some time. PCI Atheros cards generally support AP mode and it seems that most of the variants which support 802.11n will operate in 802.11G compatible mode in pfSense. (pfSense doesn't yet support 802.11n.)



  • Does software AP mode count?

    PCE-N53 (http://www.asus.com/Networks/Wireless_Adapters/PCEN53/)



  • @legit:

    Does software AP mode count?

    Only if its software for the appropriate version of FreeBSD (the operating system on which pfSense is built).

    @legit:

    PCE-N53 (http://www.asus.com/Networks/Wireless_Adapters/PCEN53/)

    That is a PCI Express card which is incompatible with PCI slots. (I think your preferred motherboard has a PCI slot but I haven't checked against the specifications.)

    The TP-Link WN321G is a USB WiFi which supports AP mode in pfSense. I don't have experience with it but the Tenda W311U which has given me satisfactory performance allegedly uses the same chipset as the WN321G. The WN321G can be purchased for the local equivalent of US$10 from the nearby retail computer parts shop.

    Others might be able to give you more specific recommendations for a PCI (or PCI Express) card.



  • Is there a list of pfsense supported wireless cards somewhere (can't find it on the wiki)?



  • How about this guy:

    http://www.sparklan.com/product.php?func=view&prod_id=184

    It has an atheros AR9382 chipset.



  • Nevermind that doesn't support WPA2, this seems harder than it should be. Am I missing something?





  • The general consensus around here seems to be that an ethernet connected access point is a better choice than an internal card. It's certainly easier, is fully portable, it doesn't depend on any drivers.



  • I guess if I really want to have a fully featured wireless access point the way to go would be to do a multi-RJ-45 port system and buy a wireless bridge/AP as a standalone.  Not really what I wanted; but, at least that way it is upgradable and I get all the wireless features I want out of the box without having to wait for bsd driver/wireless technology support.



  • @gderf:

    The general consensus around here seems to be that an ethernet connected access point is a better choice than an internal card. It's certainly easier, is fully portable, it doesn't depend on any drivers.

    Heh, came to the same conclusion and posted before I read your response. Thanks for the help!



  • @gderf:

    The general consensus around here seems to be that an ethernet connected access point is a better choice than an internal card. It's certainly easier, is fully portable, it doesn't depend on any drivers.

    I agree, but troubleshooting facilities in some external APs may well be very limited compared to what is in pfSense.

    @legit:

    Nevermind that doesn't support WPA2, this seems harder than it should be. Am I missing something?

    Strange! the page you linked to says WEP, WPA, WPA2



  • This is just as a home router, so I'm not too concerned about troubleshooting facilities.



  • Here is a list of PCI and CardBus hardware which FreeBSD 8.1 RELEASE and Ports state they support by the ath_hal module.
    http://www.freebsd.org/cgi/man.cgi?query=ath_hal&apropos=0&sektion=0&manpath=FreeBSD+8.1-RELEASE+and+Ports&arch=default&format=html

    Here is a list of PCI and CardBus hardware which FreeBSD 8.3 RELEASE and Ports state they support by the ath_hal module.
    http://www.freebsd.org/cgi/man.cgi?query=ath_hal&apropos=0&sektion=0&manpath=FreeBSD+8.3-RELEASE+and+Ports&arch=default&format=html

    I think pfsense.org should add the first link above in the hardware section somewhere.

    Why Atheros? It is the most common wireless chips found in wireless equipment.

    I had one of these 10 Years ago Netgear WG511T LMAO ….. Wish I still had it. Keep in mind even though it is listed, it still doesn't mean you wont have some problems.

    NO PCI-E cards listed …..

    One thing I have learned you have to Accept, is dealing with the fact open source can be 3 to 4 years behind in certain aspects of the hardware. This is the case here!

    Edit: Corrected Link


  • Netgate Administrator

    Atheros is simply the best supported wireless hardware in FreeBSD. Largely that is due to the efforts of one man: http://wiki.freebsd.org/AdrianChadd  though I'm sure he'd be the first to tell you there were many contributions from others.

    I agree that there will always be some delay getting hardware support in FOSS that is usually because manufacturers do not provide drivers or datasheets. Thus much has to be worked out from the ground up.
    FreeBSD is usually somewhat behind Linux in this respect simply because there are less people hacking on stuff for it. Lastly pfSense is behind FreeBSD as applying the various patches and scripts to a FreeBSD release takes time and effort.

    Thus pfSense 2.0.1 is built on FreeBSD 8.1 which was released in July 2010 but hardware support was likely finalised sometime before that and even at that time it will have been behind whatever Linux was supporting. So, yes, 3 years is probably a good guess.  ;)

    Steve

    P.S. Your first link above is wrong. Fixed.


  • Rebel Alliance Developer Netgate

    There may not be pci-e cards, but there are mini-pci-e cards and you can find mini-pci-e to pci-e adapters around.

    Also the drivers in 2.1-BETA are much newer and more likely to support recent cards, especially from Atheros.



  • @gderf:

    The general consensus around here seems to be that an ethernet connected access point is a better choice than an internal card. It's certainly easier, is fully portable, it doesn't depend on any drivers.

    I couldn't agree more.  pfSense has a lot of tasty eggs in its basket, and the fact that the wireless functionality exists is what makes the product so awesome.  But, in this case, I will go with an external wireless AP.

    Some main challenges remain with finding an ideal external AP, though.  For me:

    (1) find one that doles out DHCP settings to its wireless clients, where it doesn't insist that the AP itself be the default gateway, or at least give you the option to point somewhere else, (such as your pfSense box), for your default gateway.  The AP would obviously be bridged to LAN subnet of your pfSense box.

    (2) find one that supports simultaneous dual band, and still does (1)

    (3) find one that supports MSSID (I need lots of SSIDs (multiple guest-type access solutions per physical AP), with each SSID associated with a distinct VLAN & subnet), as well as does (1) as well as (2)

    (4) find one supports the wireless AC standard (OK, this is truly a nice to have, but… I still want it).  I will even risk the fact that AC is not yet ratified.

    These features all exist on various AP platforms, but I have yet to find ONE that supports ALL of these in one unit.  I have been looking at http://www.newegg.com/Product/Product.aspx?Item=N82E16833168130 , but have yet to confirm it can do (1).

    … hope I didn't take us too far off on a tangent here...

    NT SUX


  • Banned

    1, 2/ You do NOT want DHCP running on your AP, so just scratch it.



  • @doktornotor:

    1, 2/ You do NOT want DHCP running on your AP, so just scratch it.

    So… how would I send DHCP data to the wireless clients connecting to the AP?  Are are you referring to the actual IP of the AP - that would be static.  To be clear, it's the DHCP daemon I am referring to - not the client - on the AP itself.


  • Banned

    Uhm, you enable DHCP server on pfSense.



  • @doktornotor:

    Uhm, you enable DHCP server on pfSense.

    I have a feeling you're trying to be helpful, rather than condescending.

    I also have a requirement for MSSID, with each instance mapped to a unique VLAN/subnet.    Not sure pfSense can accommodate this with regard to DHCP.

    So, to simplify things, perhaps this would call for a solution where the AP itself is also a router (rather than a bridge), with its WAN NIC on the pfSense LAN subnet.  An extra hop is added, I  guess, but it's internal, so it should be negligible.  This would resolve the DHCP "issue".

    Thanks for your input.


  • Banned

    Rather depends on the AP wifi and firmware. I can imagine this would be doable with some Atheros-based box and DD-WRT.


  • Netgate Administrator

    @ntsux:

    I also have a requirement for MSSID, with each instance mapped to a unique VLAN/subnet.    Not sure pfSense can accommodate this with regard to DHCP.

    Why not? The usual arrangement here would be to have the access point mapping each virtual access point to a different VLAN with all the VLANs trunked to pfSense. pfSense is then configured with those VLANs such that each VAP appears to be a separate interface complete with DHCP server, firewall rules etc.

    Steve



  • @stephenw10:

    @ntsux:

    I also have a requirement for MSSID, with each instance mapped to a unique VLAN/subnet.    Not sure pfSense can accommodate this with regard to DHCP.

    Why not? The usual arrangement here would be to have the access point mapping each virtual access point to a different VLAN with all the VLANs trunked to pfSense. pfSense is then configured with those VLANs such that each VAP appears to be a separate interface complete with DHCP server, firewall rules etc.

    Steve

    OK great - then I have some reading to do.  Not quite sure where the .1q trunks are set up in pfsense, and how they correlate to the number of sub-interfaces I will require on the physical NIC (on the pfsense box) associated with the  AP.



  • @ntsux:

    Not quite sure where the .1q trunks are set up in pfsense,

    Nowhere as such. If you are using a particular physical interface as a "trunk", go to Interfaces -> (assign), click on the VLANs tab, click on "+" to create a VLAN you wish to add and fill in the details, click Save then click on the Interface assignments tab and click "+" to add the VLAN to the pfSense pool of interfaces. Your VLAN interface will now have an OPTx style name (OPT1, OPT2, etc) and you then go to Interfaces -> OPTx and fill in the details such as IP address etc then go to Firewall -> Rules to add rules to control traffic and then (optionally) go to Services -> DHCP Server to configure DHCP services on the VLAN.



  • @wallabybob:

    @ntsux:

    Not quite sure where the .1q trunks are set up in pfsense,

    Nowhere as such. If you are using a particular physical interface as a "trunk", go to Interfaces -> (assign), click on the VLANs tab, click on "+" to create a VLAN you wish to add and fill in the details, click Save then click on the Interface assignments tab and click "+" to add the VLAN to the pfSense pool of interfaces. Your VLAN interface will now have an OPTx style name (OPT1, OPT2, etc) and you then go to Interfaces -> OPTx and fill in the details such as IP address etc then go to Firewall -> Rules to add rules to control traffic and then (optionally) go to Services -> DHCP Server to configure DHCP services on the VLAN.

    If I am understanding you correctly, this method sounds analogous to a method for creating a sub-interface on the physical NIC in other products.  Therefore, I should create each additional "Optx" interface that I require, ensure that the MAC matches the original physical NIC, and map the isolated VLANs (and the subnets contained within each VLAN) to what I have created in my AP via the trunk.  And then create a suitable policy/rule set for each one I create.

    Having the ability to run a distinct DCHP daemon per sub-interface is an awesome option!

    Thanks very much! Can't wait to try it out!


  • Netgate Administrator

    Sounds like you have the idea.  Have fun! :)

    Steve


Log in to reply