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

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

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!

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

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

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! :)

  • 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.

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
  • Posts

    • Google Gemini co-lead Noam Shazeer is leaving for OpenAI by Pradeep Viswanathan Noam Shazeer is best known as one of the co-authors of the 2017 “Attention Is All You Need” paper, which introduced the Transformer architecture that now powers most large language models. He also worked on several major Google AI projects, including LaMDA, before leaving the company in 2021 to co-found Character.AI. He also authored the Sparsely-gated Mixture of Experts (2016) paper, which is popular among the AI community. After falling behind OpenAI and Anthropic a couple of years ago, Google brought Shazeer back in 2024 as part of a major deal with Character.AI. Through this deal, along with Noam, several other researchers returned to Google DeepMind. More recently, he was a vice president of engineering at Google and a technical co-lead for Gemini. Today, Noam Shazeer announced on X that he is leaving Google and joining OpenAI. In his post, Shazeer said it was a difficult decision to move on, adding that he was proud of the Google team and what it had built together. OpenAI CEO Sam Altman welcomed the move with a post of his own, saying Shazeer was one of the people he had most wanted to work with since OpenAI’s early days. Google has made strong progress with Gemini over the past year, closing the gap with OpenAI in several areas. But losing Noam Shazeer is a major talent setback for them, especially after bringing him back less than two years ago by spending a fortune. For OpenAI, the hire adds one of the industry’s most experienced language model researchers to a team that is already pushing ahead with ChatGPT, Codex, and its next generation of frontier models.
    • I'm lost too... what did you mean by your first comment then?
    • Couple years ago I got a brand new 4TB Samsung 990 Pro for $250 during Black Friday
    • Thanks
  • Recent Achievements

    • Week One Done
      Classifyskilleducation earned a badge
      Week One Done
    • One Month Later
      eurospharma62 earned a badge
      One Month Later
    • Week One Done
      With What earned a badge
      Week One Done
    • Week One Done
      Harris Gilbert earned a badge
      Week One Done
    • One Month Later
      Vincian earned a badge
      One Month Later
  • Popular Contributors

    1. 1
      +primortal
      542
    2. 2
      +Edouard
      171
    3. 3
      PsYcHoKiLLa
      85
    4. 4
      ATLien_0
      64
    5. 5
      neufuse
      64
  • Tell a friend

    Love Neowin? Tell a friend!