@amrogers3 I route my notifications through Office365 without any problems.

@RyanM said in ACB host (acb.netgate.com) not reachable from pfSense: So I don't know that saying "they don't want (DNS) requests from you" is accurate is it? It said ;; no servers could be reached which means : no answer. @stephenw10 has a point : I presume that "100.100.100.100" only can answer if approached overt the tailscale connection. If the DNS request was send over the other connection, the WAN interface, then "100.100.100.100 " can't be reached and that makes sense (to me). That would explain the "no answer". Btw : I'm not using tailscale : test : [25.07.1-RELEASE][root@pfSense.bbhf.tld]/root: dig @100.100.100.100 google.com ;; communications error to 100.100.100.100#53: timed out ;; communications error to 100.100.100.100#53: timed out Note : the return message is different - more 'dig' language for saying the same think : can't connect to 100.100.100.100 - it doesn't answer. @RyanM said in ACB host (acb.netgate.com) not reachable from pfSense: EDIT: I forgot to answer your other question @Gertjan. Yes, the uplink is fine. Everything else seems to be working, and I can even reach acb.netgate.com from other hosts on my network, just not from the pfSense router itself. This has to have something to do with the DNS configuration in Tailscale. I want to enable the "Accept DNS" setting, I just need to figure out how to make it work while also being able to use ACB. Exact. You use tailscale and want to use the provided (?) tailscale's DNS server 100.100.100.100. What about forcing unbound's connection over the tailscale connection ?

Ok so it looks like we have a bunch of input drops in if_pppoe shown in the dtrace. Try enabling debug mode on the if_pppoe interface like: ifconfig pppoe0 debug With those input drops it should be throwing a lot of errors there and those should give us more info. Enabling that will throw a lot of log lines at the console so be ready to run ifconfig pppoe0 -debug to disable it again.

@stephenw10 yes em interfaces . She has pushed almost 50 gigabit through it in the last day and a half since the last reboot so seems like working well at this point..

@Gertjan Thanks that's great I'll try that right away , oh happy partying https://www.youtube.com/watch?v=HkoJd1yGvik

I have a VM running WG server. It did not require any pfSense work other than the allow rule for the inbound traffic. From there the WG clients can go anywhere, including out to the internet. For your question about VLAN routing, the packet will leave the client, passthrough pfSense to WG. WG will decode the packet and if needed send it back to pfSense to be routed. My WG install has the ability (Hint Netgate) to generate a QR code to configure the WG client. Super nice. I just send the QR code and the client is configured in seconds.

Yes, it's a planned feature. Only limited by available developer hours.

@stephenw10 Fair enough. It seemed kind of one-off, but I'm not an expert in reading a kernel panic to say for sure. I'll chalk it up to cosmic rays for now. Thanks for checking!

@Gertjan said in Notifications for ZFS status: @ohmantics Consider using : [image: 1761300513633-5936b3a6-4c45-4968-9b84-e2317a8f1fc4-image.png] it permits you to store the files you've added yourself in the main pfSense config.xml. As this file is already backed up regularly, (right ?) you've everything in one place. I've been using pfSense for over a decade and I never noticed this package. Looks like an excellent solution to preserve some of these customizations. Kinda a shame that none of the recipes online for modifying pfSense use this. @ohmantics said in Notifications for ZFS status: https://github.com/LeonStraathof/pfsense-speedtest-widget Speed tests shouldn't be executed on a router (firewall). You should 'speedtest' through your router/firewall. This is just a convenience widget, not setup as a cron job. It gives one data point among many to consider when debugging performance problems. I don't see an issue with that.

@Gertjan The fix here was to add more of RFC1918 to the mynetworks line in postfix. It would be nice if PTR records worked properly across my two sites, but I'll leave more complicated DNS configuration until another PTR requirement pops up. That doesn't solve the possible bug that the Validate checkbox doesn't actually disable validation, nor that my adding the proper CA and cert to pfSense didn't seem to work for this. And no, I will not be exfiltrating my email to Google for them to index, profile me for ads, and train AI on. Hell no. They're already the source of the majority of spam making it through my filters today because despite shoving DKIM down everybody's throats, they aren't doing a good job of confirming that their own customers aren't bots. They also aren't doing a good job of validating that their custom domain customers actually own a domain before letting them try to send email with it -- their own DMARC reports show that they are catching themselves trying to spoof SMTP (failing SPF) and it shouldn't be getting nearly that far through the process.

@johnpoz Thanks, I will try that!

@Gertjan said in Unable to create internal certificate (CA not detected): Try this : Make a backup of your config. Delete all your CA. (edit : the ones you've added yourself. There may be other certs - see the image below, you've probably imported these don't delete these) Then, as I've shown above : create a new CA. Name it like me : "test" do/add nothing else, and hit the Save button. Now, create a certificat, and check if you can select the CA named "test". Thanks, but I've tried that already. The CAs you see in my screenshot were recently created from scratch in the pfSense web UI after I had deleted all other CAs. @stephenw10 said in Unable to create internal certificate (CA not detected): The valid from and to dates are correct though? A CA that was, for some reason, no longer valid would be hidden. You might try exporting the CA and examining it in a cert viewer to check for anything obviously wrong. Yeah, I'll try that. I don't have my hopes up, though.

Yes, exactly. You can only policy route traffic going into the firewall so that excludes traffic from the firewall itself.

@eagle61 said in How do I discover ISP's PPPoE credentials and connection settings?: Well you never mentioned what modem/router your ISP is providing. But for some of them are hacks available to read the in it stored credentials in clear text. That does not really matter, does it? All routers are basically the same, maybe with the exception of Cisco, perhaps. They all run some variant of Linux or BSD and the same basic networking tools and utilities. @eagle61 said in How do I discover ISP's PPPoE credentials and connection settings?: One example for this Router are the in Germany most popular Fritz!Box, no matter Fiber, DSL or Cable. Those allow to create backupfiles (in case a factory reset is needed) of its configs and export that to you local devices. All credentials in this export-file are encrypted. But with a small php-tool its possible to decrypt it and have it in a clear text file. Good for them! Long live Germany and their liberal and user-friendly ISPs!

Mmm you can still set the resolve interval: https://docs.netgate.com/pfsense/en/latest/config/advanced-firewall-nat.html#aliases-hostnames-resolve-interval

If that's a pass-through port it would be available as an interface in pfSense but not to assign to a bridge in proxmox. If you want VMs on the virtual LAN to access it they would just be routed to it by pfSense once it's assigned there. You just need rules to allow it.

@patient0 Thanks for the old download links, really helpful those solving this.

If it stops at the interfaces assign prompt during boot it should say which interface in the config doesn't exist on the firewall at that point. That should give you a clue. You would normally be able access the firewall webgui on any IP address on the firewall from the LAN side because the default LAN firewall rules pass that. But you can could easily have added rules to not allow that.

@SteveITS Thanks all, I’ve logged it using that link: https://redmine.pfsense.org/issues/16498

Mmm, relatively trivial for http. Difficult to impossible for https. Pretty much all modern OSes will detect a captive portal page and show the user a button to open the page though. And that could show anything you like.