Messages

Thanks coffeecup25.That is what I thought. I will do more research and give it another try. Thankfully OPNsense has Snapshots so that when I break it I can get it back to functioning without having to swap out the box while I nuke and pave and try again from scratch.

I have tried PFsense and OpenWRT on the Sophos box but I found the UI of OPNsense to be best out of the 3. OpenWRT is what I used for the first 4 months after buying the Sophos box but when I broke OpenWRT and I could not get it to install correctly a second time I thought it was time to try something else.

Once you get it figured out, I think you will be very happy with OPNsense and Adguard Home. I am. The initial config of Adguard Home was a little frustrating in getting everything properly synchronized. Sorting through all the differences is the worst part. Adguard Home is far more configurable than Unbound ad blocking and far easier to manage block list exceptions.

As I look back on it, the config was actually pretty simple. If it feels like you are jumping through strange hoops, start over. As I wrote before, the initial install screen is the most important. You only get one try and then have to go back to AdguardHome.yaml and reboot to fix what you need fixed. It's not difficult but it is annoying.

I haven't used OPNsense snapshots, so good luck there. I'm old fashioned and prefer good backups, but snapshots can certainly be better in the right circumstances.

I used pfSense CE for many years. Their update cycle was developing issues and becoming unreliable. OPNsense updates give me more confidence. My needs are simple so if development froze today, I would still remain happy. Nobody else would, I'm sure.

Openwrt on X86 looks like a bear to install. Good on you for getting it to work even once.

nero355,

Not to be argumentative but I have been using 5353 for a long time without ill effects. Some 'tutorials' also use it.

But I can see your point.

Ehm ....

I have no idea why a port forward is in the mix. I don't use it and never have on either OPNsense or pfSense.  As I said , not problems, ever.

If you ask someone how to create a BSD VLAN, you also get an unlimited number of examples. All are official and insulting to notice everyone does it a little differently. Or at least explains it differently.  I decided to use a 2nd subnet instead, which nobody in the forums had any idea how to install. (Very easy BTW, much much easier than a BSD VLAN). My point is that the person who gets it to work first becomes the expert once they carve it into stone. Then others who followed the instructions dig in their heels and refuse to consider other points of view. Don't even get me started on the pointed debates about using Unbound vs external DNS servers, even when the only option for the particular situation calls for an external DNS server.

In fact, OPNsense updates require an external DNS server. I'm using unbound, but discovered no repositories can be found without an external server listed on the initial setup page. Even some OPNsense official documentation somewhere mentioned those DNS servers are the ones OPNsense uses for updates.(Yes, I know, someone will add a post that condescendingly tell me they can do it just fine.)

To repeat, sometimes there is only one way to do something, but with BSD software there are often lots of ways.

This isn't the answer you want to read, but it's the best one so far.

There is no one place to look to install Adguard Home into OPNsense. Everyone does it differently. There are a lot of similarities among install techniques, but none are identical. Also, you do not need a port forward. I can't even see how that idea got into the mix in the first place. It is probably a kluge that somehow worked so it became 'official'.

Google how to install Adguard Home into both OPNsense and pfSense. Find several articles for each then roll up your sleeves and compare and contrast what you read.

Yes, you can install Adguard Home into pfSense. The article from India is what I used for the basics of that. You won't need it for that aspect.  My installed config was different though.

If you want to use Unbound, associate it with Not port 53. I used 5353 but anything will work. Inside Adguard Home Settings where it asks for DNS servers, enter 192.168.1.1:5353 (or whatever your router IP is). Don't load up outside servers. They may work, but you won't be using Unbound. If you are using IPV6 you are on your own.

Also, get familiar with WINSCP and find AdguardHome.yaml as you will need a copy of it for your backup. And you will need to make config edits there because Adguard Home only gives you one try on the initial install to get some very important things right.

Now, try to have fun.

Adguard Home can be updated from the Dashboard whenever a new version is advertised on it. It takes a few seconds.

+1 when moving from ISC DHCP to KEA DHCP and Importing/Exporting the Static DHCP Mappings but it did not took me a hour to figure it out :)

I've been using KEA for a long time with all devices mapped statically. Sorry you had so many problems with it. The import / export feature with KEA is amazing. It's the best part of it IMO.

