@stephenw10 Ok. Makes sense I was advised by Tailscale support that I might need to establish NAT rules and a static route in pfsense if I wanted to force pfsense to use TS as a gateway for one of my other subnets on another one of my TS networks. If I know the TS address of my local network is 100.xxx.xxx.xxx Then how would you propose to establish that address as a gateway and then to use that address as a gateway for a static route for a subnet on an external 192.168.8.0/24 subnet (also on my TS network) ? (Other than the error the routing is occurring properly now) Here is communication from Tailscale support: Kelly replied: Hello, I’m Kelly from the Tailscale support team. Thanks for reaching out! What you’re seeing is a known side effect of how Tailscale handles routing when subnet routing is enabled, especially on routers like pfSense and GL.iNet. What’s happening is that Site B is advertising a subnet like 47.214.112.0/21, and that includes its own public IP (47.214.118.244). So when Site A tries to ping that public IP, Tailscale grabs the traffic and routes it through the tunnel instead of out the regular WAN unless you add a static route to force it out the normal way. That’s why disabling Tailscale or adding the route makes it work. It’s just a side effect of advertising too broad of a subnet. Totally fixable by narrowing the subnet route or adding a static WAN route for that IP. For the other issue of not being able to reach Site B’s LAN from Site A- I think this might be a NAT or routing issue: Make sure both routers are advertising their LANs and the routes are actually enabled in the Tailscale admin console. You might need outbound NAT rules on the routers to let traffic forward properly. If you’ve disabled SNAT with --snat-subnet-routes=false, you likely need return routes for Tailscale’s 100.64.0.0/10 space, which a lot of home routers won’t handle. In that case, you can just use MASQUERADE/NAT on the router to make it work. (Related doc here ) For Linux-based routers (like GL.iNet), this usually fixes it: iptables -A FORWARD -i tailscale0 -o eth0 -j ACCEPT iptables -A FORWARD -i eth0 -o tailscale0 -m state --state ESTABLISHED,RELATED -j ACCEPT iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE Just keep in mind that’ll rewrite the source IP to the router itself, which might not be ideal depending on what you’re doing. pfSense doesn’t support that SNAT flag (since it’s FreeBSD), so I think you have to rely on NAT/firewall rules or static routes to get things working cleanly. Let me know your thoughts on this, and if this helped. I’m happy to answer any questions you may have.

@stephenw10 Seems more interesting this morning. Early morning Friday 1:30am our graylog server shuts itself down, does some maintenance and starts back up (usually takes < 5 minutes). - not a issue previously - system would come back up and logging would resume as normal. Got going this morning with this [image: 1754649751935-screenshot-2025-08-08-at-6.10.57-am.png] [image: 1754649789610-screenshot-2025-08-08-at-6.12.07-am.png] nothing from the netgate logged since and until I restarted both syslog and unbound a down syslog server should not be stopping the service - that seem wrong. makes me think syslog itself is having issues (or perhaps this as a result of the handlers not playing nice in unbound. Note: note other systems that log to the same graylog server, worked as expected. That is simply resumed/continued spewing as soon as the system came back online.

@michmoor said in Unable to log into WebUI after 25.07 upgrade: I am assuming nginx has their own local database file that it uses for credentials? Not its own. 'The' System > User Password Manager. So a user like the 'admin' is present (has to be present) in the main pfSense config file : [image: 1754649198363-9b0cf17d-25e4-4d36-8ebf-2d1a7036523e-image.png]

@kellylucero said in Keyboard stops responding after booting: I've restarted the PC ... So you're seeing the boot process on a screen attached to the device with a CVGA/HDLI cable ? The kernel boot probably switched over to the serial USB console from that point on, so nothing shows up on the screen anymore. This might help you : Troubleshooting Boot Issues. @kellylucero said in Keyboard stops responding after booting: is due to needing to disable DHCP You disabled the DHCP server on LAN ?

@stephenw10 Yeah that's what I'm thinking, maybe the ONT itself can't handle it or something along those lines. I know many ISPs do throttle torrents, but you'd usually see that as the torrent traffic itself having higher latency and stuff, not just dropped packets on the entire connection, though it doesn't appear the later is unheard of. Pretty confident at this point it isn't pfSense, so at least that's good. May also see if my ISP can get a tech out, after I test both VPNs and possibly direct fiber connectivity instead of the ONT.

Updated to 25.07 today and had the same issue. Hung at updating configuration for about 10 minutes. Reverted back to 24.11, cleared all the pfBlocker config backups (~7k), updated went smooth.

That error is from the PPPoE module so it won't show if you're not using it even if they are still arriving. Not much we can do here without more data. I suggest trying to capture these rogue packets on the WAN in a pcap.

@ahole4sure said in SSH with public key and new macbook pro: could you possibly send a screenshot of what all is in your config file? :) ... no, I can't do that. It is full of information not to be shown in public. But I can paste an example and you'll find a lot on the internet. Include ~/.orbstack/ssh/config # my firewall, e.g. pfSense, non-standard port # and specify which ssh private key to use Host firewall-at-home 192.168.1.1 User root Port 20022 IdentityFile ~/.ssh/id_rsa HostName 192.168.1.1 # my Synology DS920+ Host ds920plus User admin # default settings for hosts not matched # in above rules Host * User jane

