Messages

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

Glad you have it fixed. All mistakes are learning curves, I know, I've made a few myself. However, from time to time you do just get wierdos and a complete re-install and import of the config fixes it.

There's something odd going on that's for sure. At this point I would back up your config and reset or re-install Opnsense. Get the basics working, i.e. get a working router and the first thing you then do is the plex stuff. You can then use the restore function in System:Configuration:Backups to restore any other config settings you have one by one, testing your plex instance after every step. Chances are it will stay working as I've had oddities like that myself.

Just as a stupid idea, first try disabling the firewall on the windows PC that you are using as a plex server.

Sorry, did you set the redirect target port to 32400 in the Port Forward of Opnsense, I appear to have not mentioned that. If not, set the Redirect target port to (other)  and the port number to 32400.

On the Plex Remote access page, is it showing "Fully accessible outside your network" ?

There is nothing funky with this, it's really simple. Get rid of the reflection for port forward, you don't need it. So undo what you have done and just do this:

In the Plex interface go to Remote access select show advanced and manually specify the public port and apply, I use 54444, use that or pick a port somewhere around that number.

Next go to Opnsense, select Firewall/Port Forward and add a new rule.

Interface: WAN
TCP/IP: IPv4
Destination: WAN address
Destination Port Range: Select OTHER for both from and to and enter 54444 or the port you have used in both.
Redirect Target IP: Your plex server IP, in my case 10.4.15.100
Description: Plex

That's it, nothing else. Apply and save that lot and then go back to your plex server page and you should see the server is now accessible.

Two dhcp6c instances? I thought we'd fixed that years ago! That used to be an issue in about 2017/18 but haven't seen it since. OK, try this, we're testing not fixing. Kill any dhcp6c instance and then leave the system alone for about thirty minutes.
From the shell restart dhcp6c, if you didn't do a full grep here's the command:

# /usr/local/sbin/dhcp6c -c /var/etc/dhcp6c.conf -p /var/run/dhcp6c.pid -D

I added the -D for full debug, does it now get the addresses?
The thirty minutes is important as it might be an ISP issue, I've seen it before.

If your IPv6 PD is going to change then just leave everything as tracking. If your address allocation changes then that will be advertised to your internal LAN by the dhcp6 server and radvd.  If you want a server on your LAN that can be accessed from the WAN then use a dns provider that supports dynamic DNS such as Cloudflare and use DDNS to update it. I've been there and got that t-shirt.

24 hours later and still solid.... bloody gremlins.

Now I'm completely baffled. I rebooted again and sat there running the ndp -r command and watching the timer countdown and reset, and reset, and reset....
It's working fine now.

I'm 99% sure the default route is stripped by a zero lifetime RA which the kernel reacts to by removing its default route and you can't even see it.

# ndp -r

should reveal that default route and if it's gone afterwards.

Funnily enough I just saw there is a "ndp -I xxx" which can set a default route via one particular interface if the route disappears for any reason but I've never tried it.


Cheers,
Franco

Interesting... I see this:
fe80::8ff:fe61:e32b%igb0 if=igb0, flags=MO, pref=medium, expire=2m59s
So that explains it.