@hellegaard1 said in How to get PFSense to work with Plex?: for some reason Plex just isn't working with the PFsense Well did you setup firewall rules on your bridge? And only allow the smb ports.. Bridge is at layer 2.. If you can access through the bridge to something via protocol X.. Then only reason you wouldn't be able to access protocol Y is you firewalled it. Can you ping your plex IP? When you ping it, do you see the mac even if you don't get a response? You can view your arp table on the client your pinging your plex with arp -a

DHCP is not running so you would need to set a static IP in the new subnet you set to access it. Steve

That's a v6 link-local address. I assume that is not your WAN MAC?

Ok, well I'm not sure how many of those setting actually apply when it's in bridge mode. Those NAT setting in particular seem unlikely to apply here since the router behind it is using that IP directly. I also note that the bridged router is showing the x1.x1.x1.x1 as being DHCPv4 and not static as you said. However we can't see the WAN setup there, it could just be a display glitch. Does pfSense work there with it's WAN set as DHCP? Given what we can see I would have expected the /30 IP to work as a VIP. Can we see exactly how that was setup? I could imagine it might require a different MAC to work which would be a problem. It could be a completely separate subnet enabled on the same link (ugly!) and might require using the /30 upstream gateway. In which case you would have to add the gateway and outbound NAT rules to use it. Steve

@keyser I tried it with a local user and tested it by testing the auth on the firewall. Just the time period, not the COA.

@akuma1x yep. I'm a dumbass. That was exactly the problem. Cant believe I didnt see or catch that. Thank you. Working now.

