Messages

Hallo zusammen,

ich habe in meiner OPNsense schon seit Jahren ein automatisches Backup zu Nextcloud laufen (Plugin "os-nextcloud-backup") und hatte in den Einstellungen auch einen Encyption Password hinterlegt. Als ich das damals
eingerichtet hatte, konnte ich die Dateien auch wieder auf meinem Windows PC entschlüsseln.

Nun wollte ich das mal wieder überprüfen, aber leider klappt es einfach nicht mehr. Da ich mit meinem Latein am Ende bin, würde ich gerne bei euch nachfragen.

Die XML Datei sieht dabei wie folgt aus:

Code Select Expand

---- BEGIN config.xml ----
Version: OPNsense 22.7.10_2
Cipher: AES-256-CBC
PBKDF2: 100000
Hash: SHA512

U2Fs[...]
---- END config.xml ----

Der Befehl, den ich mir damals für OpenSSL-Win64 v1.1.1.17 aufgeschrieben hatte:

Code Select Expand

openssl enc -d -base64 -aes-256-cbc -md md5 -in "encrypted.xml" -out "decrypted.xml" -pass pass:thepassword

Jetzt habe ich es mit der gleichen OpenSSL Version versucht, ohne Erfolg. Dann habe ich es noch mit OpenSSL v3.0.7 versucht. Es gibt aber immer ein "bad decrypt", "bad magic number" oder eine "wrong final block length"

Dabei habe ich schon versucht, mit den Parametern herumzuspielen, aber das half alles nichts. Vielleicht hat ja jemand von euch eine aktuelle Backup Datei und kann diese auch auf unter Windows wieder entschlüsseln.

Grüße, Stefan

I also have some problems with MultiWAN and connections sometimes don't want to let go of the metered, LTE failover WAN.

Do you also experience the problem with a gateway failover group, the internet (and VPN, etc) gets disrupted when the secondary (failover, tier 2) WAN gets down despite the primary (standard, tier 1) still working? I guess it is the state killing on gateway failure... but why does it kick in when the failover with no traffic other than monitoring goes down. This behavior doesn't seem ideal to me. So I'd like to hear what other people experienced.

To make basic filtering fast and easy again, I would just add "any" in the first dropdown, which works just like the old filter, and make it default. If someone wishes advanced filtering, then they could use the dropdowns.

What I like to do in situations like this is the following:

Create an alias:
Name: RFC1918
Type: Network(s)
Content: 192.168.0.0/16,172.16.0.0/12,10.0.0.0/8
Description: Private Networks

And to get started, two LAN rules:

First one for the "Internet" access
Action: PASS
Source: LAN net
Destination / Invert: check
Destination: RFC1918 (use the alias here)
Gateway: WAN_GROUP

And the second one is basically your standard rule
Action: PASS
Source: LAN net
Destination: LAN net
Gateway: Default

So we basically route everything that is targeted to NOT a private IPv4 adresses through the WAN Group. The other, "internal" traffic will skip the first rule.

However, this is a *works for me* and only if you just use IPv4 and no public IPs internally. Depending on your network it might cause issues. Of course you can work on from here and tweak it to your desire if the basic idea is working for you.

Let me know it this maybe helps :)

@Maurice: You are right of course, I guess it depends on your scenario. With mine (only IPv4 and no internal usage of public IPs), this works. But I am interested to look deeper into your solution, might be useful elsewhere ;)

@mohnewald: Thanks for clarification.

Hmm, what do you consider as "properly"?

I would suggest creating an Alias:

Name: RFC1918
Type: Network(s)
Description: Private Networks
Content: 192.168.0.0/16,172.16.0.0/12,10.0.0.0/8

Now in your DMZ firewall rules, create a new Rule:

Action: BLOCK
Protocol: IPv4 *
Source: DMZ
Port: *
Destination: RFC1918

and add that before your "allow in DMZ Interface to any". Therefore any traffic to other private networks (your LAN interface and any future interfaces that are private networks) will be blocked, only "public" IPs are allowed.

You might need to add new rules to allow DNS and NTP (for example) before the RFC1918 rule.

Hope this helps a bit ;D