Messages

[ACME-Server]

Ich habe folgendes verstanden:

1. Du hast zwei interne CAs in OpnSense. Haken dran.
2. Diese können per ACME Zertifikate ausstellen. Wie das?

Bei 2 verlierst Du mich. ACME ist ein Protokoll/Verfahren, mit Hilfe dessen man Zertifikate ausstellen kann. OpnSense kann zwar Zertifikate ausstellen, unterstützt m.W. dazu aber nicht das ACME-Verfahren als ACME-Server. ACME wird nur per Plugin in der Rolle als ACME-Client, d.h. als Anforderer, nicht als Aussteller von Zertifikaten in OpnSense unterstützt.

Unabhängig davon werden in jedem Client natürlich nur die in der CA-Chain eingetragenen Root-CAs unterstützt. Wenn Du also auf einem Client per Curl irgend etwas abrufst, was von einer Deiner CAs ausgestellt wurde, musst Du auf dem entsprechenden Client auch die ausstellende CA eingetragen haben oder per Curl-Switch die Verifikation abschalten. Bei OpnSense selbst geht das elegant über "System: Trust: Authorities".

Systematisch testen. Wird der zu erreichende Hostname korrekt aufgelöst (nslookup)? IPv4 und IPv6 (-query=A / -query=AAAA)? Falls nein -> DNS.

Kann man den Host pingen bzw. ist der für den Dienst zuständige Port geöffnet (nmap -Pn -pX -4)? A. von der OpnSense aus und b. vom LAN aus?

Falls A nein: Routing? Falls B nein: Firewall-Regeln oder NAT?

Yes, GUI and wg0.conf will agree, but eventually, the contents of config.xml will overwrite wg0.conf again, destroying your efforts.

If you want to do such a thing, use the OpnSense API like already correctly answered in answer #1.

You should try with "iperf -P4". Also, you could look at the MTU size of your tunnel (you must deduct the VPN overhead from the normal MTU). As a first check, use 1400.

With VPNs, there are always two firewall rules involved:

1. The one with which you allow access for the VPN daemon port. In order to allow access for your roadwarriors from anywhere, this must not be limited by a geoip rule.

2. The ones to define what these roadwarriors can do within your network once they get an IP assigned by the VPN (which would be an RFC1918 IP). These rules can be specified at WG group, network, WG instance or even at the client IP level, but at finest granularity, they can tell you which specific WG key is bein used. They do not carry any information as to which routeable IP (or which country) the client originally came from.

So, yes, you can, but this private IP obviously bears no information on location. I use this all day. There must be a way to do this, otherwise any VPN client could do either nothing or anything. You can use different WG instances for site-2-site tunnels than for roadwarriors or even have different instances for "types" of roadwarriors (like administrators vs. developers).

For the OpnSense VM: Is a CPU emulation selected that accelerates Wireguard encryption (i.e. "host" would be best)?

If vtnet "hardware" is being used: Is multiqueue enabled on the NICs? RSS is enabled?

Also, see: https://forum.opnsense.org/index.php?topic=44159.0, notes on network "hardware".

Yes.

Do you fear that the WG VPN endpoint could be exploited? It should be fairly resilient, plus, you can use any exotic port you like.

Thus, you could place the rule for the WG port before the normal geoip block rules. You can further limit access by creating a more limited version of the geoip blocks only for the WG port which excludes whatever countries you want to have VPN access.

And how would you actually go about that?

I often pointed to the obvious fact that along with great flexibility and functionality, "easy going" for end-users goes out the window. I accept the fact that OpnSense is an expert tool.

As a simple example, take the fact that ISC DHCPv4 is a part of the initial rant (while that did not even include the firewal setup or IPv6). And at this point, we have no less than three (!) DHCP daemons, namely ISC, Kea and DNSmasq. Which would you choose if the process was indeed more streamlined?

The only approach I could imagine was a set of some kind of "helpers for common tasks", but these would have to be on top of the fine-grained settings menus. Also, they would be prone to break pre-existent settings, just because they have to be limited to default settings (which ones, BTW?) instead of the wide variety of potential settings.

I can already picture upcoming forum discussions about how the default X of helper Y "does not suit my needs, can we change it or at least make it selectable?".

[any]

In practice, this makes little sense, because, unless you explicitely disallow any traffic, you will not be safe against exfiltration anyway:

Consider any other type of traffic being allowed, like HTTPS - since you cannot break up that encrypted connection, you know jack about what is in it. And this is even true for outbound connections. Of course, any IP connection can be used in any direction regardless of the direction it was initially started in.

The only reason why this is psychologically threathening is that because ICMP ping is usually not a real connection, it looks somewhat sneaky.

You can specify a "host" type firewall alias in the source of the NAT rule.

BTW: https://docs.opnsense.org/manual/how-tos/ipinfo_geo_ip.html is way more detailed and accurate than Maxmind. You may have to enlarge the "Firewall Maximum Table Entries" to make it work.

/var/log/filter/latest.log

I put all applications that are reachable from outside, regardless if they are containerized or VMS, in a DMZ. For docker containers, I have one docker host for internal services (on LAN) and one for web services (in DMZ).

Caddy does not really help if your apps are prone to authentication circumvention attacks, SQL injections or other attacks.

Take a full web UI like Proxmox as an example - I would not expose that with a "dumb" reverse proxy only, rather use a VPN or limit access to API endpoints. It would be similar for the Portainer UI.

By putting such applications in a separate network zone, potential attacks are mostly limited to spreading outside that zone.

If you mean the "let out anything from firewall host itself" rule - it is "last match", so if you block traffic before it, it will never fire.

Take a look at this, point 24.

Keep in mind that you then need to explicitely allow anything that is needed to build up your ISP connection, probably including DHCP.