"Recent posts
#1
26.7 Series / Re: Invalid argument errors wh...
Last post by Shad - Today at 05:28:02 PMI tried to repair the file system, for some reasons it completed almost instantly and said that the file system had recovered.
but I already had some problems with this disk, and given that I had bought a 2nd hand msata disk (basically new ones are more expensive than nvme for some reasons), I seized the opportunity to migrate to the new disk.
Apart from the isc -> kea unexpected migration, it was smooth.
New smart scan also shows unknow_attribute although it comes from a reputable brand (Micron).
For now I'll keep it as it is, and look after periodic smart tests to see how it's going.
Thanks for your help.
but I already had some problems with this disk, and given that I had bought a 2nd hand msata disk (basically new ones are more expensive than nvme for some reasons), I seized the opportunity to migrate to the new disk.
Apart from the isc -> kea unexpected migration, it was smooth.
New smart scan also shows unknow_attribute although it comes from a reputable brand (Micron).
For now I'll keep it as it is, and look after periodic smart tests to see how it's going.
Thanks for your help.
#2
Hardware and Performance / Re: Mono Gateway (an NXP-based...
Last post by Greg_E - Today at 05:26:21 PMThat's not a good sign!
#3
Hardware and Performance / Re: Semi parts bin new build
Last post by Greg_E - Today at 05:24:53 PMQuote from: pfry on October 23, 2026, 01:19:34 AMHeh. I haven't seen a quad X710 for $125, though (unless $150 counts).
They have gone up recently, I probably should have bought 3 of them when I bought. The dual 25g x710 have also gone up recently.
One thing to note about these cards, not all speeds are available in the x710 series. You may be limited to 1/10 or 10/25. But the twisted pair should offer multi-gig speeds from 10m up through 10g.
#4
High availability / Re: CARP update of backup fire...
Last post by babagoo - Today at 04:52:02 PMThanks for the suggestions Sergio. I tried them and this time the download stops at the package: krb5: 1.22.2_3.
See below:
***GOT REQUEST TO UPDATE***
Currently running OPNsense 26.7.6 (amd64) at Mon Oct 26 15:46:34 GMT 2026
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (154 candidates): .......... done
Processing candidates (154 candidates): .. done
The following 21 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
cyrus-sasl-gssapi: 2.1.28 [OPNsense]
krb5: 1.22.2_3 [OPNsense]
Installed packages to be UPGRADED:
opnsense: 26.7.6 -> 26.7.7 [OPNsense]
opnsense-update: 26.7.6 -> 26.7.7 [OPNsense]
php85: 8.5.11 -> 8.5.12 [OPNsense]
php85-ctype: 8.5.11 -> 8.5.12 [OPNsense]
php85-curl: 8.5.11 -> 8.5.12 [OPNsense]
php85-dom: 8.5.11 -> 8.5.12 [OPNsense]
php85-filter: 8.5.11 -> 8.5.12 [OPNsense]
php85-gettext: 8.5.11 -> 8.5.12 [OPNsense]
php85-ldap: 8.5.11 -> 8.5.12 [OPNsense]
php85-mbstring: 8.5.11 -> 8.5.12 [OPNsense]
php85-pcntl: 8.5.11 -> 8.5.12 [OPNsense]
php85-pdo: 8.5.11 -> 8.5.12 [OPNsense]
php85-session: 8.5.11 -> 8.5.12 [OPNsense]
php85-simplexml: 8.5.11 -> 8.5.12 [OPNsense]
php85-sockets: 8.5.11 -> 8.5.12 [OPNsense]
php85-sqlite3: 8.5.11 -> 8.5.12 [OPNsense]
php85-xml: 8.5.11 -> 8.5.12 [OPNsense]
php85-zlib: 8.5.11 -> 8.5.12 [OPNsense]
Installed packages to be REINSTALLED:
openldap26-client-2.6.15_1 [OPNsense] (option changed: GSSAPI (off -> on))
Number of packages to be installed: 2
Number of packages to be upgraded: 18
Number of packages to be reinstalled: 1
The process will require 4 MiB more space.
22 MiB to be downloaded.
[ 1/21] Fetching php85-xml-8.5.12: .... done
[ 2/21] Fetching opnsense-update-26.7.7: ..... done
[ 3/21] Fetching php85-curl-8.5.12: ....... done
[ 4/21] Fetching php85-dom-8.5.12: .......... done
[ 5/21] Fetching php85-filter-8.5.12: .... done
[ 6/21] Fetching php85-simplexml-8.5.12: .... done
[ 7/21] Fetching php85-pdo-8.5.12: ........ done
[ 8/21] Fetching cyrus-sasl-gssapi-2.1.28: .... done
[ 9/21] Fetching krb5-1.22.2_3: ..
pkg-static: An error occurred while fetching package
Flushing temporary package files... done
Starting web GUI...done.
Partial update failure detected: report this error log to OPNsense.
No further actions will be taken. Please restart the update now.
***DONE***
See below:
***GOT REQUEST TO UPDATE***
Currently running OPNsense 26.7.6 (amd64) at Mon Oct 26 15:46:34 GMT 2026
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
Checking for upgrades (154 candidates): .......... done
Processing candidates (154 candidates): .. done
The following 21 package(s) will be affected (of 0 checked):
New packages to be INSTALLED:
cyrus-sasl-gssapi: 2.1.28 [OPNsense]
krb5: 1.22.2_3 [OPNsense]
Installed packages to be UPGRADED:
opnsense: 26.7.6 -> 26.7.7 [OPNsense]
opnsense-update: 26.7.6 -> 26.7.7 [OPNsense]
php85: 8.5.11 -> 8.5.12 [OPNsense]
php85-ctype: 8.5.11 -> 8.5.12 [OPNsense]
php85-curl: 8.5.11 -> 8.5.12 [OPNsense]
php85-dom: 8.5.11 -> 8.5.12 [OPNsense]
php85-filter: 8.5.11 -> 8.5.12 [OPNsense]
php85-gettext: 8.5.11 -> 8.5.12 [OPNsense]
php85-ldap: 8.5.11 -> 8.5.12 [OPNsense]
php85-mbstring: 8.5.11 -> 8.5.12 [OPNsense]
php85-pcntl: 8.5.11 -> 8.5.12 [OPNsense]
php85-pdo: 8.5.11 -> 8.5.12 [OPNsense]
php85-session: 8.5.11 -> 8.5.12 [OPNsense]
php85-simplexml: 8.5.11 -> 8.5.12 [OPNsense]
php85-sockets: 8.5.11 -> 8.5.12 [OPNsense]
php85-sqlite3: 8.5.11 -> 8.5.12 [OPNsense]
php85-xml: 8.5.11 -> 8.5.12 [OPNsense]
php85-zlib: 8.5.11 -> 8.5.12 [OPNsense]
Installed packages to be REINSTALLED:
openldap26-client-2.6.15_1 [OPNsense] (option changed: GSSAPI (off -> on))
Number of packages to be installed: 2
Number of packages to be upgraded: 18
Number of packages to be reinstalled: 1
The process will require 4 MiB more space.
22 MiB to be downloaded.
[ 1/21] Fetching php85-xml-8.5.12: .... done
[ 2/21] Fetching opnsense-update-26.7.7: ..... done
[ 3/21] Fetching php85-curl-8.5.12: ....... done
[ 4/21] Fetching php85-dom-8.5.12: .......... done
[ 5/21] Fetching php85-filter-8.5.12: .... done
[ 6/21] Fetching php85-simplexml-8.5.12: .... done
[ 7/21] Fetching php85-pdo-8.5.12: ........ done
[ 8/21] Fetching cyrus-sasl-gssapi-2.1.28: .... done
[ 9/21] Fetching krb5-1.22.2_3: ..
pkg-static: An error occurred while fetching package
Flushing temporary package files... done
Starting web GUI...done.
Partial update failure detected: report this error log to OPNsense.
No further actions will be taken. Please restart the update now.
***DONE***
#5
German - Deutsch / Re: Upgrade 26.7.5 > 26.7.6 od...
Last post by Hellgirl - Today at 04:10:36 PM@meyergru: Du bist der Beste! Genau das war das Problem! Diesen Config Fehler schleppe ich wohl seit Anbeginn meiner Installation mit und da die Reihenfolge nun scheinbar anders initialisiert, fiel das ganze erst ab Version 26.7.6 auf und führte erst ab dann zu dem besagten Phänomen.
Ich danke Dir vielmals für Deine Unterstützung, genauso natürlich @viragomann, welcher mich in die richtigen Analysen geführt hat!
Ich habe also nun nicht die IP aus dem LAN Interface entfernt, weil er mich dann ja mangels IP nicht speichern lässt. Ich habe stattdessen das ganze LAN Interface einfach deaktiviert (Haken bei enalbe Interface entfernt) und alle Problem sind damit nach einem Reboot verschwunden.
Die OPNsense ist wirklich ein hervorragendes Produkt, aber vielmehr lebt es von einer sehr starken Community, was man hier wieder gesehen hat :-)
Vielen Dank nochmal, dass Ihr Euch die Zeit genommen habt. Darauf wäre ich wohl alleine nicht gekommen. Ich war immer der Meinung, ein LAN Interface muss enabled sein. Muss es natürlich nicht, wenn darauf lauter VLAN´s laufen ;-)
Ich danke Dir vielmals für Deine Unterstützung, genauso natürlich @viragomann, welcher mich in die richtigen Analysen geführt hat!
Ich habe also nun nicht die IP aus dem LAN Interface entfernt, weil er mich dann ja mangels IP nicht speichern lässt. Ich habe stattdessen das ganze LAN Interface einfach deaktiviert (Haken bei enalbe Interface entfernt) und alle Problem sind damit nach einem Reboot verschwunden.
Die OPNsense ist wirklich ein hervorragendes Produkt, aber vielmehr lebt es von einer sehr starken Community, was man hier wieder gesehen hat :-)
Vielen Dank nochmal, dass Ihr Euch die Zeit genommen habt. Darauf wäre ich wohl alleine nicht gekommen. Ich war immer der Meinung, ein LAN Interface muss enabled sein. Muss es natürlich nicht, wenn darauf lauter VLAN´s laufen ;-)
#6
26.7 Series / Re: 26.7.7 — Security audit re...
Last post by Amodin - Today at 03:44:38 PMWell first, I don't know why you're using the Community Edition for business, but secondly, your list appears that it would be a FreeBSD issue and/or the providers of the packages that would need to update them, wouldn't it? OPN isn't the developer for packages/plugins and they are actually quite active in letting FreeBSD know about issues that are problematic.
Things like Unbound don't have to be used in the firewall. I don't use it on OPN, I maintain recursive DNS servers separate from OPN that use Unbound. Instead, you could use another package other than keeping it on the firewall, or alternative that's offered in OPN. Disabling SSH should be your go-to anyways, so it can't even be used, and only turn it on when/if you need it.
Franco is really, really good about getting updates out as quickly as they are available, but they aren't necessarily his responsibility for updating them.
And if you wait for every package to be patched, you're essentially going to play whack a mole, because there's always something found, something fixed. The PHP2Shell vulns have been around for 10 years, and they were only discovered because AI found them, not a hacktivist. So, you'd be waiting forever to put something into production.
Things like Unbound don't have to be used in the firewall. I don't use it on OPN, I maintain recursive DNS servers separate from OPN that use Unbound. Instead, you could use another package other than keeping it on the firewall, or alternative that's offered in OPN. Disabling SSH should be your go-to anyways, so it can't even be used, and only turn it on when/if you need it.
Franco is really, really good about getting updates out as quickly as they are available, but they aren't necessarily his responsibility for updating them.
And if you wait for every package to be patched, you're essentially going to play whack a mole, because there's always something found, something fixed. The PHP2Shell vulns have been around for 10 years, and they were only discovered because AI found them, not a hacktivist. So, you'd be waiting forever to put something into production.
#7
26.7 Series / Re: Crowdsec not starting (fou...
Last post by Amodin - Today at 03:34:29 PMYeah, I read that too which is what's perplexing and filtering doesn't seem to be consistent, because I have multiple DNS names in my exception alias, and one of them is this domain we are at, lol. But others simply won't go through. The only thing I can figure is what I saw in the referenced post about Crowdsec hosting in Ireland which I tend to receive a lot of port scanning and it's on my GeoIP blocklist. I confirmed it's GeoIP blocking, because I can disable the rule and everything is accessible.
I even forced the tables to update after making the changes in SSH, and it didn't update.
I'll double check the rule I have in place, as I believe that I have my Interface set to 'any' and see how that impacts my exceptions.
I even forced the tables to update after making the changes in SSH, and it didn't update.
I'll double check the rule I have in place, as I believe that I have my Interface set to 'any' and see how that impacts my exceptions.
#8
26.7 Series / 26.7.7 — Security audit report...
Last post by cfarachid - Today at 02:59:46 PMHello,
I am setting up OPNsense Community Edition 26.7.7 (amd64) for a small company. The firewall is still in a test environment and has not been deployed to production.
After updating, "Check for updates" reports:
There are no updates available on the selected mirror.
However, the security audit reports six vulnerable packages:
unbound-1.26.1
python313-3.13.15
ca_root_nss-3.130
brotli-1.2.0,1
curl-8.22.0
openssh-portable-10.5.p1_1,1
My current configuration:
Firmware type: Community
Mirror and flavour: default
Auxiliary packages repository: disabled
SSH: disabled
Unbound: enabled, listening on the LAN interface only
No manually configured WAN allow rules
Could you please clarify:
Are official fixes available, or scheduled, for these packages?
Do any of these findings have OPNsense-specific mitigations or applicability notes?
What temporary precautions should I take before deploying this firewall to production?
Should I wait for a package update, or is there an officially supported corrective procedure?
I would prefer to avoid unsupported package upgrades or adding external FreeBSD repositories.
Full security audit output:
***GOT REQUEST TO AUDIT SECURITY***
Currently running OPNsense 26.7.7 (amd64) at Mon Oct 26 13:41:10 UTC 2026
vulnxml file up-to-date
unbound-1.26.1 is vulnerable:
Unbound -- Multiple vulnerabilities
CVE: CVE-2026-97206
CVE: CVE-2026-50106
CVE: CVE-2026-96405
CVE: CVE-2026-109125
CVE: CVE-2026-35501
WWW: https://vuxml.freebsd.org/freebsd/0be28489-cd2f-11f1-8135-8447094a420f.html
python313-3.13.15 is vulnerable:
Python -- poplib module, when passed a user-controlled command, can have additional commands injected using newlines
CVE: CVE-2025-15367
WWW: https://vuxml.freebsd.org/freebsd/6d3488ae-2e0f-11f1-88c7-00a098b42aeb.html
ca_root_nss-3.130 is vulnerable:
ca_root_nss -- trusted root certificate from compromised CA eMudhra
WWW: https://vuxml.freebsd.org/freebsd/b755b277-cf12-11f1-bae2-3497f65b111b.html
brotli-1.2.0,1 is vulnerable:
brotli -- out-of-bounds write permits remote code execution
CVE: CVE-2026-111497
WWW: https://vuxml.freebsd.org/freebsd/f1e61d76-cdb6-11f1-b15e-589cfc104230.html
curl-8.22.0 is vulnerable:
Curl -- Multiple vulnerabilities
CVE: CVE-2026-107929
CVE: CVE-2026-107928
CVE: CVE-2026-94266
CVE: CVE-2026-94265
CVE: CVE-2026-92386
CVE: CVE-2026-92387
CVE: CVE-2026-92388
CVE: CVE-2026-92389
CVE: CVE-2026-92390
CVE: CVE-2026-92391
CVE: CVE-2026-92392
CVE: CVE-2026-86410
CVE: CVE-2026-86412
CVE: CVE-2026-86413
CVE: CVE-2026-86414
CVE: CVE-2026-86415
CVE: CVE-2026-87861
CVE: CVE-2026-87862
CVE: CVE-2026-87863
CVE: CVE-2026-87865
CVE: CVE-2026-87866
WWW: https://vuxml.freebsd.org/freebsd/14dab969-c797-11f1-a6ea-8447094a420f.html
openssh-portable-10.5.p1_1,1 is vulnerable:
OpenSSH -- Multiple vulnerabilities
WWW: https://vuxml.freebsd.org/freebsd/26fd839c-c338-11f1-a6ea-8447094a420f.html
6 problem(s) in 6 package(s) found.
***DONE***
Thank you for your help.
I am setting up OPNsense Community Edition 26.7.7 (amd64) for a small company. The firewall is still in a test environment and has not been deployed to production.
After updating, "Check for updates" reports:
There are no updates available on the selected mirror.
However, the security audit reports six vulnerable packages:
unbound-1.26.1
python313-3.13.15
ca_root_nss-3.130
brotli-1.2.0,1
curl-8.22.0
openssh-portable-10.5.p1_1,1
My current configuration:
Firmware type: Community
Mirror and flavour: default
Auxiliary packages repository: disabled
SSH: disabled
Unbound: enabled, listening on the LAN interface only
No manually configured WAN allow rules
Could you please clarify:
Are official fixes available, or scheduled, for these packages?
Do any of these findings have OPNsense-specific mitigations or applicability notes?
What temporary precautions should I take before deploying this firewall to production?
Should I wait for a package update, or is there an officially supported corrective procedure?
I would prefer to avoid unsupported package upgrades or adding external FreeBSD repositories.
Full security audit output:
***GOT REQUEST TO AUDIT SECURITY***
Currently running OPNsense 26.7.7 (amd64) at Mon Oct 26 13:41:10 UTC 2026
vulnxml file up-to-date
unbound-1.26.1 is vulnerable:
Unbound -- Multiple vulnerabilities
CVE: CVE-2026-97206
CVE: CVE-2026-50106
CVE: CVE-2026-96405
CVE: CVE-2026-109125
CVE: CVE-2026-35501
WWW: https://vuxml.freebsd.org/freebsd/0be28489-cd2f-11f1-8135-8447094a420f.html
python313-3.13.15 is vulnerable:
Python -- poplib module, when passed a user-controlled command, can have additional commands injected using newlines
CVE: CVE-2025-15367
WWW: https://vuxml.freebsd.org/freebsd/6d3488ae-2e0f-11f1-88c7-00a098b42aeb.html
ca_root_nss-3.130 is vulnerable:
ca_root_nss -- trusted root certificate from compromised CA eMudhra
WWW: https://vuxml.freebsd.org/freebsd/b755b277-cf12-11f1-bae2-3497f65b111b.html
brotli-1.2.0,1 is vulnerable:
brotli -- out-of-bounds write permits remote code execution
CVE: CVE-2026-111497
WWW: https://vuxml.freebsd.org/freebsd/f1e61d76-cdb6-11f1-b15e-589cfc104230.html
curl-8.22.0 is vulnerable:
Curl -- Multiple vulnerabilities
CVE: CVE-2026-107929
CVE: CVE-2026-107928
CVE: CVE-2026-94266
CVE: CVE-2026-94265
CVE: CVE-2026-92386
CVE: CVE-2026-92387
CVE: CVE-2026-92388
CVE: CVE-2026-92389
CVE: CVE-2026-92390
CVE: CVE-2026-92391
CVE: CVE-2026-92392
CVE: CVE-2026-86410
CVE: CVE-2026-86412
CVE: CVE-2026-86413
CVE: CVE-2026-86414
CVE: CVE-2026-86415
CVE: CVE-2026-87861
CVE: CVE-2026-87862
CVE: CVE-2026-87863
CVE: CVE-2026-87865
CVE: CVE-2026-87866
WWW: https://vuxml.freebsd.org/freebsd/14dab969-c797-11f1-a6ea-8447094a420f.html
openssh-portable-10.5.p1_1,1 is vulnerable:
OpenSSH -- Multiple vulnerabilities
WWW: https://vuxml.freebsd.org/freebsd/26fd839c-c338-11f1-a6ea-8447094a420f.html
6 problem(s) in 6 package(s) found.
***DONE***
Thank you for your help.
#9
26.7 Series / Re: os-net-snmp: OID for pendi...
Last post by DanielD - Today at 01:37:00 PMThanks Franco, that's really helpful context.
Comparing latest vs. current makes sense. We already pull the installed version via "Display Version in OID", so I'll compare that against new releases on our end.
Thanks again for the quick and detailed reply.
Comparing latest vs. current makes sense. We already pull the installed version via "Display Version in OID", so I'll compare that against new releases on our end.
Thanks again for the quick and detailed reply.
#10
26.1, 26,4 Series / Re: WireGuard gateway intermit...
Last post by petr.rampouch - Today at 01:13:33 PMHi, I'm seeing exactly what is described in this thread, but on a newer release, with more data. No fix found yet, only the same temporary workaround.
Version
- OPNsense 26.7.7-amd64
- FreeBSD 15.1-RELEASE-p4
- OpenSSL 3.5.9
- WAN: PPPoE
Setup
- Native WireGuard instance (wg0) to ProtonVPN, tunnel address 10.2.0.2/32, peer AllowedIPs 0.0.0.0/0, keepalive 25, "Disable routes" enabled
- Interface WG_Proton with static 10.2.0.2/32, gateway 10.2.0.1 (Far Gateway, not upstream), monitor IP 10.2.0.1
- Hybrid outbound NAT rule WG_Proton for one VLAN, policy routing (route-to wg0) on that VLAN only
- No one-to-one NAT, no port forwards, no other rule routes into wg0 (`pfctl -sr | grep wg0` shows only that VLAN)
Timeline
- Gateway worked for ~10 days, then (20 Oct) the peer stopped answering handshakes completely (Received 0). Changing to another Proton server fixed that.
- On the new server it worked for 6 days. On 26 Oct at 05:09 dpinger reported loss 12% -> 21% -> down (RTT unchanged at 6 ms before that). Gateway stayed down for hours.
- During that time the WireGuard handshake kept refreshing and traffic from clients behind the NAT rule worked normally (correct Proton exit IP, DNS via 10.2.0.1 worked, ping to 1.1.1.1 worked).
- Restarting the WireGuard instance did **not** help.
Symptoms (only for traffic originated by the firewall itself)
- `ping -S 10.2.0.2 10.2.0.1` = 100% loss. `curl --interface 10.2.0.2 https://1.1.1.1` (with a host route via wg0) also times out, so it is not only ICMP.
- `tcpdump -ni wg0 -Q out icmp` shows only the expected requests: `10.2.0.2 > 10.2.0.1` (dpinger id/seq).
- `tcpdump -ni wg0 -Q in icmp` shows replies with **both addresses rewritten**, same ICMP id/seq as the requests, TTL looks like a real remote reply:
`192.168.A.1 > 192.168.A.100: ICMP echo reply, id 27633, seq 68`
When the target was 1.1.1.1 the source stayed 1.1.1.1 but the destination was a LAN host (first 192.168.B.13, later 192.168.A.100); the destination changed for all flows at the same time.
- pf blocks these replies on the WireGuard interface as default deny / state violation.
- The LAN addresses shown are real hosts on my network (two ordinary LAN devices). They have only normal NAT states to WAN. They do not ping the firewall or send anything into wg0 (`-Q out` is clean).
- `pfctl -ss` has only the plain dpinger state (`icmp 10.2.0.2:<id> -> 10.2.0.1:8`), no NAT state mapping 192.168.x.x to 10.2.0.x. `pfctl -sn`/`-sr` contain no rule mentioning those hosts.
Workaround (same as in this thread, temporary)
After the traceroute (which goes through the tunnel) the ping starts working and the gateway turns green immediately. A traceroute to 10.2.0.1 itself did not help (no replies at all).
I don't see anything in my config that would explain the rewrite. Has anyone found what actually breaks it (pf, if_wg, dpinger?) or a permanent fix? Happy to provide more captures (`pfctl -vvss`, debug logs) when it happens again.
Version
- OPNsense 26.7.7-amd64
- FreeBSD 15.1-RELEASE-p4
- OpenSSL 3.5.9
- WAN: PPPoE
Setup
- Native WireGuard instance (wg0) to ProtonVPN, tunnel address 10.2.0.2/32, peer AllowedIPs 0.0.0.0/0, keepalive 25, "Disable routes" enabled
- Interface WG_Proton with static 10.2.0.2/32, gateway 10.2.0.1 (Far Gateway, not upstream), monitor IP 10.2.0.1
- Hybrid outbound NAT rule WG_Proton for one VLAN, policy routing (route-to wg0) on that VLAN only
- No one-to-one NAT, no port forwards, no other rule routes into wg0 (`pfctl -sr | grep wg0` shows only that VLAN)
Timeline
- Gateway worked for ~10 days, then (20 Oct) the peer stopped answering handshakes completely (Received 0). Changing to another Proton server fixed that.
- On the new server it worked for 6 days. On 26 Oct at 05:09 dpinger reported loss 12% -> 21% -> down (RTT unchanged at 6 ms before that). Gateway stayed down for hours.
- During that time the WireGuard handshake kept refreshing and traffic from clients behind the NAT rule worked normally (correct Proton exit IP, DNS via 10.2.0.1 worked, ping to 1.1.1.1 worked).
- Restarting the WireGuard instance did **not** help.
Symptoms (only for traffic originated by the firewall itself)
- `ping -S 10.2.0.2 10.2.0.1` = 100% loss. `curl --interface 10.2.0.2 https://1.1.1.1` (with a host route via wg0) also times out, so it is not only ICMP.
- `tcpdump -ni wg0 -Q out icmp` shows only the expected requests: `10.2.0.2 > 10.2.0.1` (dpinger id/seq).
- `tcpdump -ni wg0 -Q in icmp` shows replies with **both addresses rewritten**, same ICMP id/seq as the requests, TTL looks like a real remote reply:
`192.168.A.1 > 192.168.A.100: ICMP echo reply, id 27633, seq 68`
When the target was 1.1.1.1 the source stayed 1.1.1.1 but the destination was a LAN host (first 192.168.B.13, later 192.168.A.100); the destination changed for all flows at the same time.
- pf blocks these replies on the WireGuard interface as default deny / state violation.
- The LAN addresses shown are real hosts on my network (two ordinary LAN devices). They have only normal NAT states to WAN. They do not ping the firewall or send anything into wg0 (`-Q out` is clean).
- `pfctl -ss` has only the plain dpinger state (`icmp 10.2.0.2:<id> -> 10.2.0.1:8`), no NAT state mapping 192.168.x.x to 10.2.0.x. `pfctl -sn`/`-sr` contain no rule mentioning those hosts.
Workaround (same as in this thread, temporary)
Code Select
route add -host 1.1.1.1 10.2.0.1
traceroute -s 10.2.0.2 1.1.1.1
ping -c3 -S 10.2.0.2 10.2.0.1
route delete 1.1.1.1After the traceroute (which goes through the tunnel) the ping starts working and the gateway turns green immediately. A traceroute to 10.2.0.1 itself did not help (no replies at all).
I don't see anything in my config that would explain the rewrite. Has anyone found what actually breaks it (pf, if_wg, dpinger?) or a permanent fix? Happy to provide more captures (`pfctl -vvss`, debug logs) when it happens again.
