Messages

Where there is an API that can be used then monitoring scripts use it, if there isn't then other methods are used, including telnet, curl, ping and wget. It's just easier to have one machine in the middle, that handles the monitoring of everything and then just tells me once a day that everything is good and it's still awake, or in 15 minutes or less if there is a problem; Said machine also has a web page running that is updated every 15 minutes . OpnSense is a brilliant piece of software, but its primary use is that of router/firewall, and I'll leave it to do what it's primarily designed to do.

And then AI drops the ball, or in this case the parcel.
https://news.sky.com/video/amazon-drone-drop-womans-package-into-her-swimming-pool-13574981

AI, no matter how clever it is, is still subject to the acronym GiGo. For a free system Google AI is pretty impressive, and it can write scripts and create web pages faster than I can. 🤣

What it also is very clever at, is making suggestions at how I can add and improve things. It wasn't my idea to add all of the monitoring, but I said that I have a windows server running two VMs that were running Windows, and that on those VMs were immich and Jellyfin etc, it said waste of resources, let's run them all in Ubuntu server VMs. So it walked me through the migrations using docker containers, then there was the Caddy implementation, originally on Opnsense, it didn't think that was the best and most secure way, so a new vlan was created to pipe the traffic to Caddy on a spare port of the QNap, and on and on. It's completely changed my system. It's all now running very smoothly and the servers using less resources, it's a win win. I also end up with a nice web page showing this. 

i have just spent a very interesting number of hours with Google AI. It has built,along with my input a Powershell script, or should I say a number of them that monitor my main windows server,  3 docker containers running on two VMs on that machine, a monitor for Caddy which is running on my QNAP, 5 Unifi access points, and a script the monitors what I think are the critical services on Opnsense, i.e. the gateway status, Unbound, these are checked by using the API. If the main server goes down which runs most of the scripts, a script running on the QNAP will send the alarm. Most of the notifications are sent via email, but what happens if the internet/Router go down, in those cases it gets sent using ntfy to our phones and an always awake tablet. Very impressed with Google AI, I have never written Powershell scripts, but they are all working perfectly. I'm glad I've retired!

Rookie! :-p

But thanks a lot, too. :-)  Although I never got involved. To many other things arround and not really much I could help anyways.

You did some testing, you posted issues on Github, you helped a lot of users, you got involved.

It'll be 9 years in December since I made the jump from pfSense to OpnSense. At that time OpnSense was a bit rough around the edges, well, let's be honest it was very rough around the edges, but I stuck with it, got involved and helped ( or hindered ) in a few ways. I just want to say that what I am using today works pretty much flawlessly. I have just spent several hours cleaning up firewall rules, getting used to the new firewall layout, adding AbuseIPDDB and more, all working flawlessly.
Well done chaps, you should be very proud.

Looks good, installed without any issues. Thanks for the heads-up.

Having used both Omada for 4 years until I moved house and Unifi devices for nearly years two since I moved,  I will give an honest opinion.

TP Omada are cheaper and they work fine, however I have found that the Unifi devices are more stable and allow a greater degree of 'tweaking'.

I'm currently using 4 Unifi U6 Mesh devices, 3 of these are wired and one is mesh, and one Unifi AC mesh with a directional antenna in the garden, the garden one meshes with a U6 Mesh located under the eves of the house. You can try and set them all up with a phone app, but it's not fun. If you are going to use VLANs then create your own self-hosted server, it's pretty easy. It doesn't need to run all the time, there's also a plugin for Opnsense which Micheal maintains, though mine is running on a VM on my server.                                                                               
The mesh works really well providing you make sure there's a good signal between the master and slave device. Preferably only slave one device to each wired master.

One final note, if you go down the U6 mesh route, don't use one outside, they are not weatherproof, as experience has taught me, or at least use a silicone cover which are available.

Yes, apart from the two mentioned problems...

They are not issues that affect my system. Lots of memory to spare and a decently quick CPU. I had an issue with Amazon web services being blocked, even though they were in Ireland and that is allowed. I had to put in a separate firewall entry to allow them. Changing to IPInfo has meant I no longer need that extra rule.

https://github.com/opnsense/core/issues/7779 ;)

And it seems to be working nicely...

I managed to get it working by removing the 1.1.1.2 as source address and instead leave it blank.

Source address is not required for Sky SSDP which is what the OP was asking about.

It's covered in the documentation.

I switched to KEA IPv4 when it first became available and have waited on IPv6 to be added, that's now available too. The reason I'm going with KEA is Prefix Delegation, that is the only reason. Most of my devices have reservations, so I do not really need the ability to add dynamics to Unbound, though there is a modified unbound_watcher.py out there that does appear to work, maybe something like that may be added in the future. However, as I said I run a test router down stream from the primary and need to be able to delegate a v6 prefix to that.

Sky Q is why I originally put this package together. 😊

I suspect you need to add a firewall entry on your PC. Windows will block the responses from the Q box as it's coming from an address on a different VLAN.

Open windows firewall, Select Advanced Settings

Select Inbound Rules
New Rule

Name: Sky Q Pass
Enabled: Ticked

Protocol and Ports Tab
Proto Type: Any

Ports: Local and Remote: Any

Scope Tab
Local IP address: Any
Remote IP: YOUR Q BOX IP - In my case 10.4.15.91

Advanced Tab:
Specify profiles to which this rule apples
Tick all of them

That should do you.

Can you see and use the Plex server from a device on the same VLAN as the Plex server? If yes then there is no reason why with the use of UDPBroadcastrelay and a firewall rule you cannot get it to work across VLANs.

Try mDNS or UDPBroadcastRelay.

Here's mine, I have plex on my IOT VLAN but devices on my primary VLAN can see it. You'll likely need a rule to allow the PLEX server to send the streams to the primary VLAN.

Relay Port 5363
Relay Interfaces Pri, IOT
Broadcast Address 224.0.0.251
Source Address 1.1.1.1
Instance ID 2
Use TTL for ID YES
Description mDNS