Recent posts

#1
German - Deutsch / Re: Verstädnisfrage Wireguard ...
Last post by meyergru - Today at 03:12:24 PM
Es gibt eine "Abarbeitungsreihenfolge" der Regeln, siehe: https://docs.opnsense.org/manual/firewall.html#processing-order

Die greift noch vor der Reihenfolge innerhalb der dort dargestellten Regeltypen. Somit würde eine "Allow" quick-Regel in den Floating Regeln immer vor jeder eventuellen "Block"-Regel im Interface ziehen, mithin kannst Du in den Interface-Regeln nichts mehr verbieten, was in den Floating-Regeln erlaubt wird. Die Floating-Regel feuert und dann ist der Rest egal. Deswegen beschränke ich Floating-Regeln meist auf eine Interface-Gruppe "LOCAL".
#2
General Discussion / Re: FIB/VRF support in OPNsens...
Last post by pfry - Today at 02:55:33 PM
Quote from: AdSchellevis on Today at 09:00:11 AMNot at all easy to integrate (lots of moving parts)[...]

In context I wouldn't consider it particularly difficult, but it's not basic. Identifying all of the affected elements would be a pain, especially if they're not well encapsulated (as nobody does that).

Quote from: bimbar on Today at 12:05:38 PMI also think that VRFs are not that useful in firewalls[...]

I'd disagree there. But I will grant that it's a bit of a niche feature, and not popular with the OPNsense base. Part of the reason for that is that for most scenarios rule-based forwarding would work about as well; another part is the chicken/egg problem, but that merely partially contextualizes the lack of demand. From a cost-benefit value standpoint it looks pretty dead.
#3
General Discussion / Unexplained behavior - no inte...
Last post by headbanger - Today at 02:30:23 PM
I am not new to opnsense.  I have been using it almost a year.  Yesterday I made a change that caused all internet access to be lost on my vlans.  Let me first explain my setup.  On my box the first physical port is the LAN interface.  It is used only to administer opnsense and normally has nothing connected.  The second is the WAN port.  It connects directly to the ISP's modem.  The third port connects to my old consumer WiFi mesh network.  I use it for guest access and phones.  The third connects to an access point and is used for most iot devices.  The fourth is my vlans.  It connects to an ethernet power adapter.  Then at various points in the house I have other power adapters that connect to smart switches.  In my office I have one vlan for my wired linux computers, another for my wired windows computers.  In my wife's office I connect to an access point for her windows laptap.  The wired computers do not use dhcp, the laptop does.  Opnsense captures all port 53 requests and routes them to 127.0.0.1.  Unbound then routes them over DOT to a DNS provider.

Yesterday my daughter was visiting and working.  Her employer uses Microsoft teams.  I had to open some ports on the guest interface so she could work.  She was happy. Later my wife reported she had no internet access.  Hugh? I didn't change any of the vlan interfaces.  To get her going I connected her computer to the phone WiFi.  Later I noticed none of the vlans in my office had internet either.  Although it shouldn't matter I disbled the rule I added earlier in the day on the guest interface and vola! Internet access returned to all the vlan interfaces.  Hugh?! I then reactivated the rule and internet access was still there.  Now I may not be a newbe but I am no expert either so I figured let me put this out there to see if anyone out there has any idea what happened.
#4
German - Deutsch / Re: Verstädnisfrage Wireguard ...
Last post by wirehire - Today at 02:21:36 PM
Kannst du das mit der flaoting regel noch mal erklären? wenn du jetzt zb floating regel src 10.10.10.10 erlaubt web ports. dann würde das ja auch zb durch den tunnel gehen, weil sie zuerst greift. oder sehe ich das falsch?

und ja , absolut richtig immer auf den wg interfaces / gruppen, ein block , damit egal was ein anderer freiguibt , es nicht ohne extra regel anzulegen , geblockt wird.
#5
German - Deutsch / Re: Verstädnisfrage Wireguard ...
Last post by meyergru - Today at 01:57:03 PM
Quote from: wirehire on Today at 01:45:36 PMDazu auf dem WG interface ein Block, sodass, auch wenn auf der einen seite eine falsche flaoting regel vorhanden wäre, es nicht auf der remote Seite, das wg interface passieren würde!

Kritisch wäre, wenn auf "Deiner" Seite eine Floating-Regel etwas erlaubt, weil die vor den Interface-Regeln greifen. Wie gesagt, um das zu verhindern, nutze ich immer eine Interface-Gruppe für die "Nicht-WG" Interfaces (=VLANs) und nutze die in den Floating Regeln.

