Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - TheAutomationGuy

#1
25.7, 25.10 Series / Re: NAT breaks Windows update
January 21, 2026, 05:27:59 PM
Not sure if you are still experiencing a problem, but you'll have to do better at explaining your situation.

EVERY device using an IPv4 address behind a firewall/router is NATTED.  The major function of a router is to handle NAT.  If you are having problems with devices behind your firewall/router communicating with "the internet", it is due to a configuration issue.  Hopefully we can help solve it, but you'll need to give us a lot more information before anyone can start to guess what the problem might be.
#2
What is the IP address that your computer is assigned?  Is it is something like 169.254.x.x?  That would indicate a connection problem between the computer and firewall where the computer failed to get a DHCP address because of this connection problem.  I would suggest that you connect the computer directly to the LAN port of the firewall.  If you are already doing this, change the network cable to a known working cable.  If that still fails, then it is likely a hardware or driver problem with the LAN port on the firewall.

If you can access OPNsense's  command line interface, you should be able to confirm what your LAN subnet is set to.  It's possible that you originally had changed it to something other than the stock configuration and when you reset the box it set the LAN subnet back to the stock configuration (which is 192.168.1.0/24 with the firewall getting the 192.168.1.1 address).  You can always reassign the LAN interface to another physical port (if available), choose a different LAN subnet address if desired, and also make sure that DHCP is turned on for that LAN subnet.
#3
General Discussion / Re: block cameras to internet
December 23, 2025, 07:50:32 PM
Duplicate post removed.....
#4
General Discussion / Re: block cameras to internet
December 23, 2025, 07:26:46 PM
Quote from: coffeecup25 on December 20, 2025, 03:01:22 AMMull 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?
The fact that you even ask that question proves you have zero idea what we are talking about here and can only point at what other people do or say to support your "theories" - which turn out aren't based on actual personal experience other than internet search results you have read through.

That rule isn't a default rule on ANY firewall/router device because that rule stops all devices on that network subnet from accessing the internet.  That is NOT what people want to do by default.  By default, people want to access the internet from their local network.

Therefore, by default most (I dare say all, but there probably is some strange outlier device that acts differently) firewalls/routers will by default block all traffic initiated outside of the local network (ie the internet) from getting into the local network and it will by default allow all traffic that is initiated on the local network to exit your local network and travel to it's final destination (ie go to the internet).  However the default rules are not going to work in every single situation, and therefore users can add or modify their rules to change the default behavior.

In this particular use case for example, the OP does not want their cameras initiating communication with non-local servers via code built into their firmware code (which does happen and therefore it is completely reasonable to want to block this traffic).  Therefore adding this rule - while only useful in specific use cases where you want to BLOCK devices on your network from being able to communicate with devices outside of your local network (ie the "internet") -  to the "CCTV VLAN" network is exactly what needs to happen. Meanwhile the LAN and other VLANs without this rule will still be able to initiate communication with devices outside of the local network like normal.

Again, I would implore you to stop posting/arguing points about concepts you clearly don't fully understand. 
#5
General Discussion / Re: block cameras to internet
December 19, 2025, 10:17:01 PM
Quote from: TheAutomationGuy on December 19, 2025, 10:10:19 PM
Quote from: coffeecup25 on December 17, 2025, 03:29:50 PMThere's a good chance I am missing the point entirely, but you may be doing something unnecessary.

The RFC1918 addresses are non-routable by design. This system allows you, me and the man behind the tree to all have 192.168.1.1/24 subnets without crashing into each other. The three ranges normally are associated with various sized networks, with the 192.168.x.x ranges for home networks by convention. Nothing prevents a home network from using one of the other ranges.

Find out the app that's sending the videos outside of your home and shut it down.

https://netbeez.net/blog/rfc1918/

I googled this. It seems to be a good definition.

Did you even bother reading the link you posted?  It clearly says,
Quote"These IP addresses compose the majority private networks, which are networks not available, or reachable, from the Internet. The reason these hosts are not reachable from the Internet is due to a fundamental requirement: each host must possess a unique IP address. RFC1918 removes this requirement. Common RFC 1918 addresses, like 192.168.1.1, are available in multiple networks without causing any disruption. The key requirement is that they stay within the boundaries of a network."

