If I had to choose between purchasing the OpenWrt One or a Chinese equivalent from AliExpress, I would prefer the OpenWrt One. Although I'm not particularly fond of the manufacturer due to their tendency to frequently release devices and then either barely support or not update the software for them, in this case, it's a good combination of price, hardware, and OpenWrt, with which support is unlikely to be an issue on this device.

Unfortunately, I had already purchased a similar device from AliExpress and spent a lot of time experimenting with firmware. But... Filogic is very fast; it's probably the fastest OpenWrt router I've had.

@elspoon Yes!
I now have my RT-AC86U running in AP mode, and just have an Ethernet cable running right into its WAN port.
In pfsense DHCP settings (https://192.168.50.1/status_dhcp_leases.php) it shows up as 192.168.50.4 (I have it statically mapped) and so going to http://192.168.50.4 gets me to the web interface for the Asus.
Hope this answers your questions!

@Jarhead
Thank you man!
I wasted a lot of time without trying the most banal thing.

Thank you again!

Exactly. To do it with one card you would need to find a card that had two complete sets of hardware on it. I'm not sure such a card exists but if it does it's probably far far more expensive. Hence my '100x' guess. Regular single radio cards can be had for <$5.

@NollipfSense I bet in the future we will dock only our smartphones to a KDM at work and will no longer use WiFi. A VM for work boots like Windows 11 and undock and it shuts down. If you go to a different company they delete the VM.

The wireless interface type in pfSense is for wifi hardware in pfSense itself which is not what you have.

Your access point should simply be connected to one of the LAN ports in the 2100. Devices that connect to the AP will just get an IP from pfSense in the LAN subnet. Later you may want to move those to a new subnet so you can filter between them but I would only attempt that after first making it work as part of LAN.

The pfSense WAN should be set to PPPoE but that can only work if the upstream device is bridging the PPPoE connection correctly.

Steve

@stephenw10 yes we can agree the user can configure it wrong all over. Again, an administrator might fat finger a large static DHCP list with a couple entries thus causing hostname mix ups. That for one would be very hard to pinpoint. Moreover, we know the amount of hours system administrators work. It's a lot of hours. This would make PfSense have a ease of use software functionality built in. I assumed that if pfSense allowed multiple duplicate entries, it was done for a situation when two devices need to be swapped in and out and need the same IP address, in this mindset PfSense should still log the correct hostnames. Again, if that was the reason for PfSense allowing the GUI duplicate entries.

Weird thing to research, but the hostnames mixup was what I was after and or why
PfSense would allow the duplicate entries in the first place. Let's agree admins have monster static dhcp lists that are updated and changed all the time within a secure setting. This situation would want controls in place for hostnames. Finally, logs for the hostnames could get bonkered up and with a monster list and that would be hard to track down why hostnames are wrong. We know PfSense now has experimental layer 2 Ethernet filtering.

Excelllent. I added a feature request for it: https://redmine.pfsense.org/issues/14050

@stephenw10 Yes.

@johnpoz haha yes I did use the wrong name I have a Netgear switch and a netgate router. Thanks for your suggestion. I will have to research some more ! I think my issue is my lack of research. I might have gotten into something that was beyond my understanding but I do think the pf software is quite a sophisticated piece to everything. Having a parameter firewall, VPN, Snort, Proxies etc it was definitely worth the purchase. I will have to learn more about networking haha. Cheers.

You guys all scare the hell out of me.
I've loads of APs without any passwords at all.

And at home neither, as I haven't seen yet any rabbits with some BYOD ....

@alroute said in 3rd Party Hardware Request:

I'm guessing Netgate doesn't want to price the 2100 down at home user prices because it might lose small business revenue and the same for access points which I'm guessing are universal to all.

Perhaps you can't simply make it any cheaper without loosing money? Because all electronics prices have gone through the roof and nothing got cheaper at all? There's a reason why consumer/SOHO electronics is cheap, while more flexible hardware and software is not. That's not something to do with "they don't want to make it cheaper" or "they don't like their software running on toasters". It's just that no one wants to pay for that. You can't just throw the software on cheap SOHO hardware and hope it will work just because "it's also an ARM SOC/CPU". There are vastly different ARM SOCs and they have licenses etc. for accessing their tools and drivers etc. Why is Netgate running espressobin-like hardware on those SG1100-3100? Because it's mostly the same SOC and was (guessing) relatively easy to adapt FreeBSDs ARM branch on it.
We can see how "identical normal x86/64 hardware" runs every day. They aren't the same just because they may have the same NIC and CPU in it. Developing on different hardware is far more complex than "just throw it on and have a look at it". Otherwise one could simple extract the installer from e.g. a SG1100 and throw it on a Raspi4 (won't work - different ARM SOC) or on a smartphone perhaps? Those are ARM, too? Nope. Not that easy. And the menhours that go into such things as developing and testing on new hardware is what makes things time consuming and expensive to ensure the stuff is actually running quite nicely when you try to install/update it. Add to that, that many hardware vendors for WiFi, SOCs (Quallcom for ARM etc.) like to have "binary blobs" in their drivers that may only work on Linux or have problems to get them to run on FreeBSD - or even incompatible licenses to BSD/Apache Licenses? Those are just the problems on top of it.

