Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Topics - Z80ACPU

#1
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
#2
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:
        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
        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
#3
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.
***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:
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