You do understand the difference between incoming and outgoing data, correct?  Because this entire conversation has been about data traveling TO THE INTERNET from the local network (via the camera itself), not data FROM THE INTERNET trying to connect to to the camera......

The article goes on to say,
Quote"To isolate RFC1918 address from the Internet, network administrators configure their border routers to discard IP packets with private addresses.  As a result, IP packets carrying private addresses can only flow within internal, or private, networks.

How do network administrators configure their border router to discard UP packets with private addresses?  WITH THE EXACT RULE that meyermu suggested to the OP  and you have continually tried to say that it is not necessary.  Your own link contradicts you assumptions and says that it IS necessary and a normal rule for network administrators to add to their routers.

It's fine to be ignorant on a variety of topics (no one knows everything), but it's not OK when you start trying to teach and correct others (who are 100% correct BTW) when you don't understand the material yourself.  Therefore I would suggest that you stop posting in this thread until you learn a little bit more about how data travels through a network.
#6
General Discussion / Re: block cameras to internet
December 19, 2025, 10:10:19 PM
Quote from: coffeecup25 on December 17, 2025, 03:29:50 PMThere's a good chance I am missing the point entirely, but you may be doing something unnecessary.

The RFC1918 addresses are non-routable by design. This system allows you, me and the man behind the tree to all have 192.168.1.1/24 subnets without crashing into each other. The three ranges normally are associated with various sized networks, with the 192.168.x.x ranges for home networks by convention. Nothing prevents a home network from using one of the other ranges.

Find out the app that's sending the videos outside of your home and shut it down.

https://netbeez.net/blog/rfc1918/

I googled this. It seems to be a good definition.

Did you even bother reading the link you posted?  It clearly says,
Quote"These IP addresses compose the majority private networks, which are networks not available, or reachable, from the Internet. The reason these hosts are not reachable from the Internet is due to a fundamental requirement: each host must possess a unique IP address. RFC1918 removes this requirement. Common RFC 1918 addresses, like 192.168.1.1, are available in multiple networks without causing any disruption. The key requirement is that they stay within the boundaries of a network."

You do understand the difference between incoming and outgoing data, correct?  Because this entire conversation has been about data traveling TO THE INTERNET from the local network (via the camera itself), not data FROM THE INTERNET trying to connect to to the camera......

The article goes on to say,
Quote"To isolate RFC1918 address from the Internet, network administrators configure their border routers to discard IP packets with private addresses.  As a result, IP packets carrying private addresses can only flow within internal, or private, networks.
which is exactly the rule that meyergru suggested in his post and you have continually tried to say that it is not necessary.  Your own link contradicts you assumptions and says that it IS necessary and a normal rule for network administrators to add to their routers.

It's fine to be ignorant on a variety of topics (no one knows everything), but it's not OK when you start trying to teach and correct others (who are 100% correct BTW) when you don't understand the material yourself.  Therefore I would suggest that you stop posting in this thread until you learn a little bit more about how data travels through a network.
#7
The ServeTheHome forum has a nice thread about the Edge 620,640,680 devices. They are a little/lot more powerful than the 510.  Just something to consider for anyone looking for hardware ideas.  I personally have a 620 and a 640 and run OPNsense on both of them without any issues. 

PS - do not get the 610 models because no one has found drivers to make them work with third party software like OPNsense.
#8
I would agree with JonM that most consumer grade devices don't come with a static IP address of 192.168.1.1 outside of consumer routers.  If for some reason you are setting up one of these devices, you should really connect to those directly and change the appropriate settings (like turning off DHCP services) before you attempt to connect it to your regular network (perhaps as a WiFi AP point for example). 

Most consumer devices are generally going to be set up to get a DHCP assigned IP address which means they should automatically get a valid address assigned when they connect to the network the first time.  Depending on which VLAN they are connected to will dictate what IP address range they are assigned to.

If you find yourself using a device that has a factory assigned static IP address in the 192.168.1.1/24 range, you can simply connect it to your main network (no VLAN) and you should be able to connect to it that way.  Since the OPNsense firewall is the only device on the 192.168.1.1/24 subnet, there shouldn't be any issue with duplicate addresses.