Have you seen 08/15 SOHO hardware with more then 1-2y firmware support? I found them very rare. Mostly the have have a few updates and are then abandoned for the next bigger better version. Also because of ever evolving HW standards of WiFi and such, most SOHO routers tend to get switched out around 2ys. Firewall hardware normally lasts way longer than that in my experience in our company (not Netgate BTW).

@alroute said in 3rd Party Hardware Request:

I noted from the Netgate Website that youa re intending to provide support for Pfsense to be used on 3rd party routers.

Actually don't know where you found that. I only know of "supporting 3rd party hardware" and with that they are only talking about compatible (x64 Intel/amd) 3rd party hardware router boxes or barebones that you can buy/build yourself. I found nowhere they state, that they plan to run on 3rd party routers as an alternative firmware like OpenWRT or DD-WRT or Tomato. That's - AFAIK - far outside the project scope.

Cheers
\jens

Technically you could do it by running pfSense as a virtual machine in Windows using hyper-V or VBox etc. But pfSense is a complete operating system, it cannot run as an application on your desktop. It expects to be running on it's own dedicated hardware but running virtualised can also work.

Steve

@wmheath586 you might also want to drill down further to the MAC address tables in your router. If you are using a managed switch you should be able to telnet into your router and inspect the MAC address table. This would be relevant if you are running multiple VMs and have left the MAC addresses at their defaults.

@lucas-0 Yep. That is how I have my rules ordered.

The x3 block rules for "HiddenWasp Linux Malware" will never be reached because they are below the two allow all rules (Default allow LAN to any rules) for IPv4 and IPv6. Same for the NORDVPN_VPNV4 rule. It will never be reached because LAN traffic will take the "Default allow LAN to any rules).

Rules are processed in a top to bottom order (with an exception of floating rules). I will not get into detail. But this is a good read to explain how to order rules.

If the pfsense box has at least x3 ports it could be set up as follows:

port1: WAN
port2: LAN --> Switch1
port3: LAN_IOT --> Switch2

This would give the same result as using VLANs to separate LAN from LAN_IOT. If LAN devices need to access LAN_IOT devices then a firewall rule will need to be put into place. Depending on how the IOT device is configured a NAT Outbound rule may also need to be put into place if the IOT device does not respond to IPs out of its IP address range.

For me, I just set up a generic NAT Outbound rule (allow LAN to LAN_IOT). The NAT rule does not do anything until there is a firewall rule setup which also allows (LAN.deviceX to LAN_IOT.deviceY). Don't be afraid to put pfsense into hybrid outbound NAT mode. It just moves the auto-generated rules to the bottom and allows the creation of custom rules.

But as always; before any changes are made to the pfsense box make sure there is recent backup configuration easily available for restoring in the event a mistake is made during the learning process.

Good luck and have fun!

@Parakinesis

or Ruckus and UBNT (in this order) 😉