Firewall rules to further restrict traffic?


Recommended Posts

So these are the rules I've implemented for my IoT VLAN network in pfSense. I wonder if I should restrict the outbound protocols, or just leave it on "Any", since there are other blocks in place?

 

image.thumb.png.77536c44b6fe2929204cef9052b617e5.png

Link to comment
Share on other sites

Those rules don't make a lot of sense without more context.

 

For starters I take it your your clients on this network are not using pfsense for dns or time?  Oh wait your rules are only TCP?  What exactly are you blocking in Management blocks, since I take it they are not on the firewall, since your blocking everything to firewall below that rule?  But only tcp?

 

! rules or Not rules can be problematic if your using VIPs?  Like pfblocker?  What exactly is in your Non_IOT alias?

 

Here is example rules that I like to use that are restrictive..

rules.thumb.jpg.922065585a2fafa9c8ab99cfe3d94cb6.jpg

 

The rules are labeled to exactly what they do.. But quickly described.

1) allow to ping pfsense IP in this network to test for connectivity

2) Allow dns to pfsense IP in this network

3) Allow ntp to pfsense IP in this network

4) Block all other access to ANY IP on the firewall - this would be any other lan side IP, or even the public wan IP.  And if that changes - still block per the built in alias

5) Block all access to any rfc1918 addresses, my other local networks. (10/8, 192.168/16, 172.16/12) This works no matter how many other vlans/networks I might add in the future on any rfc1918 space.

6) Allow access to anything else - ie the internet on any port.

 

I use reject vs just blocked, since this will send icmp response to client saying hey you can not do that.. So client doesn't have to send retrans trying to get an answer.  This is something you would do locally, but never on a wan rule, etc..  It should help clients from having to wait for a timeout trying to do something and let them know right away - hey you can not go there..

  • Like 2
Link to comment
Share on other sites

Sorry for the long delay in replying, my whole network was down at home due to renovation. Anyway I'm back up again!

 

Clients on IoT network reach out to Cloudflare for DNS. Didn't think of NTP actually! Maybe they are syncing with the UniFi controller for it? Reason I blocked only TCP is because I thought those are web access only, 80 and 443. Though now that you mention this specifically, I realise it is actually wrong. Forgive my ignorance! 😔

 

The Management Blocks alias has the access IP's of my virtualisation host XEN server, UniFi Controller, Pi-Hole and OpenMediaVault. Sorry, I don't understand what you mean by them not being on the firewall though. TCP only again because of my reasoning above.

 

I am using pfBlockerNG, but only for GeoIP blocking. The DNS filtering is disabled as I have Pi-Hole handling that. The Non_IoT alias has all my other networks - Trusted, Guest, WiFi, Servers and Pi-Hole. Pi-Hole is on its own VLAN based on your advice to achieve a proper DNS redirect for devices that have hardcoded DNS servers. Curious, what problems can it cause? Everything seems to be working here. Or maybe there is something already wrong, and I just don't know about it!

Link to comment
Share on other sites

I also have this rule setup for redirecting DNS to my Pi-Hole. How do I specify a DNS rule for my restricted networks keeping this in mind?

 

dnsredirect.thumb.png.31241632bfa0ec71c8775bcbbcdfc10a.png

Link to comment
Share on other sites

So your blocking iot devices from talking to 80/443 on anywhere - not just the firewall?  So what are they doing on the internet if they can not use 80/443 - your management ports?  Guess they could use quic which is over udp..

 

What is on your firewall on 10443, that you don't want them to talk to?  What about ssh to the public IP? 

 

I gave you an example how it is normally done, Not with those ! rules... Which if your using vips with pfblocker could not work how you think they are going to work.

 

Wouldn't an aliases of your local networks be better called just local_nets, or how about you just use all rfc1918 space?

 

No your rules are not how I would do them at all, and are not very intuitive to look at..   That redirected rule is only on your lan, so it has zero to do on your iot vlan..

 

 

  • Like 1
Link to comment
Share on other sites

Oh ok, so by blocking TCP connections to pfSense, I am actually blocking these devices completely from using 80 and 443? Didn't realise that! But all the devices connect and work just fine, remotely as well. So they have found a way out! :blink:

 

With my limited knowledge or ignorance, I just wanted to prevent access to the login page of pfSense, that is why I put in that rule. :blush:

So that means the Management Block rules are all wrong? Or just specifying a rule like yours called "Block all other access pfSense IPS" takes care of it? But your rule specifies "This Firewall" only. Sorry, this is a bit confusing to me.

 

I don't allow access to SSH by itself remotely. I VPN in if I need to.

 

The only problem (that I know of) that I faced with pfBlocker was that enabling another instance of Pi-Hole exclusively for the IoT network caused connection issues. Disabling pfBlocker seemed to solve them, so I just removed Pi-Hole and continued with pfBlocker. Probably caused other issues too (and still does), but I have no idea! :blush:

 

The reason I setup individual aliases like Non_IoT was because I specified all other local networks in them, excluding the one I wanted to prevent blocking. So Non_IoT for example has LAN, Servers, Restricted and Guests in it. Non_Servers has all networks except Servers. And so on. So you're saying I can just have one alias for local networks for each individual network? How do I do this?

 

Oh ok, I thought as much the DNS redirect rule shouldn't affect other networks, just wanted to confirm! :)

Link to comment
Share on other sites

  • 11 months later...

This topic was automatically locked because it did not receive any replies for a year. If you want to have this topic reopened

  • please contact any staff moderator or
  • report the first post of the topic with the reason why it should be reopened.

Thank you.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now