Ansonsten immer am lokalen Ende des WG-Tunnels filtern, der "andere" kann ja erlauben, was er will.
#6
German - Deutsch / Re: Verstädnisfrage Wireguard ...
Last post by wirehire - Today at 01:45:36 PM
Vielen lieben Dank an euch!

Genau durch die Floating regel ist es mir aufgefallen. Ich habe jetzt die Floating regeln jeweils angepasst.
Dazu auf dem WG interface ein Block, sodass, auch wenn auf der einen seite eine falsche flaoting regel vorhanden wäre, es nicht auf der remote Seite, das wg interface passieren würde!

Danke noch mal an euch, dass ihr mir den Knoten im Kopf gelöst habt!
#7
German - Deutsch / Re: Verstädnisfrage Wireguard ...
Last post by Lucas P - Today at 01:36:14 PM
Quote from: wirehire on Today at 10:29:44 AMSeite 1 . lan regel icmp zu ziel zb 10.10.10.10 erlaubt,

dann würde die regel greifen, durch den vpn bis rübe rzur seite zwei.

Und jetzt block nötig oder wnen nicht erlaubt, dann kommt es nicht durch?
Ganz genau.

Ich mache die Regeln selbst immer auf dem VPN Interface, auch wenn ich die Kontrolle für beide Firewalls habe.
So kann man auf einen Blick sehen, was per VPN rein kommt und was nicht.

Floating Regeln nutze ich garnicht, bevorzuge es die Regel da zu lassen, wo sie hingehört
#8
I feel really dumb, but the solution was surprisingly simple. All I had to do was add https:// to the front. I assumed Chrome did that automatically. Thanks so much to both of you for pointing me in the right direction!
#9
General Discussion / Re: Support AmneziaWG
Last post by Monviech (Cedrik) - Today at 12:21:17 PM
We need PRs for this we will not implement this ourselves.
#10
Announcements / OPNsense 25.7.8 released
Last post by franco - Today at 12:17:59 PM
Hey,

So we are making way for safer command execution since a comment was
added to the certification of the business version about a possible
injection into interfaces_pfsync_configure() -- note that it was a comment
and not a security issue since the exploit requires to edit the config.xml
and/or do a configuration import.

The issue in interfaces_pfsync_configure() has now been fixed, but as
mentioned the idea was to get rid of these problems once and for all so
the Shell class was rewritten and every call was audited.  You will see
more movement on our way to 26.1 in this area as we do not want to push
all changes into the 25.7 series immediately so that they can be properly
verified first.  Suffice to say most of the code we worked on over the
years was already much safer due to the introduction of exec_safe() very
early in the project history.

The Unbound blocklists feature formerly known as a business feature is
now a community feature.  Since this required merging both the existing
community one with the business one you need to make sure to reapply the
blocklist settings after the reboot since it will not generate a new and
possibly incompatible format.  Make sure to check your automatically
migrated settings while at it.

What does all of this mean?  It means security matters.  It also means
that community matters.  We will continue to improve the community version
because it is the base for the business version and that is exactly how
it should be so that everybody can benefit from these changes!

Note this release includes a new kernel with a lot of improvements in the
vtnet(4) driver department.  It is stable code according to release
engineering procedure but if you are seeing specific issues let us know.

Here are the full patch notes:

o system: defaults: properly delete empty model containers in the configuration
o system: switch int/bool to string in gateway properties
o system: ignore TypeErrors when parsing log lines in the backend
o system: replace various raw exec(), system(), passthru() and shell_exec() calls with safer variants
o system: add host route deletion support to system_host_route()
o system: move the general page host route removal to system_host_route()
o system: add CA chain to PKCS12 export
o interfaces: support link-local IPv6 mode
o interfaces: also stop PPPoE connections when CARP is temporarily disabled (contributed by René Mayrhofer)
o interfaces: fix packet capture and ping buttons not working since 25.7.7
o interfaces: limit execution of sysctl scope in PPP device edit code
o interfaces: safer interfaces_pfsync_configure() handling
o firewall: live log: make this grid static and slightly adjust info column width
o firewall: live log: backwards compatibility for old 'interface_name' field type
o firewall: live view: fix wrong variable scope
o firewall: automation: split search logic and normalize legacy output
o firewall: aliases: add a few GeoIP related logging messages
o firewall: mute pfctl-based table entry expire to avoid cron noise due to stderr use
o firewall: aliases: missing placeholder for username in basic auth type selection
o firewall: support "0" as valid rule ID in rule lookup redirect
o firewall: automation: add per-rule state timeouts for "udp.first", "udp.multiple" and "udp.single"
o captive portal: fix selectpicker #voucher-groups not being re-rendered after change event
o captive portal: move grid init to tab show event
o dnsmasq: switch to file_safe() use in backend
o dnsmasq: minor safe execution changes in backend
o kea-dhcp: automatic route support for PD leases
o kea-dhcp: case insensitive MAC address comparison
o isc-dhcp: adjust backend for safe execution
o ipsec: disable model caching on SPD page
o ipsec: add AES256GCM16 to the child ESP proposals list
o ipsec: hide phase 2 output based on phase 1 status instead of the row count for phase 2
o ipsec: add "reqid_base" setting to advanced settings
o openssh: minor safe execution change in backend
o openvpn: swap description and mode in "tls_key" and require a description for static keys
o openvpn: one safe execution change
o openvpn: add fast-io option (contributed by mdten)
o radvd: safe execution changes
o unbound: improve CNAME handling of whitelisted domains
o unbound: safe command execution changes
o unbound: merge extended blocklists into community version
o unbound: duplicate pointer records due to not casting the field types
o wireguard: fix wrong maximum value for "PersistentKeepalive"
o backend: rename "realif" variables to "device" in a number of spots
o backend: avoid the use of get_real_interface() when it does not matter and remove dead code associated with that
o backend: exend shell_safe() to emulate exec() $output argument magic
o backend: reimplement existing command execution functions with Shell class implementation
o backend: replace mwexecf_bg() with mwexecfb() for clarity
o mvc: move translation to menu system and add "FixedName" property
o mvc: extend ModelRelationField so it can optionally disable caching
o mvc: rewrite the old Shell class according to our current standards for safe command execution (exec_safe() wrapper)
o mvc: make "data_change_message_content" configurable
o shell: assorted cleanups in console menu related scripts
o ui: fix tokenizer event trigger loop
o plugins: os-freeradius 1.9.28[1]
o plugins: os-frr 1.49[2]
o plugins: os-ndp-proxy-go 1.0 is a hot-off-the-press userspace IPv6 Neighbor Discovery Proxy[3]
o plugins: os-q-feeds-connector 1.3[4]
o plugins: os-theme-flexcolor 1.0 is a new 3-in one theme[5] (contributed by Schnuffel2008)
o src: vtnet: assorted stable branch improvements
o src: ifconfig: assorted stable branch improvements
o src: SO_REUSEPORT_LB breaks connect(2) for UDP sockets[6]
o src: sctp, tcp, udp: improve deferred computation of checksums
o src: dhclient: improve UDP checksum handling
o src: ipfw: check for errors from sooptcopyin() and sooptcopyout()
o src: ipfw: pmod: avoid further rule processing after tcp-mod failures
o src: dummynet: move excessive logging messages under debug output
o src: net: validate interface group names in ioctl handlers
o src: pf: improve DIOCRCLRTABLES validation
o src: pf: improve add state validation
o src: pf: SCTP abort messages fully close the connection
o src: if_vxlan: fix byteorder of source port
o src: ixl: fix multicast promiscuous mode state tracking and filter management
o src: ix/ixv: add support for new Intel Ethernet E610 family devices
o src: ice: add PCI IDs for E835 devices
o src: ice: add support for E835-XXV-4 adapter
o src: igb: fix out-of-bounds register access on VFs
o src: netlink: in snl_init_writer() do not overwrite error in case of failure
o ports: curl 8.17.0[7]
o ports: nss 3.118.1[8]
o ports: openvpn 2.6.16[9]
o ports: pcre2 10.47[10]
o ports: php 8.3.28[11]


Stay safe,
Your OPNsense team

--
[1] https://github.com/opnsense/plugins/blob/stable/25.7/net/freeradius/pkg-descr
[2] https://github.com/opnsense/plugins/blob/stable/25.7/net/frr/pkg-descr
[3] https://docs.opnsense.org/manual/ndp-proxy-go.html
[4] https://github.com/opnsense/plugins/blob/stable/25.7/security/q-feeds-connector/pkg-descr
[5] https://github.com/opnsense/plugins/blob/stable/25.7/misc/theme-flexcolor/pkg-descr
[6] https://www.freebsd.org/security/advisories/FreeBSD-SA-25:09.netinet.asc
[7] https://curl.se/changes.html#8_17_0
[8] https://firefox-source-docs.mozilla.org/security/nss/releases/nss_3_118_1.html
[9] https://community.openvpn.net/openvpn/wiki/ChangesInOpenvpn26#Changesin2.6.16
[10] https://github.com/PCRE2Project/pcre2/releases/tag/pcre2-10.47
[11] https://www.php.net/ChangeLog-8.php#8.3.28