@frankyd3325 Hello It now lasts alot longer than 30 minutes (or it has in last few days, but still drops for no reason, or as you pointed out, when I make changes to rules/alias ect.... Why does Avahi daemon leave the group on all vlans ??? I wasn't adding rules/editing rules or anything, it just fired off? Is this normal behavior? Any ideas tips/solutions I'll take any help I can get

After a lot of failing I finally have a very first small success: My interim solution is using https://github.com/marjohn56/udpbroadcastrelay on another virtual machine I spin up just for that and more or less "disabling" my firewall (i.e. currently I allow way to much traffic between my networks... but as a starting point it works finally and I think from here I can work my way out by silently reading existing posts ;-)). I'm not very familiar with freeBSD, that's why using a separate LXC for that is more convinient to me. Now, that I know it CAN work, maybe (possibly never..) I will take the time and migrate that to my pfSense host. Anywas, thank you for your answers

Yup that would do it! Both sides need a valid route to reach the other if there is no NAT involved. Usually that's the default route via pfSense. Steve

Right, so if your BIOS does not include a UEFI shell then you need to boot something that does, which isn't pfSense. I would be looking for a USB image to do it. What are you trying to change anyway? Is it passing a bad value to pfSense? Steve

@mdecou you need server: above that.. With the server: I would expect you would get a parse error. I just tried it without server, and do not seem to get an error - but not sure it would work.. But yeah you need that or your most likely going to run into a rebind error.

the problem is already solved. the account was already secured. by a password 30 characters long randomly generated. it was not at risk. it only serves this purpose, its not my email account, so i never log into it, except when they break things in the name of "security". because i never log into it, i had no idea app passwords was a thing that could be used; they don't show up as even existing until you have 2fa on, but why would I turn 2fa on and break my notifications, thus, creating a circle. i have another account that is for arctual google services that doesn't use external apps, and all my google-fu failed to find any reference to app passwords. the first I heard of it was by chance in the feature request. once I knew that existed, i was able to find out that 2fa needs to be ON to even see it. i know perfectly well how to read my email...

Yeah, there's no way to switch filesystems at upgrade. You can only do that by reformatting at install. So it must have been running ZFS already. I think the bug you are referring to is this: https://redmine.pfsense.org/issues/12144 That only applied to ZFS installs, Steve

Encrypted private keys are not yet supported. You have to import the key without encryption. https://redmine.pfsense.org/issues/1257

- this is embarrassing. . . . I feel so stupid. It turned out to be that the server was being blocked in the AP's access control settings. Had been banging my head on this for a couple of hours. Thanks for the reply, @stephenw10 .

The simplest way to get back to a known working state with those sorts if errors is going to be a clean reinstall of 2.6 and config restore. If you cannot do that you can try a force re-install but that is not guaranteed. https://docs.netgate.com/pfsense/en/latest/troubleshooting/upgrades.html#forced-pkg-reinstall Steve

@departy As @Bob-Dig : [image: 1646643883767-5a3455e9-33b1-4940-9361-46c08720ffb0-image.png] says that dyndns is synced every day at 1AM1. The sync is also triggered at a WAN NIC network event, as this might imply a WAN IP change. If pfSense uses a RFC1918 IP on it's WAN, there must be an upstream router. These routers can renegotiate a new WAN IP without pfSense knowing about it. For pfSense, the RFC1918 didn't change : no WAN NIC event : the dyndns sub system isn't made aware of a possible change. As proposed : accelerate the checks. The dyndns script checks the domain DNS IP (it does a nslookup or dig) and compares the obtained IP with the IP stored in a local cache file. They must be the same. If so, the IP is shown on green in the widghet. If not, the IP is update on the DNS server side, and if all ok, then the local cache file is updated.

@steveits thanks for the tip re old releases. Lesson learned.

Probably both. The pfSense package should not create a pimd conf file that includes invalid interfaces. pimd should probably not kernel panic on a bad conf file. I expect it to simply fail to start. Steve

No, I've not noticed that. What CPU is that? The widget gets those values from the sysctls so I'd suggest you might just be missing the peak values that are caused by loading the dashboard. Try loading the CPU artificially and see if the steady state values match. When I'm doing that I use: [22.01-RELEASE][admin@5100.stevew.lan]/root: yes > /dev/null & [1] 6443 [22.01-RELEASE][admin@5100.stevew.lan]/root: yes > /dev/null & [2] 6589 [22.01-RELEASE][admin@5100.stevew.lan]/root: yes > /dev/null & [3] 6594 [22.01-RELEASE][admin@5100.stevew.lan]/root: yes > /dev/null & [4] 6923 That makes the 4 cores there run at 100%: last pid: 7719; load averages: 2.28, 0.69, 0.29 up 2+01:00:56 22:36:41 64 processes: 5 running, 59 sleeping CPU: 15.7% user, 0.0% nice, 84.3% system, 0.0% interrupt, 0.0% idle Mem: 20M Active, 152M Inact, 437M Wired, 3229M Free ARC: 175M Total, 42M MFU, 129M MRU, 172K Anon, 785K Header, 3756K Other 57M Compressed, 175M Uncompressed, 3.05:1 Ratio Swap: 1024M Total, 1024M Free PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND 6443 root 1 103 0 10M 2068K CPU1 1 0:49 100.06% yes 6594 root 1 103 0 10M 2068K CPU3 3 0:47 99.90% yes 6589 root 1 103 0 10M 2068K RUN 2 0:47 99.86% yes 6923 root 1 103 0 10M 2068K CPU0 0 0:46 99.83% yes 7719 root 1 20 0 13M 3572K CPU2 2 0:00 0.21% top 87020 root 1 20 0 14M 5068K nanslp 1 0:21 0.02% vnstatd On the 5100 the core temps are help pretty close: [22.01-RELEASE][admin@5100.stevew.lan]/root: sysctl -a | grep temperature hw.acpi.thermal.tz0.temperature: 0.1C dev.cpu.3.temperature: 46.0C dev.cpu.2.temperature: 46.0C dev.cpu.1.temperature: 46.0C dev.cpu.0.temperature: 47.0C Other CPUs may not be coupled as well to the heatsink, or internally each core. You can run killall yes to stop those. Steve