Do you see blocked traffic on secondary? It sure looks like it's failing to authenticate there. Are you using a complex password? Are you using the admin user for the xml sync?

Yeah it will only show reduced usage when the pppoe link is loaded. On CPU that has good single thread performance it will be less apparent. The single threaded mpd5/netgraph driver is restricted by that. It's still worth using though.

@stephenw10 Thanks. I monitored the WireGuard traffic on the underlying interface at the same time and sure enough every 15 seconds the remote peer sends a 32 byte UDP packet. This ties up with the client's setting 'PersistentKeepalive = 15' so it is just the keep alive traffic. Mystery solved.

They are still coming into the WAN just without the :5 octet?

@stephenw10 No it doesn't install a 3rd party repo. However... it could possibly Mess with shared libraries (libmd.so, libssl.so, etc.) getting replaced or misaligned. Create conflicts in /etc/rc.conf, init scripts, or pkg metadata. OS version expectations (pkg or pfSense-upgrade behaving strangely).

You can't DNS Lookup 1.1.1.1, it's not an FQDN. When you have the outgoing interfaces in Unbound set to only the VPNs then it will fail to resolve anything if the VPNs go down. If pfSense itself it also set to use only the VPN DNS servers it won't be able to resolve the VPN servers to connect to them. pfSense itself must have access to some other DNS server. Or the VPN servers must be entered as IP addresses directly. I would revert to a much simpler more default config and make sure that works first.

Hmm, well hard to be sure I'd guess that Unbound was restarted when pfBlocker updated and then failed to restart for some reason. However that wouldn't prevent pinging 8.8.8.8. So another possibility is that one of the pfBlocker feeds had some rogue entry blocking far too much when it updated.

FWIW doing a "pfSense-upgrade -d" from CLI fixes this for me and does the upgrade properly. Not sure why that works and the GUI fails lol. I did have to rebuild my base packages. Here is what ChatGPT had to say about it. I had the same problem, two different locations, network providers, etc. One is in a datacenter with multiple network redundancies so I doubt it was a network issue. Root cause: The core problem was due to an incomplete or partially failed upgrade from pfSense 24.11 to 25.07. The missing critical libraries (libmd.so.7), corrupted package repositories, and broken package signatures indicate that some part of the upgrade script was interrupted, incomplete, or encountered dependency conflicts. Specific indicators of broken upgrade: Missing libraries (libmd.so.7) causing package operations to fail. Missing critical files (/usr/local/sbin/read_global_var, /usr/local/libexec/pfSense-upgrade, and /etc/version) indicate that pfSense-base or core packages were only partially upgraded. Invalid or broken repository signatures (pkg-static: Error loading trusted certificates) point to repository configuration or trust issues post-upgrade. Dependency conflicts (IGNORE_OSVERSION prompts) clearly indicated version mismatches due to packages from different pfSense/FreeBSD versions.

@stephenw10 Thank you. I will do some research on this option