How to use a consumer wireless router with pfSense
-
Why not set it to wireless bridge and let pfsense do the routing?
-
That's just it. The "Router" setting is, apparently, the "Bridge" setting. So say the ddwrt dudes. Clear as mud.
-
:D In Netgear removing the mark in firewall function makes it a bridge…. Doesnt say anything in the manual about that at all :D
-
If you should happen to have a cheap wireless router and you can not install ddwrt. A quick fix is to Turn off DHCP on the wireless router and not use the wan interface on the wireless router. Connect the wireless router to pfsense using the LAN ports.
-
some wireless routers offer CLI and you could conf it as DHCP relay (Thompson/Alcatel Speedtouches), pfSense itself would provide DHCP server. WLAN router's own static IP may belong into same subnet. Just leave it outside DHCP range. WLAN router LAN ports connect to the pfSense LAN port.
-
Technically speaking APs don't have to be in the same subnet as pfsense. APs are not routers when bridging the wireless to the wired network. They are switches => layer 2 traffic gets processed through them. they will forward everything to pfsense, even when not in the same subnet. It's a clever way to hide parts of the network, from the network (remember that security through obscurity I've been screaming about?).
Typically when you can't access pfsense from the wireless part of the network, you forgot to add an allow rule for it (you shouldn't add it btw, always use wired connections for administering gateways).
The only downside to this is that since the AP can't see the "actual" network, it can't update itself. Whether or not a consumer AP gets updates a year down the line is a different story.
-
@jflsakfja:
Technically speaking APs don't have to be in the same subnet as pfsense. APs are not routers when bridging the wireless to the wired network. They are switches => layer 2 traffic gets processed through them. they will forward everything to pfsense, even when not in the same subnet. It's a clever way to hide parts of the network, from the network (remember that security through obscurity I've been screaming about?).
What are you talking about? Bridges don't "forward" traffic anywhere. They participate in the connected subnet.
-
@jflsakfja:
Technically speaking APs don't have to be in the same subnet as pfsense. APs are not routers when bridging the wireless to the wired network. They are switches => layer 2 traffic gets processed through them. they will forward everything to pfsense, even when not in the same subnet. It's a clever way to hide parts of the network, from the network (remember that security through obscurity I've been screaming about?).
What are you talking about? Bridges don't "forward" traffic anywhere. They participate in the connected subnet.
I'm talking about APs (access points), bridging their wireless section (the little (usually) black or white antenna, technically operating around 2.4GHz, or could be 5Ghz) to their wired section (the vast majority of them being ethernet. Since there is only one ethernet, there is no need to define it).
Subnets have no place next to bridges. Bridges are layer 2 traffic. Subnets are layer 3 traffic.
A wireless AP having an address of 192.168.1.1 WILL (the baseball bat is right here for anyone who says otherwise) forward traffic from a wireless client having an IP of 192.168.2.2 to the wired gateway with an IP of 192.168.2.1. The same trick can be used to forward IPv6 traffic on a switch/wireless AP not "technically" supporting IPv6.
-
No, they won't. They will, on behalf of the wireless client, put an arp request, for example, out on the ethernet for the default gateway and, if one is received, bridge it to the client. It doesn't forward traffic anywhere. It's a bridge.
You are correct that the IP of the config interface for most APs has nothing to do with the IPs of the clients.
-
If you bridge the AP, then it will be PFsense handling the DHCP requests, not the AP.
It just acts as a wireless network card attached to the pfsense.
-
Forward doesn't mean "make a decision based on the destination".
Forward means "pick a packet on this interface, and put it on that interface". In the context of a bridge, that means simply letting the packet flow through, not stopping it.
And they will not put an arp request out on behalf of the client. The client will put out that arp request and the bridge will forward the request to all its bridged interfaces. Remember, the bridge has nothing to do with layer 3 traffic.
-
Regardless of terminology, you're clouding the issue instead of providing clarity. Taking something simple and making it more complicated for those whom this post is supposed to help - the typical double-NATters. These users are no less secure having their wireless device's management interface accessible on the LAN since before they used pfSense it was probably open to wireless users anyway.
In a proper config, the AP's management interface would be listening on a management VLAN.
-
The issue as I understood it: How to use an AP with pfsense.
My recommendation: Use it as a bridge (if it's a consumer wifi router it should have the functionality) or use a plain AP which already does away with the routing part. Also provided the extra tip of putting it on a different subnet than the LAN (which is where presumably your management interface is). Provided hint at a common mistake (forgetting to add interface rules for the wireless interface) as help in identifying why it doesn't work.
Something was posted that wasn't entirely correct. I corrected it.
I don't see where I did something wrong to be honest.
-
They are switches => layer 2 traffic gets processed through them. they will forward everything to pfsense, even when not in the same subnet.
I guess I am taking issue with "forwarding everything to pfSense" as misleading. Nothing is forwarded "to pfSense." It's just tossed out on the segment. It's up to the client device to ARP for pfSense's MAC address and send traffic to the proper IP/MAC address.
Anyway, we're both talking about exactly the same thing. Disable all router functionality in the wireless device and plug your wireless router's LAN port into your LAN and leave its WAN port disconnected.
-
Here's a diagram generally describing how to connect a typical consumer wireless router as an access point/switch for use with pfSense.
Be careful with this. My DIR-601 was hooked up this way, and I had issues for weeks with tons of packet loss etc. over Ethernet (Access point switch port was run into my Cisco catalyst 2954). It wasn't until I did a debug arp on the switch that I noticed the problem: frames sent into the access point were getting reflected right back into the Cisco switch, unmodified, causing the switch to flipflop the ARP assignment between two ports.
-
Did you make a loop by connecting two cables from the switch to the AP or was there another bridge device joined to wi-fi and also connected to wired?
Layer 2 loops break networks.
This is the proper way to do this absent a real access point.
-
Did you make a loop by connecting two cables from the switch to the AP or was there another bridge device joined to wi-fi and also connected to wired?
Layer 2 loops break networks.
This is the proper way to do this absent a real access point.
That was my first thought. Actually it threw me off pretty good, I was going all over the place looking for a loop but couldn't find one. The access point only had one wire plugged into it, and there was no bridge device on the wifi. I plugged the cord into the WAN side of the access point and that immediately fixed the problem. Plugging it back into the switch port, the problem came back. I even replaced the wire entirely, thinking there was a short of some kind causing some kind of backscatter, nope, same problem.
-
That AP is broken then and has nothing to do with this config.
-
Anyway, we're both talking about exactly the same thing. Disable all router functionality in the wireless device and plug your wireless router's LAN port into your LAN and leave its WAN port disconnected.
This is my procedure - I start with the AP disconnected from the network and perform a Factory Reset of the AP - this way I have a known configuration to start.
Then I use a laptop and connect to the AP via a LAN port for the initial AP configuration. I use a standard browser without any plugins like No-Script running so that nothing gets in the way of the setup. Depending on the AP you may be able to log straight in, or you may have to accept a license agreement first. I always skip any setup wizards and set up the AP manually.
Once you are logged into the AP you can connect the AP WAN to the internet and check for any firmware updates - I try to do this once a year and I've just finished running this process on two of my three AP's at home. Once you have the AP updated then disconnect the AP WAN cable.
Open the AP administration/manual setup and configure the Wireless LAN in your AP with SSID and password.
Ensure that all services except DHCP - like DNS, NAT, etc are disabled on your AP. In general, if the AP offers a service then you probably want to disable it, but make sure that changing the LAN DHCP settings is the last thing that you do. It's a good idea to check that the settings that you enter on any of the AP configuration pages are actually saved before you move on to the next step. Make sure that you go through all the setup screens.
Finally - and this is always the last step - set the LAN IP in the AP to an unused, static address on your LAN subnet outside the PfSense DHCP range so that you will be able to admin the AP from this address afterwards. Now disable DCHP on the LAN and save the configuration - the AP will disconnect from your laptop.
Unplug the laptop and connect the AP LAN port to the LAN port on PfSense. Leave the AP WAN port disconnected!
You should now have Wi-Fi access on the PfSense LAN and you should be able to admin the AP via the static address that you assigned for any fine-tuning. If you can't reach the AP via the assigned address then you've done something wrong - the safest thing is to do a factory reset and start again.
Finally, from a security point of view:
-
Always change the admin password on the AP.
-
Always disable Wi-Fi Protected setup.
-
Never configure the AP to use WPA or TKIP.
-
Always use strong passwords on your AP.
There's no sense in making it easy to hack.
-
-
That all looks really solid. Thanks.
