Adding Another Interface Mostly Separate From Others?
-
I thought I knew what I was doing until I didn't!
Currently I have WAN0, LAN1, and Crapwork interfaces. WAN0 and LAN1 were initial defaults (I think) where LAN1 is my main network (10.0.0.0/24) with DHCP enabled. Then I enabled another interface "Crapwork" (192.168.0.0/24 also with DHCP) that I put all my IoT devices on. I believe it's set up such that clients have internet access but can't get to LAN1. However, I can access Crapwork from LAN1 as well. So I can access a webcam locally from LAN1 without it going "out" onto net and the "back in" but also access webcam when mobile. Then I added and enabled pfBlockerNG.Now I want to add another interface "BARN" (172.16.0.0/24 with DHCP enabled). I want:
- all clients to have internet
- to be able to access 172.16.0 .2, .3, and .4 from LAN1 for administration purposes (tplink AP, tplink client, and remote wifi AP in barn)
- for all other 172.16.0.X clients to NOT get to LAN1 or Crapwork.
Is this doable? I started making some firewall rules that had an invert on destination networks but it doesn't seem to be working. Also, I don't understand how Crapwork has internet without an any-any-any rule, unless I've mistaken and used the wizard to setup both LAN1 and Crapwork and therefore it's defaulted to having internet? Anyway, below is a big image of firewall rules for the interfaces as well as outbound NAT page. Please let me know if additional info is needed! Thanks!

-
@turbotater19 said in Adding Another Interface Mostly Separate From Others?:
Then I enabled another interface "Crapwork"

Now I want to add another interface "BARN" (172.16.0.0/24 with DHCP enabled). I want:
all clients to have internet
to be able to access 172.16.0 .2, .3, and .4 from LAN1 for administration purposes (tplink AP, tplink client, and remote wifi AP in barn)
for all other 172.16.0.X clients to NOT get to LAN1 or Crapwork.To allow internet access, but no internal I use an alias with all RFC 1918 networks included in pass rules together with invert checked.
So these rules are still save when I add a subnet or change something.My IoT rule and alias look like this:

When you allow only access to internet, you may have to add an additional rule for allowing DNS access to pfSense if you need it.
-
Ok so you're saying if I make an alias of all 3 private IP ranges then just add 1 rule to BARN where source would be... WAN0 and destination RFC1918 and enable invert match? That accomplishes what I want? That seems too easy!
Edit: that didn't seem to work. I've temporarily put my laptop (Windows) on the BARN network and I could map to a shared drive on LAN1 as well as a share on Crapwork... hmm...
-
@turbotater19 said in Adding Another Interface Mostly Separate From Others?:
Ok so you're saying if I make an alias of all 3 private IP ranges then just add 1 rule to BARN where source would be... WAN0 and destination RFC1918 and enable invert match?
No, the source has to be BARN net.
-
@viragomann said in Adding Another Interface Mostly Separate From Others?:
No, the source has to be BARN net.
Thanks, I'll play around with this. So, what does the below do, if anything? For a while I'd presumed it meant that the IoT crap on Crapwork couldn't get to my primary home network... but the more I thing about this and my head hurts... how can that be occuring if I can map to a share on located on Crapwork from my LAN1 computer?

-
@turbotater19
First to know, pfSense controls access on the incoming interface. Responses are permitted automatically. This is called stateful firewall.
So access from LAN to Crapwork is controlled by the rules on LAN tab. If you have a rule on LAN which allow access to any you can access the file share on Crapworks.The rule shown by the screenshot on Crapwork interface:
Since it's a pass rule, it allows any protocol from Crapwork network to any, but LAN1 subnet (since invert is checked). -
I must be an idiot, I can't get this to work and now I'm feeling dumber than when I started! Am I supposed to be rebooting pfSense in between these changes and the computers/servers and APs in between rule changes?
So in Firewall rules, under BARN interface, I deleted everything and added 1 rule that's (from what I can tell) the same as yours that has description "Allow Internet". I have source as "BARN net", any IPv4 protocol, destination is !RFC1918. Under Firewall>Aliases I created an IP alias just as you've got shown. When I apply this, using a laptop on BARN network, I have no internet access. I also can't browse to pfSense at 172.16.0.1. So I have to put the laptop back onto the LAN1 network to get to pfSense at 10.0.0.100.
-
@turbotater19
Did you consider what I’ve written about DNS access in this correlation? -
@viragomann said in Adding Another Interface Mostly Separate From Others?:
@turbotater19
Did you consider what I’ve written about DNS access in this correlation?I did, but didn't know quite how to do that

What I did do was keep experimenting, which isn't a bad (and potentially dangerous!) way to learn, and I think I got it set up and working. At least it seems to be, unless I've created some kind of less-than-robust ruleset? I think I accomplished the same outcome as an accept all with inverted match coupled with a DNS access rule by instead blocking anything to the alias but then allowing everything else? WAN0 and LAN1 rules haven't changed, just the below changes to Crapwork and BARN after making 2 new aliases.
-
@turbotater19
Surely that's a way. But you may have to review your rule set every time you make some network changes as you did lately by adding BARN. Therefore I use the RFC 1918 alias in the rules which covers all my internal network without fail.I did, but didn't know quite how to do that
So you'd better ask for it.
When your rule set only allows access to non RFC 1918, it doesn't allow access to an internal DNS server naturally and you need to add an additional firewall rule for it.
Your internal DNS server might be pfSense itself if you're not oblivious of it. Guess you've also enabled DHCP, hence the DHCP server provides the respective pfSense interface address as DNS server to the devices.So to allow DNS access you need an additional rule to allow TCP/UDP to "This firewall" port 53.
That's the whole magic. -
Alright, here I am again... my above rules for both BARN and Crapwork seemed to be working fine a couple days ago. Block LAN1 and Crapwork on BARN and then on Crapwork, block BARN and LAN1. Then both have under it allow all. This was working a couple days ago; I could access from LAN1 shares on Crapwork, login to the AP on BARN, but devices on Crapwork and BARN couldn't see shares, etc. on LAN1.
Earlier today I tried to get to the web interface of an AP on BARN from LAN1 and it wouldn't load, but previously did. Then this evening, I tried again, and it worked. Not 10 minutes later though, now the web interface won't load.
Then to add more confusion, I've got an AP on the Crapwork and I can consistently access it's web interface from LAN1, never had issues, but the firewall rules are the same for it as BARN? I don't think the issue with the BARN AP's web interface is the device itself because when it works, I can see other devices on BARN from LAN1, but when it's not working, I can't see any devices.
Any ideas?
-
@turbotater19
I don't think that this has anything to do with the pfSense configuration. But you will have to do some investigations to draw down the issue.What you described could indicate an IP address conflict.
If that is the case, pfSense would write some ARP log entries in the system log saying that an IP is moving from one MAC to another one.
So you should search the system log for such ARP entries.If not, sniff the traffic on BARN interface, while you try to access the AP from LAN to see what's going on.
-
No luck so far, searched logs for ARP messages and didn't find anything. Not sure if this is useful but I logged constant pings to the AP on BARN from a laptop on LAN1 for over a day... only to have less than 10 requests fail. So for whatever reason, the issue with connecting to that AP is gone, at least for now. What's more puzzling though is that the entire time, I could never access the web interfaces of either CPE on that BARN network from LAN1. But both CPE web interfaces are accessible any time from the BARN network that they're on. Previously I could access them from LAN1 but now I can't.