Messages

Hallo Zusammen,
noch mal vielen Dank für den intellektuellen Ar**tritt.

Manchmal keist man nur noch in seinem eigenen Grübelkarussel und kommt da ohne dem nicht raus.

Liebe Grüße
Wolfgang

Oh weh.. Die Regeln 5 und 6 beziehen sich auf ESP-Protokoll...
Das hab ich nicht gesehen... Sorry für die Verwirrung!

Hallo Patrick,
na dann. Wenigstens hab ich nix übersehen. Ist ja schon mal was.
Nun hab ich mir die alten "Automatic-Regeln" mal angeguckt:

Nr.	Source	Port	Destination	Port	Gateway
1	*	*	IPSEC_Hosts	500	WAN
2	IPSEC_Hosts	*	*	500	*
3	*	*	IPSEC_Hosts	4500	WAN
4	IPSEC_Hosts	*	*	4500	*
5	*	*	IPSEC_Hosts	*	WAN
6	IPSEC_Hosts	*	*	*	*

Auf Anhieb hätte ich gesagt, dass eine Regelsatz für Port 500 und eine Regelsatz für 4500 reicht.
Offensichtlich ist der Automatic da anderer Meinung.

Wieso bastelt er da konsequent die überlagernden Regeln 5 und 6 ein?
Das macht er bei jedem "legacy" Tunnel.

Na, wie dem auch sei. Ich bau jetzt alle 6 Regeln, denn ich bin nicht schlauer als die Automatik.

Ist das okay so, oder babbel ich da Mist zusammen?

Liebe Grüße
Wolfgang

Hallo Allerseits,
ich stecke gerade mitten in der IPSEC Migration von Tunnels nach Connections. (Version 25.4.1)
Hierbei ist mir aufgefallen, dass die automatisch erstellten Firewallregeln, bezüglich Port 500 und 4500 bei der Migration gelöscht werden.

Ist das Absicht und ich bin zu doof, das entspechende "Häkchen" zu setzen, dass bei Connections die entsprechende Regel gesetzt wird?
Gibt es an anderer Stelle eine diesbezügliche Einstellung.
Was ist der Gedanke hiner dieser Änderung?

Sommerliche Grüße
Wolfgang

Oha!
Ach neee... Aha!

Danke für die schelle Antwort!
Wolfgang

Guten Tag Zusammen,
Ich migriere zur Zeit meine IPSEC Tunnels nach Connections. (OPNsense 25.1.11-amd64)
und hier stosse ich beim zweiten VPN auf eine Ungereimtheit in der swanctl.conf
Szenario:
Ich habe vier Remote-Netze mit einem Zentralnetz zu verbinden

• RemoteServer1 hostet RemoteNetz1 und RemoteNetz2
• Remoteserver2 hostet RemoteNetz3 und RemoteNetz4

Soweit, so gut.

Aber in der swanctl (immer noch legacy!) sehen die children so aus:

Für RemoteServer1:

