What exactly are you counting as a leak test failure? If you're forwarding requests to Cloudflare then DNS tests will always show Cloudflare. It just might be local servers if the query isn't over the VPN.

@wesley33taylor okay, now I have to ask, just due to being especially dense today, what and how did you do that? what do others need to change, so that there is written history for anyone else that might end up finding this thread and wanting to do the same, the usefulness of archival purposes and the desire to confirm I've done the same drive me to ask this. please advise.

@gambit100 That file is really not usefull, as it doesn't show the contents. I ran Wireshark, filtering on ICMP6. Here's a list of the packets received, with the RA in the top row: [image: 1757623267241-17d2a377-a2cc-4179-aa71-f0ba19566d2d-image.png] Here is the contents of that frame, showing the relevant info. Several items can be expanded further: [image: 1757623471656-826054d0-050a-4992-890f-b88e7057c4e5-image.png] This is the sort of thing you need to understand network problems. You can use Packet Capture, in pfSense, but I find Wireshark is much better. Even if you capture with Packet Capture, you're still better off examining the capture with Wireshark. Now, if you look at the options, you'll see things like assigned addresses and DNS.

Hmm, well it should start at boot. If it fails to start I'd expect some error to be logged.

@perrin said in new if_pppoe Backend - getting HA/CARP to work like in MPD: @zjamali yep, same here. I'll debug why it is not working on the first VIP later. Can you temporarely work with a different VIP? Should be OK. no issue

@claudiove se non hai già aggiornato fallo, non aspetterei troppo c'e' già la 2.8.1 io aggiorno costantemenete e non ho da segnalare problemi

Hmm, I agree. Let me see what we can do here.

The ice(4) driver is in kernel already in 2.8.X.

You could try an afterfilterchange shellcmd to trigger a script. That would be triggered when any tunnel comes up.

@Gertjan Yeah, the Wi-Fi isn't assigned at all. I'll try disabling it and see if it has any effect.

@philippe-richard use the new UI (by default it listens on port 8443), which will let you see the API calls, similar to the screenshot of the web devtools above, where the id is derived from a unique value of the rule entry. This is unlike the PHP pages which do not have an API and assume one admin accessing the page at any time, so submitting from *_edit.php?id=7 could end up hitting the wrong entry if two people are modifying the rules at the same time.

Check for rogue repo files here: [2.8.1-RELEASE][admin@cedev-2.stevew.lan]/root: ls -ls /usr/local/etc/pkg/repos/ total 1 1 -rw-r--r-- 1 root wheel 25 Aug 28 17:10 FreeBSD.conf 1 lrwxr-xr-x 1 root wheel 55 Sep 5 12:02 pfSense.conf -> /usr/local/etc/pfSense/pkg/repos/pfSense-repo-0002.conf It's been a long while since I tried pf2ad but I'm pretty sure it has an install/uninstall script that should do it. Unless it's completely broken!

@scottlindner look in https://github.com/pfsense/FreeBSD-ports/*/pfsense-pkg-*

@marcelobeckmann Obrigado pelo contato em diagnostico/rotas existem varias rotas inclusive para 192.168.10.0/24 Meu conhecimento com PFSense é basico e fiz as congurações baseados em videos e tutoriais encontrados na internet para fechar esta VPN Site to Site Poderia me auxiliar como criar estas rotas e onde verifico se elas existem? Para adiantar vamos a estrutura DATACENTER - PFSENSE WAN: 201.46.121.XXX LAN_BLO:192.168.100.1/24 LAN_EFT:172.11.1.254/24 LAN_HPK:192.168.120.1/24 LAN_GTR:192.168.130.1/24 VPNSITETOSITE VPN_EFT - LAN_EFT DATACENTER X LAN_EFT CLIENT TUNEL IP: 10.0.11.0/24 LAN LOCAL: 172.11.1.0/24 LAN REMOTA 192.168.10.0/24 STATUS: FUNCIONANDO EM PRODUÇÃO PINGANDO NORMAL DA LAN REMOTA PARA LAN LOCAL DATACENTER. VPN_GTR TUNEL IP: 10.0.15.0/24 LAN LOCAL: 192.168.130.0/24 LAN REMOTA 192.168.10.0/24 STATUS: CONECTADA PINGANDO SO DE DENTRO DO PFSENSE LAN REMOTA NAS ESTACOES DA LAN REMOTA (192.168.10.0/24) NAO ALCANCAM NEM O SERVIDOR DE DADOS (192.168.130.242) E NEM O PFSENSE (192.168.130.1) AMBOS SAO ALCANCADOS DE DENTRO DO PFSENSE LAN REMOTA. JA USEI COMO BASE A VPN_EFT E NAO ENCONTREI NADA DE DIFERENTE QUE JUSTIFICASSE A VPN_GTR NAO FUNCIONAR|-left aligned paragraph

So as a follow on, I have noticed that the gateway monitors are tripping fairly regularly on my AT&T Fiber IPv6 which is probably what is causing the DHCPv6 client to jump into action which occasionally leads to this situation. I've found similar issues from older releases where there was a race between interface reconfiguration and disablement. I've disabled the IPv6 monitor from taking action (but still logging) so will see if that eliminates the panics. But the fact that it can happen is still concerning.