@wc2l said in Teams Issues:

teams.microsoft.com works just fine.
Host "msg.teams.microsoft.com" could not be resolved.

Same for me.

edit : while waiting, read also C:\Program Files (x86)\Microsoft Teams Network Assessment Tool\Usage.docx - this is a Microsoft tool with a manual / notice .... ( 😊 )

@Wolfgangthegreat
...and to @comet424

I wasn't able to perform the 2.8.0 update this weekend, but when I got to the school this morning, it worked perfectly!

I appreciate the support from both of you, and from Netgate.

The backup/standby pfSense instance is back in place and ready in case I have a hardware failure, or a failure of the gray matter between my ears!

My best to all of you.

@ThePowerPig
So add an additional rule to allow access to internal subnets (best to create an RFC 1918 alias for this purpose), but at least for the IPs you want to access from the device in question, and move this rule up above of the policy routing rule.

@stephenw10 Confirmed fixed ty kindly sir.

@70tas Indeed the global token does not work anymore, you must use the API token. And then for the login, do not use your email address. As I wrote before: "One must use the Zone ID when using the API token."

I have this working using the DDNS GUI. I only needed the script for debugging.

The default LAN to any rule should pass that traffic.

What rule did you add exactly?

What gets logged when you run that in 2.8?

Because 10.60.0.252 is the server end of the VPN tunnel at pfSense. The local DNS resolver (Unbound) listens and responds on that IP and that is where the override is set.

Where as 8.8.8.8 is Google's DNS service that knows nothing about any local overrides you might have set. When clients use that DNS server is bypasses any local DNS overrides.

@stephenw10 Thanks for letting me know there were backend issue, I think it would be helpful if Netgate posted an announcement when there are issues, maybe some details, and an ETA to restore service.

It would save a little headache for some of us.

@rasputinthegreatest well blocking and not log would just be any any udp to that ff0e::c address or port 1900 anything, etc. And don't have it log.

As to the scanners - that is a pfblocker alias I have.. And put that in a floating rule.

scandeny.jpg

@jc1976 said in Squid on 2.8:

upgrade an issue developed between suricata, pfblocker, and unbound. when i disable the two packages, all works fine

Let's consider :
If you leave the 'unbound' (the resolver) settings to "all default", the way you found them when you first installed pfSense.
You remove / don't install the extra stuff = suricata and pfblocker.
Then : no issues what so ever.
Right ?

This means your issue isn't "pfSense 2.8.0" or the upgrade. Its an 'ordinary' package settings issue - call the admin 😊

Tell you boss that suricata can only filter non TLS traffic **, something that doesn't exist anymore. Check for yourself : who visits http (port 80) sites these day ? Who collects mail using port 110 ? Who sends mail using port 25 ?
Imho : suricata, for what it's worth, can't do much these days, it can 'see' the data payload in the packets. Everything is TLS these days.

** It is possible to do TLS filtering, but that demands a 'proxy' setup, making you a real expert.

pfBlockerng is blocking you, DNS or something else ? That's any easy one, and rather simple do debug.

@johnpoz I see, thanks for explaining and the help!

I have already solved the problem by using the Python library. You can delete my post. Thank you for your help)

@lbeard said in Dynamic dns don't work with carp ip:

Done => https://redmine.pfsense.org/issues/16326

Great, thanks 👍 👍

@stephenw10
Thanks again.
Well it is full of passwords and pre-shared keys and very detailed stuff but I guess we should find the culprit of it somehow.

I did find leftovers of lcdproc before, which I cleaned at some point.
That means that part of the config I am using was migrated from a modified WatchGuard I have used in the past.

Let me have a look tomorrow.
It's kind of late now in my timezone.
Thanks!

@SteveITS

Thank you for the clarification. You're right — better to be safe. I’ll update FW2 when I'm on site, and then FW1, which is my usual one.

UI Update output.

