Essentially, I'm sharing an internet connection with a neighbor in my apartment building, hence this (stupid) setup. The PFsense firewall must remain in place.
How can I configure the OpenWRT AP device to be a dumb AP... in reverse from the provided OpenWRT documentation? I want the WAN port on my PFsense device to receive DHCP leases (over ethernet) from the Bell Home Hub (over 5G WiFi).
I've spent hours trying to figure it out, but can't. I am endlessly getting confused by various OpenWRT configuration settings (devices vs interfaces vs bridges vs firewall zones vs firewall rules), and while I've learned a lot, I still can't get this to work.
To me this might be easiest, if you think that your home hub would act like hotel's WiFi server, and your openwrt would just be a WiFi client connecting to it, and then provides Lan for pfsense etc. inner network.
You could try using travelmate package in openwrt. It eases the config of having upstream connection via WiFi.
(You may need to go into double NAT, so that the inner Lan is in a different subnet than the home hub.)
The wiki page from psherman shows the similar manual config.
What @hnyman suggested may be more practical... it is far easier to configure a simple routed network with a wifi upstream than it is to setup relayd. You'll also probably get better performance and reliability.
That said, once you're in a routing setup, you might consider if OpenWrt (in routing mode) would be sufficient for your needs. Obviously it depends on what your pfsense system is doing, and you may still opt to keep it in the system, but OpenWrt's routing and firewall functionally should be on-par in most respects.
Sorry for the delayed response @psherman & @hnyman , didn't expect such a quick response.
What would be the difference between the TravelMate vs RelayD package? Why would some go for RelayD, if it has worse performance + reliability? I know very little about OpenWRT's available packages, but I see that there A LOT of them.
I'm running PFBlockerNG, UnBound, a bunch of static DHCP leases, various scripts running on pfsense, and probably some other things that I'm forgetting, hence wanting to just leave it as-is. I know I could probably run PiHole or set a lot of that up on OpenWRT, but it would be very time consuming. Plus I have upnp disabled, so AFAIK, a double-nat shouldn't effect me too much.
With the TravelMate package, can I avoid having any NAT done within OpenWRT? I already have OpenWRT converting the 5G WiFi 192.168.2.0/24 range to an ethernet 192.168.5.0/24 range.
I'd very much prefer PFsense to simply get a DHCP lease from the 192.168.2.0/24 range (from the Bell Home Hub).
Travel mate is designed to handle the road-warrior use case where you might be visiting different hotels/cafes/etc which all have unique wifi networks for guests to use... the idea is that you can have Travelmate manage a list of possible upstream networks and gracefully fail if none is available (this was specifically an issue with single radio devices bceause cannot bring up their own AP until they have established the STA (client) mode connection first). It can also handle automatically enabling VPNs and the like. In the travelmate use scenario, you'll likely be using the device as a router (i.e. a different lan subnet) to provide a layer of security between your downstream devices and the upstream network.
By contrast, relayd is a method of extending an existing network with a wifi uplink and a wifi and/or ethernet downlink. This will result in the downstream devices being on the same subnet as the upstream network. So this is purely an extender method and does not do any routing or firewall stuff. Think of it as a range extender for your home.
To extend an existing wifi network, there are three ways to do it: 802.11s (mesh), WDS/4addr, or relayd. The first two will only typically work if they are within the same firmware ecosystem because of differences in implementation so that each vendor/firmware can add its own special sauce. relayd is more universal in that you don't need an OpenWrt device upstream to make it work. However, relayd is a bit of a hack -- the reason for this stems back to the fact that the basic wifi standards didn't really include a means of providing a wifi (STA mode) -to- [wifi (AP mode) and/or ethernet] bridge. So clever people figured out how to make it work, but it's always been a hack for this reason.
No. Travelmate doesn't have anything to do with NAT, but it is usually used in the context of a NAT/routed setup.
If you want to avoid NAT, your upstream router needs to have the ability to set static routes. I am almost 100% certain that the Bell Home Hub doesn't have the ability to do this (I know it's not available in the HH4000).
That said, I'm not sure that an extra NAT layer really matters. Yes, far from ideal, but your HH upstream already sets up NAT. Then your PFSense box is doing another layer. So if you had a 3rd NAT (between them), it wouldn't really change anything.
If you want to avoid NAT, your upstream router needs to have the ability to set static routes. I am almost 100% certain that the Bell Home Hub doesn't have the ability to do this (I know it's not available in the HH4000).
Can you clarify this a tiny bit, just because I'm not familiar with RelayD yet. By static routes, do you simply mean static IP's (either done manually on the OpenWRT device, or telling the DHCP server to always assign a certain IP to a device/mac address)?
Additionally, looking at the available packages, I see both "luci-proto-relay" and "RelayD" available. The earlier-provided documentation discusses the use of bot luci-proto-relay & RelayD. Are they the same?
Static routes are how you can achieve symmetric routing and disable NAT masquerading (there are other reasons static routes might be useful, too). This basically tells the router where it can find a network that it isn't otherwise aware exists.
For example, let's say I have
main router with a lan subnet of 192.168.5.0/24
secondary router with lan address 192.168.14.0/24
The secondary router has address 192.168.5.23 on the main network.
If a host on 192.168.5.0/24 sends traffic to 192.168.14.0/24, the traffic will go to the main router first, and the main router will attempt to send it where it needs to go. However, the main router isn't aware of 192.168.14.0/24, so it will say "no route exists" and drop the traffic.
A static route (in the main router) would be 192.168.14.0/24 via 192.168.5.23 which means "if you see traffic destined for 192.168.14.0/24, send it to 192.168.5.23 and that router will send it to the actual destination host."
relayd is the underlying package that does the work, whereas luci-proto-relayd is the 'front end' allowing you to configure relayd with the LuCI web interface.
I'm not familiar with these concepts of static routes but if my understanding is correct, RelayD is unlikely to work with the Bell Home Hub, due to (the likely) missing configuration options for static routes?
Honestly really thought it would be easy to simply place the OpenWRT into a somewhat-transparent mode, simply passing all traffic from the Bell Home Hub to PFsense (including DHCP leases) but this doesn't seem to be the case, for what I want to accomplish?
Relayd doesn't require static routes because it results in the downstream network being an extension of the upstream network. It's a universal solution for extending wifi or making a wifi-to-ethernet bridge.
With wifi uplink, it's not easy, but that's not the fault of OpenWrt, it's related to the way that wifi was standardized. All of the purpose-built wifi extenders or wifi-to-ethernet bridge devices use some variant of relayd.... some of them work pretty well right out of the box, others don't.
Oh shoot, okay. Looking back, it looks like the static routes part was in reference to the TravelMate package, is that correct?
Sorry okay, I'll be looking into RelayD again! Sorry for getting confused. Definitely not an expert on OpenWRT nor on networking (hence coming here to ask questions), but I appreciate your patience and clarifying things for me!
Yes, but travelmate isn't actually the part that would need static routes... it was about the idea of avoiding another layer of NAT masquerading. The NAT masquerading issue applies only if you're using a routed approach (with or without actually using travelmate), but it does not apply when using relayd.