If you find yourself working with a lot of devices that are factory assigned static IP addresses outside of the 192.168.1.1/24 subnet that your network is already using, you can always create a VLAN specific for that use.  For example, 192.168.0.1/24 seems to be another popular consumer grade subnet, so you could always create a new VLAN using the subnet to connect these devices to initially to change their settings to whatever you want to use long term.  Then unplug them from this "setup" VLAN and connect them to the VLAN they will be associated with long term.   

Personally I'll generally connect directly with a new device using my laptop however and just manually set the device up to function like I want (IP address or otherwise) prior to connecting it to  my home network.  This way I know there aren't going to be any issues.
#9
While I would never set up my router to auto update, I can also understand why someone would. 

I don't do it because there is always a chance that the update will break something and bring my whole network down.  Given that I am away from my house most of the day, this would be very annoying for everyone that is still at home.

However, the odds that a bug would bring down the network are relatively low, and if someone worked from home or was otherwise around to fix issues when they arose, having updates automatically applied would be convenient. 
#10
Are you sure the different LANs are set up correctly with regard to IP addresses.  You say only one of the three is set up to use DHCP.  I would suggest that you turn DHCP "on" on all three LAN segments.  I suspect there is an issue either in your network segmentation address scheme (your LANs are overlapping addresses for example), or with IP address assigned (or not assigned) to the NIC of your computer you are tying to connect.  By turning on DHCP, this will correct both issues. 

You need to simplify things to ensure they work correctly.  If you later want to "complicate" things by turning off DHCP on some of the network segments, at least you know why it stops functioning.
#11
If you don't use VLANs, then all of your "routing" is handled at the switch level.  This means the only traffic that should be crossing through the firewall is data going to/from the internet connection.  Since your internet connection is slower than a 2.5gb connection, the difference between using a 10gb and 2.5gb between the firewall and switch is really not going to make a difference.

If you decide to switch to using VLANs (managed by OPNsense), traffic on the same VLAN will continue to be routed at the switch level.  Only traffic that needs to cross over from one VLAN to another will have to traverse to the firewall.  So even if you decide to add VLANs in the future, if you just take some time to ensure that data will travel on the same VLAN as much as possible and only cross over to another VLAN in rare occasions, you will likely still be fine using the 2.5gb connection between switch and firewall.

That being said, you don't mention the speeds of the normal ports on your network switch, but I suspect they are 10/100/1000.  This means that the real speed limitation on your network is currently with your switch, not the connection between the firewall and switch.  My recommendations above are assuming that all of your network devices are connected to the switch and nothing else is connected to the firewall (other than WAN and switch connections).

If you do have devices that can connect at faster speeds, you might want to connect those devices directly to the firewall's 2.5gb ports and then connect the firewall to the switch using the 10gb connection to ensure the fastest possible speeds should there be max throughput on several firewall ports at the same time.  In that case, using the 10gb connection between the firewall and switch could make a difference in overall network speed.

Hopefully that makes sense!

#12
Tom,

You seem to be just beginning your network journey.  As such, I would like to know why you think you need a DMZ?  While DMZs are not unheard of, they are kind of out of the ordinary for a typical home network.  I just want to get some clarity on your use case because it might be something you think you need, but really don't.
#13
Any particular reason you feel the need to run two DHCP servers (one in OPNsense and one in the Wireless AP)?  To keep it simple, you should really just run one on the OPNsense device.  Any device connecting to the wireless AP will still be issued a DHCP address from the firewall.  Hopefully the two current servers are handing out addresses in different subnets, but that still raises complexity to the system that really isn't needed.  If the two servers are handing out addresses that can overlap with each other, then you will really have problems.
#14
Thanks for everyone's help with this.  I utilized the stacking capability of the Brocade switches and it works great. Being a non-professional and having zero experience with stacking, I thought it was going to be a challenge for me to accomplish because I was expecting to have to do a lot of the switch configuration manually.  In the end, all I really had to do was connect the two switches together correctly and then initiate the stacking setup on the "primary" switch.  It found the second switch and set both switches up in the stack automatically.  It couldn't have been easier to do!
#15
I would suggest that you change the "from LAN network" to "any" in both of your rules, making it a true Allow All type of rule.