I just upgraded to a netgate 4200 from PFsense CE and am setting up & testing the new box. I slapped an extra OpenWRT box behind it to provide wifi with its WAN port plugged into the LAN side of PFsense. Connecting to OpenWRT I can get access to the internet and dig domain names (like google.com), I can't resolve domain names like pfsense.home.arpa .
I've done packet capture with tcpdump and inspected it with wireshark on the wan and br-lan interface and somehow between the wan asking for the record and getting the correct answer back, and that information being pushed into the lan side the answer is stripped off for some reason.
I can get the correct answer if I query the pfsense DNS directly with dig @<dns ip> <domain name>. I have also tried changing the pfsense domain to skeuskaspluyels.com in case home.arpa was running into some special rules, and that didn't change anything.
Any idea why my DNS query is disappearing from the OpenWRT box? Any how I get it working? My attempts at searching for this have returned more general DNS stuff, and I haven't seen an option while poking around in luci that looks like it might be responsible.
network layout and software versions:
The OpenWRT box is a WRT3200ACM running basically default version 24.10.0 on 192.168.2.1/24
The Netgate 4200 is running pfSense plus 24.11, and the port OpenWRT is conecting to is 10.2.0.1/24
Ultimately I want more control of untrusted wireless connections and want to inflict my firewall rules directly on them depending on which wifi they came from.
I plan to take NAT down and just rely on routing tables later on. I thought this would be an easy first step.
Are you referring to Wireless Guests or Wireless IoT devices, or both?
I am not familiar with OpenWrt APs features, but these are usually address via APs supporting Guest SSID and SSID based VLANs linked back to the VLAN on the Router.
Where do you intend for the guest network to be handled? In general, it is considered best practice to do this on your main router, assuming it has the capabilities. Since you're using pfSense, that is a given.
With that in mind, you should setup your networks on the main router and then use the OpenWrt device as a simple bridged AP. With the use of VLANs, it will be possible to have OpenWrt broadcast an SSID for each of your networks.
Thanks for the link, the Guest wi-fi SSID does not create a separate VLAN which is the standard practice across the industry.
Usually establishing a separate SSID based VLAN/Subnet for untrusted IoT Wireless devices is how it is done rather than trying to do this with just Firewall Rules on the pfSense.
I'm hesitant on using vlans I've seen a few people say vlans aren't considered reliable security. This https://en.wikipedia.org/wiki/VLAN_hopping talks about a few ways to mitigate vlan attacks and what to watch out for but I haven't run across stuff claiming to have comprehensive information on how to stop vlan attacks. I also don't know how to check if my set up is hardened against these attacks. If I wanted to check my work I'd probably have to set up a test procedure to inject ethernet frames then capture then along the way to make sure it worked out right.
I'm somewhat familiar with ip networks and routing between them, plus checking my work is easy with nmap. Worst case scenario I write up some routing tables for 10 or so networks manually and setup the firewall rules to enforce my segmentation.
I guess my question is, whats the upsides to vlans when compared to ip networks and firewall rules? The main arguments I see against this might be that layer 3 equipment is less efficient and more costly? To my eye the ease of vetting my work makes this an easy choice.
I found why the DNS queries are disappearing from looking at the dnsmasq man page.
--stop-dns-rebind
Reject (and log) addresses from upstream nameservers which are in the private ranges. This blocks an attack where a browser behind a firewall is used to probe machines on the local network. For IPv6, the private range covers the IPv4-mapped addresses in private space plus all link-local (LL) and site-local (ULA) addresses.
(note this was text was captured after setting root's shell to bash in /etc/passwd and relogging into ssh since ash kept truncating the lines)
Most of the necessary security is in the firewall. Proper configuration of your downstream switches/APs will ensure that VLAN hopping is not an issue.
It is also exceedingly unlikely that an IoT device would be able to VLAN hop. Guests are a different story, but done right, they also won't be able to, either. And then you also need to ask yourself if these are people you want in your home and on your network.
VLANs are common in corporate environments because they allow a lot of control over the behaviors and security of each of the network segments, and also ensure that the network runs efficiently by using smaller broadcast domains.
We can help you with the OpenWrt side. Since your main router is pfsense, you'll need to ask on their support/community channels.
VLANs specifically are a layer 2 concept only. IP networks span L2/L3. Firewall rules apply at L3.
VLANs are the ethernet 'incarnation' of having multiple networks that can run over shared infrastructure (switches, APs, etc.).
The term VLAN is used colloquially to refer to multiple subnets, but really only applies when those are running over a shared ethernet link/hardware. VLANs are made possible by tagging the ethernet frames with a VLAN ID (802.1q tags), and that allows the systems at each end of the link to keep each VLAN separate from the others. However, the whole point of them is because you have different subnets that you are using over the same link, so you need to ensure that they stay separate in terms of the data flow itself (at L2/switching). The firewall is what keeps the networks isolated from each other at L3 (routing).
Simplistically, imagine you own a home with an attached rental unit and you want to offer internet service to those that rent that space. You could get two internet connections and have two entirely separate networks. Or, you can use one internet connection and have the router create two subnets that have access to the internet, but not to each other. Assign them as VLANs over the same ethernet port that connects to the switch or AP, and the next device (switch/AP) will split them back out again into two distinct networks that cannot be "hopped".
They are - and they are not, it's all a question of how you use them.
Giving an untrusted device access to a VLAN trunk and hope that it will ignore everything but the untagged frame is not secure.
VLANs are between your router and your 'trusted' managed switch (and for it to remain trusted, you need it to have continued security support), which executes the policies and directives of your router. VLAN trunk between your router and (one port of) your switch, which then distributes the different VLANs to your access ports (single VLAN, untagged) - your client devices will never see- or deal with VLANs directly, VLANs end on the switch (yes, more sophisticated setups are possible, but those are only for the devices that know VLANs themselves and are reasonably trustworthy).
It's worth building on this point for one other key element... physical security. If you have concerns about VLAN hopping by an adversarial party, they would usually need to have physical access to your hardware (assuming things are otherwise properly configured and secured). As such, if you are in such a threat environment, you need to physically secure your network infrastructure equipment. But in said environment, not using VLANs means that you have even less protection since you can actually use VLANs to ensure that your network infrastructure is managed on a separate and secure VLAN to which a threat actor would not have access unless they gain physical access to your network devices... the ports that would otherwise be physically accessible would belong to a VLAN that (by design) would be considered 'untrusted' (or a lower trust tier) because random people may have access to plug something in. (This doesn't mean that the VLAN construct itself is less secure, it's just a VLAN that contains traffic you may not fully trust, so it would have lower privileges than one you can fully trust).