I updated to 26.1_4 with no issues. Very smooth. I exported my current rules, all 6 or so of them, into a csv. I tried to upload the csv into the new screen. Yes, I imported them in the right place. Yes I clicked 'Apply'. Yes, the csv had records.

Nothing happened. I did it 2x. Nothing happened. I rebooted. Nothing happened.

My rules are default LAN rules, default LAN rules copied to IOT and edited. Then rules in both to restrict LAN from IOT and vice versa.

Whatever other rules that might be there are the ones that came from the base install. No idea about them.

So how is this thing supposed to work as a simple import doesn't appear to do anything?

Happily, I tried the upgrade and migration on a backup router.

EDIT:

Like the other post, I found the check box.

I don't mean to be rude, but somebody needs to work on that screen a little more. It was already checked so why would I check a box that alread has a check mark???

I wasted an hour on this.

[in place of]

petski,

You are taking a simple situation and overcomplicating it by a lot.

That switch is overkill for what you have described. A $15 TP-Link dumb switch would have been better. Do a factory reset on the Cisco switch to turn it back into a dumb switch and leave it as a dumb switch. Do not do DHCP on it. Ever.

Use Kea DHCP and Unbound DNS. Google for how to set up Unbound. Unbound will be a fallback DNS server. KEA is fairly simple to use now that it does not have hidden boxes for simple config options.

Use the DNS override box on KEA to access Pihole. Find a box associated with your LAN interface where it asks for DNS servers. It will probably have 192.168.1.1 if 192.168.1.1 is your router address. Put the static address for pihole in that box in place of 192.168.1.1.

I am assuming all devices are on the same LAN. If you have more than one subnet, then I don't know if KEA can point to a pihole server on a different home subnet. Probably not. Look into Adguard Home instead, but you will have to edit AdguardHome.yaml to add all the local subnets it needs to serve.

I had planned to end my time here so you kids have an exclusive playground. But, you got me. Hopefully nobody else will draw me back again.

I just watched all the packets that escaped from your network and now I know all your secrets. I guess you were right. I can't get into your system since it uses non-routable addresses. But somehow your frames and packets (inside joke) found their way to me of all people.

Seriously. Reddit has normal people on the OPNsense forum. What's wrong with you and the other little princes?

Why not explain how your 192.168.x.x or whatever gets out and gets into trouble? Without using NAT and SPI, which is the traditional way traffic goes from a network to a destination and finds it's way back. NAT and SPI are actual firewalls. Look up NAT / SPI and your hesitation and apprehensions about Internet Leakage might lessen.

Mull this over .... why does the real pro or the prince need to write a rule to prevent Internet Leakage, while almost nobody has even heard of this terrible situation? Why isn't it an OPNsense default? Millions of routers are out there without any owner or manufacturer awareness. This should become yours and that other's guy's crusade to wake everyone up. Hopefully, this will be my last post here.

At least you will still have the newbies to impress.

meyergru, the football keeps on being moved a bit at a time. Eventually you will sneak it across the goal if nobody notices the sneak.

Shut Down the app - check

Block specific addresses from the lan- check

Conflating RFC1918 with errant devices - check

Internet Leakage - still an unsolved mystery

Everything else is only sneaking the football down the pitch. Why do you old pros always do that? All it does is chase people away. OK, you remain one of the princes here who apparently could use a refresher course in networking fundamental along with making an effort to stop changing the subject a little at a time so you are never wrong. That's annoying and not uncommon. I doubt you're fooling anyone except the other princes.  Don't argue with me like I'm your wife.

Now, fix his problem. Don't walk away after all this. I mean fix it, not offer some incomplete techno-babble.

Here's an overkill solution. Build a new subnet using an open port. (Please dear god ignore the VLANs. they aren't needed and won't add value.)  Hang a spare access point off of it or off of a simple switch attached to it. Put the bad devices on that subnet. Block the subnet from the WAN. Weirdly complicated and massive overkill, but fixed. My favorite solution is simply to unplug it.

meyergru, said: "If you do not want that, you can block specific source LAN IPs to access the internet (=destination !RFC1918), which is what the OP tried to do. If he failed in that, there must be something wrong with his rules, the order of processing or anything."

The rule blocks a nonroutable ip address. A pointless exercise.

The rest of what you wrote makes it appear you are unclear about what I wrote as it does not correlate to what I said, and not for the first time.

This time really leaving the chat, which has also become a pointless exercise.

[do]

