"Recent posts
#1
26.7 Series / Android IPv6 issues: In my cas...
Last post by astronaut - Today at 05:49:25 PMHi,
there are numerous posts on Android IPv6 issues (lost access, lost gateway, timeout issues etc.) in the OPNsense forum:
https://forum.opnsense.org/index.php?topic=51298.msg262792#msg262792
https://forum.opnsense.org/index.php?topic=43034.msg213764#msg213764
https://forum.opnsense.org/index.php?topic=53043.0
There is an extensive how-to from meyerguru on IPv6 topics in general:
https://forum.opnsense.org/index.php?topic=45822.0
I myself was plagued from annoying IPv6 issues on my Android smartphone (the only Android device in my network) for some time: My device lost its IPv6 connection after some time, and some apps didn't work or timed out. A new connection (e. g. by turning WiFi off/on) solved this issue temporarily. All other operating systems (iOS, Linux, Windows, FreeBSD) are working normally. After having read the above posts, I blamed OPNsense and/or FreeBSD for these issues. I tried a lot of different things to solve this on the OPNsense side, with no success. Turns out this was wrong, in my case, it was an Android driver issue.
My Android device is a Fairphone 6. I found a thread in the Fairphone forum where a lot of users complained about IPv6 issues:
https://forum.fairphone.com/t/dns-over-tls-ipv6-issues-apps-dont-load-data-over-wifi/130519/542
It's a very long thread, but the issues seem at least similar to what I have read in the OPNsense forum posts. It seems that there is an issue with the Android WiFi driver:
https://github.com/LineageOS/android_device_fairphone_FP6/commit/768592057b3c1a457f7a0134ef157336f01319ee
Today, a firmware update for the Fairphone 6 was released, which seems to solve the IPv6 issues on my device.
Now, I am not saying that all mentioned IPv6 issues in a OPNsense managed IPv6 network stem from faulty Android drivers, but I wanted to point out that this is at least a possibility to consider.
I hope this helps.
Best regards,
Astronaut
P.S. OPNsense rocks!
there are numerous posts on Android IPv6 issues (lost access, lost gateway, timeout issues etc.) in the OPNsense forum:
https://forum.opnsense.org/index.php?topic=51298.msg262792#msg262792
https://forum.opnsense.org/index.php?topic=43034.msg213764#msg213764
https://forum.opnsense.org/index.php?topic=53043.0
There is an extensive how-to from meyerguru on IPv6 topics in general:
https://forum.opnsense.org/index.php?topic=45822.0
I myself was plagued from annoying IPv6 issues on my Android smartphone (the only Android device in my network) for some time: My device lost its IPv6 connection after some time, and some apps didn't work or timed out. A new connection (e. g. by turning WiFi off/on) solved this issue temporarily. All other operating systems (iOS, Linux, Windows, FreeBSD) are working normally. After having read the above posts, I blamed OPNsense and/or FreeBSD for these issues. I tried a lot of different things to solve this on the OPNsense side, with no success. Turns out this was wrong, in my case, it was an Android driver issue.
My Android device is a Fairphone 6. I found a thread in the Fairphone forum where a lot of users complained about IPv6 issues:
https://forum.fairphone.com/t/dns-over-tls-ipv6-issues-apps-dont-load-data-over-wifi/130519/542
It's a very long thread, but the issues seem at least similar to what I have read in the OPNsense forum posts. It seems that there is an issue with the Android WiFi driver:
https://github.com/LineageOS/android_device_fairphone_FP6/commit/768592057b3c1a457f7a0134ef157336f01319ee
Today, a firmware update for the Fairphone 6 was released, which seems to solve the IPv6 issues on my device.
Now, I am not saying that all mentioned IPv6 issues in a OPNsense managed IPv6 network stem from faulty Android drivers, but I wanted to point out that this is at least a possibility to consider.
I hope this helps.
Best regards,
Astronaut
P.S. OPNsense rocks!
#2
German - Deutsch / OPNcentral hält sich nicht an ...
Last post by Stephan M. - Today at 04:58:50 PMHallo liebe OPNsense-Community,
ich bin auf der Suche nach Hilfe in folgender Angelegenheit.
OPNsense hinter einem Proxy ist soweit ich es recherchieren konnte, eher ein schwieriges Thema, da es sich an verschiedenen Stellen angeben lässt, aber nicht jeder Service diese Settings unbedingt auch nutzt. Wir benötigen den Proxy aktuell für Updates sowie den Upload von Backups in eine Nextcloud Instanz. Dies funktioniert aktuell auch soweit.
Aktuell setzen wir den Proxy an folgenden Stellen:
In der Konsole /root/proxy.sh, für Zugriffe wie wget o.ä.
# /usr/local/opnsense/service/conf/configd.conf.d/proxy.conf
# /usr/local/etc/pkg.conf
Das Problem besteht nun darin, dass unsere OPNcentral Instanz (10.18.23.250) die API-Anfragen, die für die Provisionierung der Firewalls rausgehen, auch über den Proxy schickt. Daher habe ich die Einstellungen in der # /usr/local/opnsense/service/conf/configd.conf um no_proxy ergänzt.
Rufe ich nun über die Console
Im Livelog korrekt zu sehen, kommt die Anfrage von 10.18.23.250 und geht zu 10.18.11.251 auf Port 4444:
You cannot view this attachment.
Setze ich im OPNcentral über die WebUI einen Diagnoseping ab, kommt der an und wird auch im Log korrekt dargestellt.
Führe ich nun jedoch im OPNcentral über die WebUI eine Provisionierung aus oder rufe die Firewalls über das zentrale Management ab, wird die Kommunikation scheinbar durch den Proxy geleitet und es antwortet (glücklicherweise) ein entfernter Router und schickt die Anfrage zurück. Damit stimmt die Absenderadresse natürlich nicht mehr und es hat etwas gedauert zu verstehen, warum ein Zugriff nicht erfolgreich stattfinden konnte. (Hier war die Firewallregel natürlich nicht darauf ausgelegt). Im Screenshot zu sehen ist als Quell-IP nun eine 10.19.241.242. Damit hat die Anfrage das lokale Netz verlassen und ist über einen entfernten Proxy wieder zu uns zurück.
You cannot view this attachment.
Nun meine Frage: Gibt es noch eine Stelle, an der Proxysettings und Ausnahmen eingestellt werden können? Übersehe ich etwas? Mache ich etwas falsch?
Vielen Dank vorab!
ich bin auf der Suche nach Hilfe in folgender Angelegenheit.
OPNsense hinter einem Proxy ist soweit ich es recherchieren konnte, eher ein schwieriges Thema, da es sich an verschiedenen Stellen angeben lässt, aber nicht jeder Service diese Settings unbedingt auch nutzt. Wir benötigen den Proxy aktuell für Updates sowie den Upload von Backups in eine Nextcloud Instanz. Dies funktioniert aktuell auch soweit.
Aktuell setzen wir den Proxy an folgenden Stellen:
In der Konsole /root/proxy.sh, für Zugriffe wie wget o.ä.
Code Select
PROXY_URL="http://10.19.241.33:3128"
KEINPROXY="10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.unseredomain.de"
HTTP_PROXY=$PROXY_URL
HTTPS_PROXY=$PROXY_URL
FTP_PROXY=$PROXY_URL
NO_PROXY=$KEINPROXY
http_proxy=$PROXY_URL
https_proxy=$PROXY_URL
ftp_proxy=$PROXY_URL
no_proxy=$KEINPROXY
export HTTP_PROXY HTTPS_PROXY FTP_PROXY NO_PROXY http_proxy https_proxy ftp_proxy no_proxy
# /usr/local/opnsense/service/conf/configd.conf.d/proxy.conf
Code Select
[environment]
HTTP_PROXY=http://10.19.241.33:3128
HTTPS_PROXY=http://10.19.241.33:3128
http_proxy=http://10.19.241.33:3128
https_proxy=http://10.19.241.33:3128
FTP_PROXY=http://10.19.241.33:3128
ftp_proxy=http://10.19.241.33:3128
NO_PROXY="10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.unseredomain.de"
no_proxy="10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.unseredomain.de"
# /usr/local/etc/pkg.conf
Code Select
PKG_ENV {
http_proxy = "http://10.19.241.33:3128"
https_proxy = "http://10.19.241.33:3128"
ftp_proxy = "http://10.19.241.33:3128"
}
Das Problem besteht nun darin, dass unsere OPNcentral Instanz (10.18.23.250) die API-Anfragen, die für die Provisionierung der Firewalls rausgehen, auch über den Proxy schickt. Daher habe ich die Einstellungen in der # /usr/local/opnsense/service/conf/configd.conf um no_proxy ergänzt.
Rufe ich nun über die Console
Code Select
curl -v https://firewall1.unseredomain.de:4444/ auf, klappt das wie gewünscht und Code Select
curl meldet brav, dass es die Proxy Settings aus dem Environment verwendet:Code Select
root@opncentral:~ # curl -v https://firewall1.unseredomain.de:4444/
* Uses proxy env variable no_proxy == '10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,.unseredomain.de'
* Host firewall1.unseredomain.de:4444 was resolved.
* IPv6: (none)
* IPv4: 10.18.11.251
* Trying 10.18.11.251:4444...
* ALPN: curl offers h2,http/1.1
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* SSL Trust Anchors:
* CApath: /etc/ssl/certs
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384 / X25519 / RSASSA-PSS
* ALPN: server accepted h2
* Server certificate:
Im Livelog korrekt zu sehen, kommt die Anfrage von 10.18.23.250 und geht zu 10.18.11.251 auf Port 4444:
You cannot view this attachment.
Setze ich im OPNcentral über die WebUI einen Diagnoseping ab, kommt der an und wird auch im Log korrekt dargestellt.
Führe ich nun jedoch im OPNcentral über die WebUI eine Provisionierung aus oder rufe die Firewalls über das zentrale Management ab, wird die Kommunikation scheinbar durch den Proxy geleitet und es antwortet (glücklicherweise) ein entfernter Router und schickt die Anfrage zurück. Damit stimmt die Absenderadresse natürlich nicht mehr und es hat etwas gedauert zu verstehen, warum ein Zugriff nicht erfolgreich stattfinden konnte. (Hier war die Firewallregel natürlich nicht darauf ausgelegt). Im Screenshot zu sehen ist als Quell-IP nun eine 10.19.241.242. Damit hat die Anfrage das lokale Netz verlassen und ist über einen entfernten Proxy wieder zu uns zurück.
You cannot view this attachment.
Nun meine Frage: Gibt es noch eine Stelle, an der Proxysettings und Ausnahmen eingestellt werden können? Übersehe ich etwas? Mache ich etwas falsch?
Vielen Dank vorab!
#3
Dutch - Nederlands / Chromebook van school op thuis...
Last post by MaartenVT - Today at 04:27:26 PMDag iedereen
Misschien weten jullie raad.
Mijn zoon heeft een Chromebook van school, voor "schoolwerk"... Wanneer ik de DNS-over-HTTPS (DoH) probeer uit te schakelen, wil de Chromebook helemaal niet meer op internet. Geen connectie meer.
Maar als ik de DOH niet uitschakel, omzeilt de Chromebook mijn beveiliging via mijn eigen DNS (Adguard home).
Hoe zorg ik ervoor dat de Chromebook wél op internet kan maar dan wél over mijn DNS en m'n eigen beveiliging?
Alvast bedankt om mee te denken.
Groeten
Maarten.
Misschien weten jullie raad.
Mijn zoon heeft een Chromebook van school, voor "schoolwerk"... Wanneer ik de DNS-over-HTTPS (DoH) probeer uit te schakelen, wil de Chromebook helemaal niet meer op internet. Geen connectie meer.
Maar als ik de DOH niet uitschakel, omzeilt de Chromebook mijn beveiliging via mijn eigen DNS (Adguard home).
Hoe zorg ik ervoor dat de Chromebook wél op internet kan maar dan wél over mijn DNS en m'n eigen beveiliging?
Alvast bedankt om mee te denken.
Groeten
Maarten.
#4
German - Deutsch / Re: [Hardware] Temperaturen
Last post by mooh - Today at 03:28:13 PMIch würde mit dem smartctl plugin mal nachsehen wie die SSD gebraucht wird. Wichtig ist die Info bei "Data Units Written:". Daraus kann man dann grob die noch verbleibende Lebensdauer der SSD abschätzen. Im Zweifelsfall RRD abschalten und unter Systemeinstellungen die RAM Disk aktivieren, um Schreibzugriffe zu minimieren. Unter "Available Spare" sollte immer 100% stehen, andernfalls ist das Ende schon in Sicht.
Unter "Supported LBA Sizes" wird die "natürliche" Blockgröße der SDD durch ein "+" angezeigt. Bei vielen SSDs ist aus Kompatibilitätsgründen jedoch gerne mal 512 Bytes eingestellt, obwohl 4096 die bessere Wahl wäre. Insbesondere in Kombination mit ZFS als Dateisystem sollte man das mal durchdenken, damit Write-Amplification vermieden wird. Das ist ein relativ weites Feld, das ich hier nicht erklären möchte.
Smartctl zeigt außerdem in "Warning Comp. Temperature Time:" und "Critical Comp. Temperature Time:" an, wie lange die SSD außerhalb ihrer Wohlfühlzone betrieben wurde.
Unter "Supported LBA Sizes" wird die "natürliche" Blockgröße der SDD durch ein "+" angezeigt. Bei vielen SSDs ist aus Kompatibilitätsgründen jedoch gerne mal 512 Bytes eingestellt, obwohl 4096 die bessere Wahl wäre. Insbesondere in Kombination mit ZFS als Dateisystem sollte man das mal durchdenken, damit Write-Amplification vermieden wird. Das ist ein relativ weites Feld, das ich hier nicht erklären möchte.
Smartctl zeigt außerdem in "Warning Comp. Temperature Time:" und "Critical Comp. Temperature Time:" an, wie lange die SSD außerhalb ihrer Wohlfühlzone betrieben wurde.
#5
26.7 Series / Re: OPNsense 26.7.4 - VLAN tra...
Last post by nero355 - Today at 03:17:58 PMI have got a question that really bugs me :
Why would you do this =>
What is the purpose of such a setup ??
Why would you do this =>
Quote from: merrins63 on September 28, 2026, 01:38:52 PMI also have an Intel i226 2.5 GbE trunk, with corresponding VLAN interfaces bridged to the X550/LAGG VLAN interfaces.Aren't you effectively Bridging 2x 2,5 Gbps with 2 x 10 Gbps ?!
What is the purpose of such a setup ??
#6
26.7 Series / Re: IPv6 RA for Android workin...
Last post by mooh - Today at 02:54:58 PMI looked at this a while ago but didn't really work through it, so I don't have hands-on experience. My understanding was that the RA setting in General is just a global setting. Actual announcements need to be configured in the DHCP ranges.
#7
German - Deutsch / Re: [Hardware] Temperaturen
Last post by JamesFrisch - Today at 02:10:02 PMQuoteWohl eher Ausfall kurz nach Ablauf der Garantiezeit vs. Ausfall nach 10 Jahren.Auch so eine gefühlte Wahrheit? :)
QuoteAußerdem sind die Zeiten, in denen 5 Jahre Garantie bei Festplatten nahezu Standard waren, lange vorbei.Zeig mir eine Enterprise/NAS disk, welche nicht mit 5y Garantie daherkommt.
Bei SSD ist es noch krasser, alles was nicht absoluter Schmutz ist kommt sogar im Consumer Bereich mit 5 Jahren.
Keine Ahnung wie die auf die Idee kommst, 5y Garantie wäre ein Ding der Vergangenheit. Das Gegenteil ist der Fall.
#8
26.7 Series / Re: OPNsense 26.7.4 - VLAN tra...
Last post by Patrick M. Hausen - Today at 01:20:12 PMThese definitions match the interface configuration. I am out of ideas ... er ... one moment ...
Did you check this option?
If you did not that would perfectly explain your observed symptoms.
ISC creates the necessary firewall rules for DHCP to work by default, if I remember correctly. For Kea that's optional, because some users complained that OPNsense should not create any rules automatically giving full control to the admin.
Did you check this option?
If you did not that would perfectly explain your observed symptoms.
ISC creates the necessary firewall rules for DHCP to work by default, if I remember correctly. For Kea that's optional, because some users complained that OPNsense should not create any rules automatically giving full control to the admin.
#9
26.7 Series / Re: OPNsense 26.7.4 - VLAN tra...
Last post by merrins63 - Today at 01:09:31 PMThanks, good spot.
Those two /29 entries are unrelated to the issue I'm troubleshooting. They are temporary device/transit networks on this test firewall and were not involved in the DHCP testing.
The relevant test networks are:
VLAN 10
Subnet: 10.100.10.0/24
Gateway: 10.100.10.1
Bridge: bridge0
VLAN 15
Subnet: 10.100.15.0/24
Gateway: 10.100.15.1
Bridge: bridge1
VLAN 15 has been my primary troubleshooting network. With the same bridge configuration and client:
Kea DHCP -> client fails to obtain/use a lease
ISC DHCP -> client successfully receives 10.100.15.10/24
Static IP -> connectivity to 10.100.15.1 works
So please focus primarily on the 10.100.10.0/24 and 10.100.15.0/24 Kea configuration.
I'll correct the two /29 definitions separately. Thanks for spotting them
Those two /29 entries are unrelated to the issue I'm troubleshooting. They are temporary device/transit networks on this test firewall and were not involved in the DHCP testing.
The relevant test networks are:
VLAN 10
Subnet: 10.100.10.0/24
Gateway: 10.100.10.1
Bridge: bridge0
VLAN 15
Subnet: 10.100.15.0/24
Gateway: 10.100.15.1
Bridge: bridge1
VLAN 15 has been my primary troubleshooting network. With the same bridge configuration and client:
Kea DHCP -> client fails to obtain/use a lease
ISC DHCP -> client successfully receives 10.100.15.10/24
Static IP -> connectivity to 10.100.15.1 works
So please focus primarily on the 10.100.10.0/24 and 10.100.15.0/24 Kea configuration.
I'll correct the two /29 definitions separately. Thanks for spotting them
#10
26.7 Series / Re: OPNsense 26.7.4 - VLAN tra...
Last post by Patrick M. Hausen - Today at 01:02:26 PMCode Select
[...]
"subnet": "10.100.14.1/29",
[...]
"subnet": "10.100.23.1/29",
[...]
These are not valid subnets. 10.100.14.0/29 and 10.100.23.ü/29 would be if that is what is intended.
