Messages

Fixed in latest 26.7.8.

No ideas? So using Squid is a security risk now?

Hi,

Using Squid on my OPNsense and the test website tells me that 6 (emSign Root TLS CA - G3) out of 12 Domains are able to connect https://emudhra.we-have-a-problem.com/

How do we get the updated revocation list into Squid?

Durchschnittliche Upstream-Antwortzeit ist zu hoch.

Das ist doch völlig normal, wenn du rekursiv auflöst. Dafür macht Unbound Caching, Serve-Expired und Prefetch. Wenn der Cache erst mal gut gefüllt ist, erledigt sich das Problem von selbst.

Du musst nur bedenken, dass der Cache geleert wird, wenn du den Router neu startest. Dann können initiale Requests eben wieder etwas länger dauern. Wenn dich das stört, musst du den Cache vorher sichern und dann wiederherstellen.

Strict QNAME Minimisation halte ich übrigens für mutig. Ich vermute, das wird zu vielen fehlgeschlagenen Auflösungen führen.

Hi,

just updated to 26.7.6 and there seems to be a logic bug with the new DNSSEC column in the Unbound Reporting Details.

• Checking the DNSSEC checkbox hides the column.
• Unchecking the checkbox makes the DNSSEC column visible.

[not]

Still same problem, when second PC tries to connect it gets network error in Call of Duty, as soon as the first PC closes Call of Duty the second PC can connect and vice versa.

Yes, that's exactly what Static Port does. Read the documentation about Endpoint-Independent NAT that I linked a few posts earlier:

In particular, this behavior helps avoid issues with multiple local clients using the same source port to reach the same remote host.

Static port is not the correct setting for gaming clients.

This is not a bug. Create an Alias if you want to combine entries.

So far it seems you can't combine both so I am not sure if Endpoint-Independent NAT will solve that issue too...

It does resolve this issue in a more secure way than Static Port. EIM-NAT is a fairly recent addition to OPNsense, and I migrated my rules for online gaming away from static port as soon as it became available. You might still need static ports for specific scenarios like SIP, but for gaming clients, EIM-NAT is definitely the more secure route now.

There's a good explanation of the details in the Netgate documentation here: https://docs.netgate.com/pfsense/en/latest/nat/outbound.html#endpoint-independent-port-restricted-cone-nat

See Post #1 => https://forum.opnsense.org/index.php?topic=52419.msg270603#msg270603 ;)

Why? What's the benefit of Static Port over Endpoint-Independent NAT?

It should be sufficient to enable Endpoint-Independent NAT for your gaming client.

Code Select Expand

[ ] Disable all packet filtering.
Warning: This will convert into a routing-only platform!
Warning: This will also turn off NAT!
If you only want to disable NAT, and not firewall rules, visit the Outbound NAT page.
I think this should point to the new d_nat page.

Sorry the normalization documentation was merged and updated a bit too early and reflects the upcoming version already.

Ah! :) Thanks for the clarification.

Hi,

I am reading https://docs.opnsense.org/manual/firewall_scrub.html

Firewall ‣ Settings ‣ Filter <- does not exist
Firewall ‣ Rules [new] <- does not exist
Select the Match action <- how and where? I do not see any field where I can select a Match action

Is this documentation for a previous version? Is there documentation for 26.7?

Ok. But this is a route, right? Looking at the documentation https://man.freebsd.org/cgi/man.cgi?query=route

Code Select Expand

    Routes have associated flags which influence  operation  of  the  protocols
    when sending to destinations matched by the routes.  These flags may be set
    (or sometimes cleared) by indicating the following corresponding modifiers:

    -xresolve    RTF_XRESOLVE  - emit mesg on use (for external lookup)
    -iface    ~RTF_GATEWAY    - destination is directly reachable
    -static    RTF_STATIC    - manually added route
    -nostatic ~RTF_STATIC    - pretend route added by kernel or daemon
    -reject    RTF_REJECT    - emit an ICMP unreachable when matched
    -blackhole RTF_BLACKHOLE  - silently discard pkts (during updates)
    -proto1    RTF_PROTO1    - set protocol specific routing flag #1
    -proto2    RTF_PROTO2    - set protocol specific routing flag #2
So what we're using here is -blackhole. Can we use -reject instead?

There's another and - in my opinion - better approach for preventing traffic with private destination addresses from being routed to the ISP:
Create null routes for all private address space. This will blackhole all private destination networks for which no higher priority routes exist. No firewall rules needed.

TIL. Thanks.

Is it possible to reject the blackholed traffic instead of dropping it?