RFC1918 IPs do go out over the internet if they are on your LAN and a NAT rule exists via the WAN IP - this is the default for any OpnSense installation as for LAN, there is a default "allow any -> any" rule and an automatic NAT rule for the WAN. If this were not so, you would not have internet access from your LAN.

And you still do not get what the firewall rule of the OP does: It is an "in" rule on (presumably) the LAN interface, which essentially blocks all outbound access for the cameras (as source) - the ONLY reason that in the destination, RFC1918 is exempted is to still allow local access (by virtue of the (presumably) existing "allow any" rule that comes further down in the list, but is not shown).

Stop the presses. OPNsense by default allows all local traffic to escape to the internet for all to see. Only a select few have firewall rules to prevent this.

That's what you just wrote. If it's true then I will immediately replace my Chinese router pcs with  my spare TP-Link ER605-V2 and be safe once again. Please confirm.

Quick question: How does the internet differentiate my 192.168.1.xxx from yours or anyone else's? There must be millions to choose from all across the world with the same local IP address? Or is my leaked data just floating in the ozone? Again - look up NAT and SPI, they work hand in glove to separate the local network from the outside world. Except possibly in OPNsense, according to you.

but trouble is my rule doesnt work and i dont understand why it doesnt work, i dont get how its going out even tho ive created a rule for it, do i need to create an outbound NAT rule aswell?

I just explained why the rule does not work. More than once. What are you really asking?

coffeecup25 exits the group chat.

[If]

@coffecup25: Your cameras and selected IoT devices may do that. Where does the OP say he uses exactly those devices?

The OP expressed concern and wanted to make sure his cameras do not connect outside - and he successfully achieved that goal by his firewall rule.

Besides that: If you can use your camera app from outside of your network, I can absolutely, 100% assure you that the cameras connect outside without your app started or active or you having asked for a cloud connection - if not for a standing connection, your app could not reach your cameras inside your home network in the first place. So, who would then tell your cameras to connect outside? See? BTW: This was exactly the case with my friend's UpCams.

Please note - I do not say YOUR cameras do this. I only say, SOME (if not most) do, so read the OP's request again in that light.

As RFC1918 states, non-routable addresses do not go out over the internet, so there's no need to block them from the WAN. I covered this in detail above. Anyone who wants to do a little intro to networking research can easily confirm this.

Agree nothing can connect to the internet without a standing connection. Also my point above in excruciating detail.

meyergru,

No, I called every shot correctly.

My TAPO doorbell and light bulbs and various cameras all use the TAPO App to communicate with TP-Link. They do not have minds of their own like little AI Terminators. I even have them on their own subnet (no VLANs anywhere). Very private on my network. If I want them to stop communicating with TP-Link, then I disconnect them from my local lan and they go silent. They will also probably stop working. My thermostat, on the same IOT subnet, works without a connection to the home office. When it is connected, I can change the temperature while never leaving my recliner - from anywhere in the world. the TP-Link TAPO app allows world wide access. So there's that.

Moral and absolute rule every time - turn off the app if you don't want it to go out over the internet. The little terminators may fume but a doorbell can't cause much harm without an internet or lan connection.

Putting non trusted apps or non-trusted people on separate networks, or separate broadcast domains using a VLAN, has ABSOLUTELY NOTHING to do with RFC1918.

NAT and SPI don't works as you think they do. Seriously, look it up. you will be embarrassed. But, as I said, the only people who don't make mistakes are the people who don't do anything. So good for you for putting yourself out there. So many 'experts' only lurk behind the scene and undermine those who do things.

So, back to the original  poster. Shut down the app and you will end your concerns automatically. or block the ip assigned from DHCP from outgoing traffic. But first assign a fixed local ip otherwise it may get a new number after the lease expires.

but surely there on my LAN and using those ips i gave to you guys ie 10.100.1.249 and 250 as i can see the leases on my dhcp?

DHCP deals with local addressing. Of course you can see all the devices on your network on DHCP. What is your specific concern?

Just a thought, but the internet has numerous free intro to networking courses and texts available. All of your concerns are included in the early chapters.

Also, networking is networking. Different companies sometimes implement the universal concepts differently. Cisco and OPNsense and TP-Link, and all the other big companies all do things 'their way' but all use the same networking concepts. DHCP is the same everywhere, but each router company may implement it differently if they consider it appropriate.