Messages

I prefer binding to 127.0.0.1 and then use port forward rules. Especially useful for Multi WAN scenarios too.

Lass mal Host leer und gib als Domain "unify" ein.

Finde heraus welchen endpoint die GUI abruft:

https://docs.opnsense.org/development/how-tos/api.html#using-browser-console-to-inspect-api

Getting all settings included in all combinations is very hard.

The man page has quite some directives, some features will be limited in some way.

The scope in which the features work right now is pretty clear. A new grid just for ipset will not be created.

What could be a possibility though is to improve the validation so that a domain must not necessarily have an IP address or port defined. Such a scope would be managable to solve.

The issue sounds mostly input validation related.

Create a clear scoped ticket here and we can probably solve that:

https://github.com/opnsense/core

The way it works right now is intentional, since it guides the user implicitly that domains that are entered must be resolvable by dnsmasq. This is because most users also run unbound.

Allowing a wildcard (#) to flush all resolved domains into an alias seems like its unecessary. The use case is clearly stated in the documentation, for allowlists regarding things like *.example.com or the like. It is just an extension of the other Alias types that exist for hostnames, not a solution for full alias management.

Work can be repetitive in most GUIs, a larger set can be imported via the API for example.

If you want full control, you can import a custom dnsmasq configuration file.

Maybe you are not going to System - Trust - Certificates but are still in Authorities?

Well do you run the Opnsense WebUI on another port than 443 and 80?

Check in your administrative settings, and change to something like 8443 and disable the automatic redirect to free port 80.

NAT reflection is the way to go and it works (Im the guy who wrote this:

https://docs.opnsense.org/manual/how-tos/nat_reflection.html

If you wanne see which services listen locally on your OPNsense:

# sockstat -l

You probably want this:

https://docs.opnsense.org/manual/dnsmasq.html#dnsmasq-as-primary-dns-resolver

And if you want dnsmasq authoritative, make sure to select "local" when doing a DNS Host Override.

That warning is normal until the plugin is available in the opnsense repository.

Neh für Hypervisor scaling sollte man sich hilfe von einem auf virtualisierung spezialisierten Experten holen.

Wäre aber traurig wenn Hyper-V im Standalone oder in einem Hyperconverged Cluster probleme mit mehr als 10 vswitchen hätte. xD

https://docs.opnsense.org/manual/dnsmasq.html#firewall-alias-ipset

Sorry I dont know.

Maybe you can bootstrap once you installed the FreeBSD 14.3 version with your hack.

https://github.com/opnsense/update?tab=readme-ov-file#opnsense-bootstrap

Or you install a hypervisor on the server (e.g. any linux with kvm) and run OPNsense as VM.

Is there a way in the q-feeds dashboard to whitelist an IP address, e.g. if its an accidental false positive that would impact production?

Right now, you could create a manual alias and firewall rule, matching before the q-feeds block rule, that allows an IP address explicitly.

But I couldn't on first glance find anything in tip.qfeeds.com to overrule a decision for an IP address manually.

I meant setting the START ACTION of all CHILD(ren) to NONE.

This would make the OPNsense the responder only. The other side would have to initiate then.

The NATing Router in front of the OPNsense could then Port Forward (destination NAT) to the CARP IP address.

The initiator would then handle initiating a new IKE for Phase 1 when DPD would kill the session after a failover.

But with your specific issues, when you do a carp maintainance, you could also simply stop the strongswan service manually on the primary firewall as additional step.