Code Select Expand

        remote_addrs = RemoteServer1
        dpd_delay = 10 s
        dpd_timeout = 60 s
        proposals = aes256-sha1-modp1024
        children {
            con1-000 {
                start_action = trap
                policies = yes
                mode = tunnel
                sha256_96 = no
                dpd_action = start
                local_ts = LocalNet
                remote_ts = RemoteNet1
                reqid = 1
                esp_proposals = aes256-sha1-modp1024
                life_time = 28800 s
            }
            con1-001 {
                start_action = trap
                policies = yes
                mode = tunnel
                sha256_96 = no
                dpd_action = start
                local_ts = LocalNet
                remote_ts = RemoteNet2
                reqid = 2
                esp_proposals = aes256-sha1-modp1024
                life_time = 28800 s
            }
Und RemoteServer2

Code Select Expand

        remote_addrs = RemoteServer2
        proposals = aes256-sha1-modp1024
        children {
            con2 {
                start_action = trap
                policies = yes
                mode = tunnel
                sha256_96 = no
                local_ts = LocalNet
                remote_ts = RemoteNet3,RemoteNet4
                reqid = 5
                esp_proposals = aes256-sha1-modp1024
                life_time = 28800 s
            }
        }
Der Elefant im Laden ist:
für den RemoteServer1 wird für jede Phase 2 ein eigenes Child aufgemacht, wohingegen für den RemoteServer2 das Child beide Netze zusammenfasst.

Meine konkreten Fragen:

• Warum ist das so? Ich sehe keinen Unterschied in dn Parametern, ausser der REQID, die ich nicht vergeben habe
• Kann ich die beiden Children für RemoteServer 1 zu einem Child zusammenfassen?

Vielen Dank für Eure Gedanken und Mühen im Voraus

Wolfgang

Hello Jimp, Hello Franco,
coming from OPNsense 24.7.4_1-amd64, i got the same Message, while trying to switch to business.

Is it possible to stay at the current version and wait until October and then trying to switch?

Best Regards
Wolfgang

Hallo Allerseits,
nur um das Thema abzuschliessen:
Jetzt hat das Update wunderbar geklappt!
@franco: Noch mal herzlichen Dank!

Liebe Grüße
Wolfgang

Hi Franco,
Wie sagte der olle Goethe? "Und bist Du nicht willig, so brauch' ich Gewalt"

Nach dem "pkg bootstrap -f" sagte Console:

Code Select Expand

root@HobergVPN:~ # pkg bootstrap -f
The package management tool is not yet installed on your system.
Do you want to fetch and install it now? [y/N]: y
Bootstrapping pkg from https://pkg.opnsense.org/FreeBSD:13:amd64/24.1/latest, please wait...
Verifying signature with trusted certificate pkg.opnsense.org.20240105... done
Installing pkg-1.19.2_1...
package pkg is already installed, forced install
Extracting pkg-1.19.2_1: 100%

OK. Soweit, so gut.
Der HealthCheck meckerte noch etwas von unknown Repository.

Also flugs in die Firmware->Packages geschaut.
Aha! "pkg 1.19" war vorhanden.
Das habe ich noch einmal re-Installiert.

Neuer HealthCheck und Tadaa...

Code Select Expand

opnsense-24.1.10_3 version mismatch, expected 24.1.10_8
Checking packages: ............................................. done
***DONE***

Ganz großen Dank für die Hilfe.

Heute Nacht werde ich noch einmal ein Update versuchen. Werde berichten.

Liebe Grüße
Wolfgang
Und ich werde auch ganz bestimmt nicht mehr an den Repos fummeln. Selbst wenn ich immer noch nicht weiss, wie ich das angestellt habe

Hallo Franco,

nee. nicht ganz, denn:

Code Select Expand

***GOT REQUEST TO REINSTALL***
Currently running OPNsense 24.1.10_3 at Wed Aug  7 13:20:51 CEST 2024
Updating OPNsense repository catalogue...
OPNsense repository is up to date.
All repositories are up to date.
The following packages will be fetched:

New packages to be FETCHED:
pkg: 1.19.2_1 (4 MiB: 100.00% of the 4 MiB to download)

Number of packages to be fetched: 1

The process will require 4 MiB more space.
4 MiB to be downloaded.
Fetching pkg-1.19.2_1.pkg: .......... done
pkg-1.21.3: already unlocked
Checking integrity... done (0 conflicting)
Nothing to do.
***DONE***

Danach noch ein healthcheck

Code Select Expand

pkg-1.21.3 repository mismatch: FreeBSD
pkg-1.21.3 version mismatch, expected 1.19.2_1

Fehlt dem noch ein Reboot? Das könnte iche erst heute Abent tun.

Liebe Grüße
Wolfgang

Hi Franco,
öhemm... Wie soll ich sagen?
Ich bekomme das PKG-Paket 1.19 nicht angezeigt.

Ich bin in System->Firmware->Packages. Dort setze ich den Filter "pkg" und bekomme nur die Ver 1.21.3 gezeigt.

Liebe Grüße
Wolfgang



(Grübelt immernoch wann ich diese verflixten BSD-Repos angefasst haben könnte)

Hallo Franco,
vielen Dank für die schnelle Antwort!

Am besten einfach das "pkg" Paket neu installieren im "Packages" Tab und das wars.

Nur um richtig zu verstehen. Ich soll die Version 1.21.3 neu Installieren?

(Ich frag mich gerade, bei welcher Gelegenheit ich an den FreeBSD Repos herumgefummelt habe.)

Liebe Grüße
Wolfgang

Guten Tag liebe Leute,
ich wollte letztens meine virtualisierte OPNSense von 24.1.10_3 nach 24.1.10_8 über die WebGui aktualisieren.
Am System läuft nix Spezielles. IPSec und OpenVPN wird genutzt

Jedoch ist irgendwas dabei schief gegangen.
System war trotz mehrerer Neustarts extrem langsam und so nicht mehr zu administrieren.
Es zeigten sich Plugin-Konflikte.
Betroffen waren "os-vmware", sowie drei os-Themen (cicada, tukan und vicuna, wenn ich mich recht erinnere).

Ergebnis und Siegerehrung war, dass ich das System aus einem Backup wiederhergestellt habe und vorerst das update verschoben habe.

Nun habe ich ein health audit angeschubst.
Hier sind "eigentlich" keine augenscheinlichen Fehler aufgetreten.

Code Select Expand

***GOT REQUEST TO AUDIT HEALTH***
Currently running OPNsense 24.1.10_3 at Wed Aug  7 07:20:30 CEST 2024
>>> Root file system: /dev/gpt/rootfs
>>> Check installed kernel version
Version 24.1.8 is correct.
>>> Check for missing or altered kernel files
No problems detected.
>>> Check installed base version
Version 24.1.8 is correct.
>>> Check for missing or altered base files
No problems detected.
>>> Check installed repositories
OPNsense
>>> Check installed plugins
os-vmware 1.5_1
>>> Check locked packages
No locks found.
>>> Check for missing package dependencies
Checking all packages: .......... done
>>> Check for missing or altered package files
Checking all packages: .......... done
>>> Check for core packages consistency
Core package "opnsense" has 68 dependencies to check.
Checking packages: ........................
opnsense-24.1.10_3 version mismatch, expected 24.1.10_8
Checking packages: .........................
pkg-1.21.3 repository mismatch: FreeBSD
pkg-1.21.3 version mismatch, expected 1.19.2_1
Checking packages: .................... done
***DONE***

Nur dieser kleine, häßliche Hinweis:

Code Select Expand

opnsense-24.1.10_3 version mismatch, expected 24.1.10_8
Checking packages: .........................
pkg-1.21.3 repository mismatch: FreeBSD
pkg-1.21.3 version mismatch, expected 1.19.2_1

macht mich nervös.
Der "opnsense-mismatch" ist plausibel. Hätte halt lieber die aktuellere Version.
Nur die Geschichte mit dem "Repository-Mismatchch" ist IMO seltsam.

Nun frage ich lieber, bevor ich erneut in eine Falle tappe:

Habe ich ein Problem, an der OPNsense?
Wenn ja, wie kann ich das beheben?

Lieben Dank für Eure Mühen im Voraus

Wolfgang