"Recent posts
#1
26.1, 26,4 Series / Re: New Source NAT - specific ...
Last post by Monviech (Cedrik) - Today at 11:32:00 AM #2
Development and Code Review / Re: vibecoded plugin
Last post by Patrick M. Hausen - Today at 11:17:00 AM"backup to the sshd"? Or is that a typo and you mean "backup to the ssd"? A backup on the same machine is not a backup. If the SSD fails - no backup.
So, yes, you can backup via SSH/SFTP to another machine. Which is one of the recommended ways.
I don't understand the question about the FS. There is really no reason to use anything but ZFS in 2026. Apart from very small embedded systems and/or VMs when the underlying VM storage is ZFS, already.
So, yes, you can backup via SSH/SFTP to another machine. Which is one of the recommended ways.
I don't understand the question about the FS. There is really no reason to use anything but ZFS in 2026. Apart from very small embedded systems and/or VMs when the underlying VM storage is ZFS, already.
#3
Development and Code Review / Re: vibecoded plugin
Last post by Vectralis - Today at 11:06:09 AMand if i for example want to backup to the sshd in the machine using that feature, and opnsense is installed on the ssd. does it still need to be zfs then? or is ufs also alright?
#4
German - Deutsch / WireGuard-Tunnel ohne Internet...
Last post by Shoux - Today at 11:01:05 AMHallo zusammen,
ich stoße seit dem letzten größeren Update auf ein reproduzierbares, aber schwer greifbares Problem und komme bei der Ursachensuche nicht weiter.
Setup:
Appliance: Deciso DEC2687
OPNsense-Version: OPNsense 26.4.1p1_3-amd64
WireGuard als Site-to-Client- bzw. VPN-Tunnel im Einsatz (läuft im Normalbetrieb absolut stabil)
Das Problem:
Nach jedem Update hat der WireGuard-Tunnel zunächst keinen Internetzugang mehr. Der Tunnel selbst kommt hoch (Handshake ist da), aber der Traffic über den Tunnel läuft nicht bzw. es geht kein Datenverkehr ins Internet.
Der Workaround, den ich gefunden habe:
Damit der Tunnel wieder Internet hat, muss ich manuell einen Firewall-Reload erzwingen. Konkret hilft eines von beiden:
Eine fiktive Firewallregel anlegen, wieder löschen und anschließend ,,Apply/Speichern" klicken – danach läuft der Traffic wieder.
Oder die WireGuard-bezogene Regel einmal deaktivieren und wieder aktivieren (ebenfalls mit anschließendem Anwenden).
Beides läuft im Grunde auf dasselbe hinaus: Es scheint ein Regelwerk-/Firewall-Reload nötig zu sein, damit der Tunnel wieder Internet bekommt. Ohne diesen Eingriff bleibt er nach dem Update ,,tot", obwohl an der Konfiguration nichts geändert wurde.
Was mich stutzig macht:
Das Verhalten tritt erst seit dem letzten großen Update auf – vorher gab es das Problem nach Updates nicht. Es riecht für mich nach einem Reihenfolge-/Timing-Problem beim Regel- oder NAT-Reload nach dem Reboot (evtl. dass die WireGuard-Interfaces/Regeln beim Boot nicht sauber mit dem Firewall-Regelwerk ,,verheiratet" werden), aber ich weiß ehrlich gesagt nicht, wo ich sinnvoll ansetzen soll.
Meine Fragen:
Kennt jemand dieses Verhalten seit dem letzten Update und weiß, ob es sich um einen bekannten Bug handelt?
Wo würdet ihr mit der Fehlersuche ansetzen (Logs, NAT-Regeln, Interface-Reihenfolge beim Boot, Gateway-Monitoring)?
Gibt es eine saubere Lösung, damit der Firewall-Reload nach einem Update automatisch korrekt durchläuft, ohne dass ich manuell nachhelfen muss?
Über Hinweise wäre ich sehr dankbar. Bei Bedarf reiche ich gerne Logs oder Konfig-Auszüge (natürlich anonymisiert) nach.
Danke und viele Grüße
ich stoße seit dem letzten größeren Update auf ein reproduzierbares, aber schwer greifbares Problem und komme bei der Ursachensuche nicht weiter.
Setup:
Appliance: Deciso DEC2687
OPNsense-Version: OPNsense 26.4.1p1_3-amd64
WireGuard als Site-to-Client- bzw. VPN-Tunnel im Einsatz (läuft im Normalbetrieb absolut stabil)
Das Problem:
Nach jedem Update hat der WireGuard-Tunnel zunächst keinen Internetzugang mehr. Der Tunnel selbst kommt hoch (Handshake ist da), aber der Traffic über den Tunnel läuft nicht bzw. es geht kein Datenverkehr ins Internet.
Der Workaround, den ich gefunden habe:
Damit der Tunnel wieder Internet hat, muss ich manuell einen Firewall-Reload erzwingen. Konkret hilft eines von beiden:
Eine fiktive Firewallregel anlegen, wieder löschen und anschließend ,,Apply/Speichern" klicken – danach läuft der Traffic wieder.
Oder die WireGuard-bezogene Regel einmal deaktivieren und wieder aktivieren (ebenfalls mit anschließendem Anwenden).
Beides läuft im Grunde auf dasselbe hinaus: Es scheint ein Regelwerk-/Firewall-Reload nötig zu sein, damit der Tunnel wieder Internet bekommt. Ohne diesen Eingriff bleibt er nach dem Update ,,tot", obwohl an der Konfiguration nichts geändert wurde.
Was mich stutzig macht:
Das Verhalten tritt erst seit dem letzten großen Update auf – vorher gab es das Problem nach Updates nicht. Es riecht für mich nach einem Reihenfolge-/Timing-Problem beim Regel- oder NAT-Reload nach dem Reboot (evtl. dass die WireGuard-Interfaces/Regeln beim Boot nicht sauber mit dem Firewall-Regelwerk ,,verheiratet" werden), aber ich weiß ehrlich gesagt nicht, wo ich sinnvoll ansetzen soll.
Meine Fragen:
Kennt jemand dieses Verhalten seit dem letzten Update und weiß, ob es sich um einen bekannten Bug handelt?
Wo würdet ihr mit der Fehlersuche ansetzen (Logs, NAT-Regeln, Interface-Reihenfolge beim Boot, Gateway-Monitoring)?
Gibt es eine saubere Lösung, damit der Firewall-Reload nach einem Update automatisch korrekt durchläuft, ohne dass ich manuell nachhelfen muss?
Über Hinweise wäre ich sehr dankbar. Bei Bedarf reiche ich gerne Logs oder Konfig-Auszüge (natürlich anonymisiert) nach.
Danke und viele Grüße
#5
German - Deutsch / IPv6 - Giga5 / SWN / Stadtwerk...
Last post by muldini - Today at 10:38:43 AMHallo,
wer nach der Kombination im Titel sucht wird einige Threads finden, in denen nach Informationen gefragt wird, wie IPv6 einzurichten ist. Üblicherweise bleibt am Ende das Problem, dass zwar ein /56 Prefix zugewiesen wird, das WAN Interface selbst jedoch ohne Adresse verbleibt.
Nach ein wenig Probieren lässt sich das durch Angabe einer optionalen prefix ID beheben.
Dieses Setup funktioniert bei mir:
IPv4 Configuration Type: PPPoE
IPv6 Configuration Type: DHCPv6
Use VLAN priority: Disabled
Configuration Mode: Basic
Prefix delegation size: 56
Request prefix only: [X]
Request DNS configuration: []
Send prefix hint [X]
Send rapid commit [X]
Optional prefix ID: 0 <- Diese Angabe führte dazu, dass dem WAN Interface selbst eine Adresse zugewiesen wurde.
Optional interface ID: []
Optional prefix IAID: []
Hoffe das hilft dem einen oder der anderen.
Viele Grüße
wer nach der Kombination im Titel sucht wird einige Threads finden, in denen nach Informationen gefragt wird, wie IPv6 einzurichten ist. Üblicherweise bleibt am Ende das Problem, dass zwar ein /56 Prefix zugewiesen wird, das WAN Interface selbst jedoch ohne Adresse verbleibt.
Nach ein wenig Probieren lässt sich das durch Angabe einer optionalen prefix ID beheben.
Dieses Setup funktioniert bei mir:
IPv4 Configuration Type: PPPoE
IPv6 Configuration Type: DHCPv6
Use VLAN priority: Disabled
Configuration Mode: Basic
Prefix delegation size: 56
Request prefix only: [X]
Request DNS configuration: []
Send prefix hint [X]
Send rapid commit [X]
Optional prefix ID: 0 <- Diese Angabe führte dazu, dass dem WAN Interface selbst eine Adresse zugewiesen wurde.
Optional interface ID: []
Optional prefix IAID: []
Hoffe das hilft dem einen oder der anderen.
Viele Grüße
#6
26.1, 26,4 Series / Re: New Source NAT - specific ...
Last post by dseven - Today at 10:18:12 AMI guess the issue is that the new interface won't allow specifying a target port range when the protocol is "any", so I suppose you'd have to create one rule for TCP/UDP (with port range) and another rule for "any", and use sequence numbers to ensure that the TCP/UDP one comes first? Seems kindof unnecessarily cumbersome?
Curiously PF shows a port range even for ICMP-specific rules:
Curiously PF shows a port range even for ICMP-specific rules:
Code Select
root@opntest1:~ # pfctl -s nat | grep icmp
nat on igc1 inet proto icmp from (igc0:network) to any -> (igc1:0) port 1024:65535
root@opntest1:~ #
#7
26.1, 26,4 Series / Re: (os-sftp-backup) Backup-Fi...
Last post by SchengFui - Today at 10:12:50 AMHello Cookiemonster,
thank you for your reply!
thank you for your reply!
#8
26.1, 26,4 Series / Re: New Source NAT - specific ...
Last post by Monviech (Cedrik) - Today at 09:29:23 AMI don't understand, only UDP and TCP do have port numbers. ICMP has types. Other protocols don't have port numbers or use different schematics.
#9
26.1, 26,4 Series / New Source NAT - specific port...
Last post by Ametite - Today at 09:10:49 AMGood morning all, I'm here to report a missing configuration from old outbound rules to new one. I know it's something that is my specific need/implementation but I put here some contest.
My ISP (Iliad Italia) uses MAP-E (not supported from OPNsense), but I use a trick and I connect the ISP router LAN ("router mode, no NAT") to the OPNSense WAN, then I know from ISP router GUI the port range (1:4) that is assigned to me (eg 24576:32767).
That range port was configured in the old outbound NAT, that allowed to set outbound interface WAN (with its IP address) AND the port range. The new Source NAT does not allow you to set the port range without choosing the TCP/UDP option, but - in this way - every protocol that is not TCP/UDP will not work (ICMP, etc...).
Now I have to roll back to old rules and all is working again.
Do you know if this can be implemented, or if I'm missing something?
Thanks a lot.
My ISP (Iliad Italia) uses MAP-E (not supported from OPNsense), but I use a trick and I connect the ISP router LAN ("router mode, no NAT") to the OPNSense WAN, then I know from ISP router GUI the port range (1:4) that is assigned to me (eg 24576:32767).
That range port was configured in the old outbound NAT, that allowed to set outbound interface WAN (with its IP address) AND the port range. The new Source NAT does not allow you to set the port range without choosing the TCP/UDP option, but - in this way - every protocol that is not TCP/UDP will not work (ICMP, etc...).
Now I have to roll back to old rules and all is working again.
Do you know if this can be implemented, or if I'm missing something?
Thanks a lot.
#10
26.1, 26,4 Series / Re: Problem with shutdown/rebo...
Last post by mrzaz - Today at 08:37:26 AMI have some dynamic data where most of the time it is limited but at certain times I run backups from Synology to external systems
and at other times I have a friend who backups to my storage.
Unfortunatley I had to revert to non-VM now as I hade a lot of other issues caused me to pause the Unraid and use same machine
as standalone OpnSense. I will check if I still get same issue.
I do have 1000/1000 connection and at times both runs much UL and sometimes much DL to system that has similar speeds as me.
//Dan Lundqvist
and at other times I have a friend who backups to my storage.
Unfortunatley I had to revert to non-VM now as I hade a lot of other issues caused me to pause the Unraid and use same machine
as standalone OpnSense. I will check if I still get same issue.
I do have 1000/1000 connection and at times both runs much UL and sometimes much DL to system that has similar speeds as me.
//Dan Lundqvist