>>> Updating repositories metadata... Updating pfSense-core repository catalogue... Fetching meta.conf: . done Fetching data.pkg: . done Processing entries: . done pfSense-core repository update completed. 5 packages processed. Updating pfSense repository catalogue... Fetching meta.conf: . done Fetching data.pkg: .......... done Processing entries: .......... done pfSense repository update completed. 733 packages processed. All repositories are up to date. >>> Setting vital flag on pkg...done. >>> Setting vital flag on pfSense...done. >>> Renaming current boot environment from 25.03 to 25.03_20250719205419...done. >>> Cloning current boot environment 25.03_20250719205419...done. >>> Removing vital flag from php83...done. >>> Upgrading packages in cloned boot environment 25.03... Updating pfSense-core repository catalogue... pfSense-core repository is up to date. Updating pfSense repository catalogue... pfSense repository is up to date. All repositories are up to date. Checking for upgrades (10 candidates): .......... done Processing candidates (10 candidates): .......... done The following 10 package(s) will be affected (of 0 checked): Installed packages to be UPGRADED: if_pppoe-kmod: 25.03.b.20250515.1415.1500029 -> 25.07.r.20250715.1733.1500029 [pfSense] pfSense: 25.03.b.20250515.1415.1500029 -> 25.07.r.20250715.1733.1500029 [pfSense] pfSense-base: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense-core] pfSense-boot: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense-core] pfSense-default-config-serial: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense] pfSense-kernel-pfSense: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense-core] pfSense-pkg-Nexus: 25.03.b.20250515.1415 -> 25.07.r.20250715.1733 [pfSense] pfSense-pkg-System_Patches: 2.2.21_1 -> 2.2.21_2 [pfSense] pfSense-repoc: 20250419 -> 20250520 [pfSense] unbound: 1.22.0_1 -> 1.23.0 [pfSense] Number of packages to be upgraded: 10 The operation will free 12 MiB. 214 MiB to be downloaded. [1/10] Fetching unbound-1.23.0.pkg: .......... done [2/10] Fetching pfSense-pkg-System_Patches-2.2.21_2.pkg: ......... done [3/10] Fetching if_pppoe-kmod-25.07.r.20250715.1733.1500029.pkg: ... done [4/10] Fetching pfSense-pkg-Nexus-25.07.r.20250715.1733.pkg: .......... done [5/10] Fetching pfSense-kernel-pfSense-25.07.r.20250715.1733.pkg: .......... done [6/10] Fetching pfSense-base-25.07.r.20250715.1733.pkg: .......... done [7/10] Fetching pfSense-25.07.r.20250715.1733.1500029.pkg: .......... done [8/10] Fetching pfSense-boot-25.07.r.20250715.1733.pkg: .......... done [9/10] Fetching pfSense-default-config-serial-25.07.r.20250715.1733.pkg: . done [10/10] Fetching pfSense-repoc-20250520.pkg: .......... done Checking integrity... done (0 conflicting) [1/10] Upgrading unbound from 1.22.0_1 to 1.23.0... ===> Creating groups Using existing group 'unbound' ===> Creating users Using existing user 'unbound' [1/10] Extracting unbound-1.23.0: .......... done [2/10] Upgrading pfSense-repoc from 20250419 to 20250520... [2/10] Extracting pfSense-repoc-20250520: .. done [3/10] Upgrading if_pppoe-kmod from 25.03.b.20250515.1415.1500029 to 25.07.r.20250715.1733.1500029... [3/10] Extracting if_pppoe-kmod-25.07.r.20250715.1733.1500029: .. done [4/10] Upgrading pfSense-boot from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [4/10] Extracting pfSense-boot-25.07.r.20250715.1733: .......... done [5/10] Upgrading pfSense-pkg-System_Patches from 2.2.21_1 to 2.2.21_2... [5/10] Extracting pfSense-pkg-System_Patches-2.2.21_2: .......... done [6/10] Upgrading pfSense-pkg-Nexus from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [6/10] Extracting pfSense-pkg-Nexus-25.07.r.20250715.1733: .......... done [7/10] Upgrading pfSense-kernel-pfSense from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [7/10] Extracting pfSense-kernel-pfSense-25.07.r.20250715.1733: .......... done [8/10] Upgrading pfSense-base from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [8/10] Extracting pfSense-base-25.07.r.20250715.1733: ... done ===> Keeping a copy of current version mtree ===> Removing schg flag from base files ===> Extracting new base tarball ===> Removing static obsoleted files [9/10] Upgrading pfSense from 25.03.b.20250515.1415.1500029 to 25.07.r.20250715.1733.1500029... [9/10] Extracting pfSense-25.07.r.20250715.1733.1500029: .......... done [10/10] Upgrading pfSense-default-config-serial from 25.03.b.20250515.1415 to 25.07.r.20250715.1733... [10/10] Extracting pfSense-default-config-serial-25.07.r.20250715.1733: [10/10] Extracting pfSense-default-config-serial-25.07.r.20250715.1733... done Failed

Thanks everyone. That did it. No more errors!!

I would agree. 18 hours in and everything continues to run smoothly. The issue related to image availability I believe is the valid answer and we can close this out as solved. Thanks everyone. -JD

@ashleygavin said in Vodafone UK - IPv6:

What error do you get if you wget -6 a website?
And you have the two default LAN firewall rules, one for IPv4 and one for IPv6, and only the LAN net? On WAN you won't need any rules for accessing internet. And do you see open states for the (web) connection?

NAT would not be a topic for IPv6 in the default config.