How to use a consumer wireless router with pfSense
-
Here's a diagram generally describing how to connect a typical consumer wireless router as an access point/switch for use with pfSense.
-
I understand the diagtam. I'm having problems with the config.
-
What config?
-
Set the LAN IP in the AP to a free, static address on your LAN subnet
-
Configure the Wireless LAN in your AP
-
Ensure all services like DNS, DHCP, etc are disabled on your AP (especially DHCP)
-
Plug its LAN port into the LAN port on pfSense.
You can also plug wired devices into the switch on your AP if any.
-
-
I understand the diagtam. I'm having problems with the config.
my ddwrt router is setup for ap. I cant access pfsense is the problem
-
You need to put it on the same subnet as your pfSense LAN interface.
You'll have to provide far more details of exactly how you have it set up (LAN settings in AP, LAN settings on pfSense, DHCP on pfSense etc) for anyone to be able to help you.
-
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.
