Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - Patrick M. Hausen

#1
Quote from: MrHappyHippo on May 17, 2026, 09:38:16 PMWould it be possible to use the Alias "This Firewall" as the redirect target instead of the ULA address?

No.

Define an arbitrary ULA, assign to lo0 with /128 netmask, use that.
#2
If you use destination NAT with 127.0.0.1 whatever the service and completely independent of OPNsense, the reply packets are generated with a source address of 127.0.0.1, which is then source NATed back to the public address to achieve bidirectional flow.

In the case of ::1 the relevant RFC explicitly forbids ("MUST NOT") a packet with a source of ::1 ever leaving a conpliant system. So the FreeBSD network stack drops every IPv6 packet with a loopback source that does not also have a loopback destination.

That's why it does not work with IPv6.
#3
Quote from: HerkomerKlamm on May 16, 2026, 06:48:53 PMWith the option in Q-Feeds 'Register domain feeds' enabled

Well, if you explicitly enable the "block via Q-Feeds" feature, what do you expect?
#4
opnsense-revert -r 26.1.7 nut
pkg lock nut
#5
Je nach Gegenstelle musst du entweder

- 2 Subnetze in einen Phase 2 Eintrag schreiben oder
- 2 getrennte Phase 2 Einträge mit je einem Subnetz anlegen.

Wenn bei einer Variante immer nur ein Subnetz funktioniert, probier die andere.
#6
The OS names change when the hardware does.

Switch from 1G to 10G by adding a new 10G NIC? Simply reassign the logical interface to the new device - done. IP configuration, DHCP, firewall rules, NAT, ... all will just follow with a single click.
#7
Citing from https://www.suny.edu/meansbusiness/procurementpp/digital-resources/ there are four different rules/laws applied:

Quote[...] requires all websites procured under state contract to conform [...]

Quote[...] prohibits disability discrimination in places of public accommodation, including public facing websites [...]

Quote[...] all web content and mobile applications must conform [...]

Quote[...] all web content, mobile applications, and kiosks must conform [...]

Neither OPNsense nor FreeBSD is any of these.
#8
A new version of the plugin is not necessary but OPNsense needs to release an updated version of the NginX package.

If you use the plugin you can more or less easily check if you are affected by the most serious of the current set of vulnerabilities, which you correctly identified as CVE-2026-42945. It gives an unauthenticated RCE (remote code execution). Big bada-boom.

Put probably you don't need to worry.

1. Finde the location of the NginX configuration in OPNsense - if I read the plugin source correctly, it's in /usr/local/etc/nginx just like in a regular FreeBSD install.

2. Inspect all configuration files in there for "rewrite" statements. If there are none, you are not affected.

3. Inspect all rewrite statements for occurrences of an unnamed regular expression capture in the match expression, i.e. a regular expression wrapped in parentheses e.g. like so:
(.*)

4. If an unnamed regular expression capture is found, does the replace expression contain a question mark, e.g. like so:
/index.php?page=$1

If no such expression is found you are also not affected.

HTH,
Patrick
#9
This applies to web content, not devices.
#10
Or use a proxy instead of destination NAT. E.g. Caddy listening on the WAN interface can be used from internal networks just like from the Internet with just the public IP address in DNS.
#11
German - Deutsch / Re: MTU richtig setzen
May 14, 2026, 03:04:29 PM
Calculated value reicht.
#12
Did you activate "show community plugins"?
#13
German - Deutsch / Re: MTU richtig setzen
May 13, 2026, 10:26:04 PM
Alle logischen Interfaces, auf denen du Clients hast, also genau die VLANs und nicht die Hardware-Interfaces.

Aber nochmal zum Wording:

"If you enter a value in this field" - wenn du in dieses Feld (also das MSS Feld - nicht MTU!) einen Wert eingibst ...

"then MSS clamping for TCP connections [...] will be in effect" - dann wird MSS clamping für TCP Verbindungen aktiviert ...

"to the value entered above minus 40 (IPv4) or 60 (IPv6)" - auf den eigegebenen Wert minus 40 für IPv4 oder minus 60 für IPv6.


Genau so steht es also da. MTU Feld lehr, MSS Feld 1492. Abgezogen wird automatisch. Das MSS Feld ist über ("above") dem Hilfetext.
#14
German - Deutsch / Re: MTU richtig setzen
May 13, 2026, 09:56:29 PM
MSS solltest du bei OPNsense auch auf 1492 setzen. OPNsense zieht dann selbständig 40 für IPv4 und 60 für IPv6 ab. Steht auch in der Hilfe zum Feld im UI.

Und du machst das auf den internen Interfaces:

- WAN sollte von selbst "Calculated PPP MTU: 1492" anzeigen. Sonst nichts weiter konfigurieren.
- Auf allen internen Interfaces setzt du MSS auf 1492.

HTH
Patrick
#15
Yes, the interface views show all floating rules applied to that particular interface, now. A good move, IMHO.