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 habe zwischen zwei Standorten ein IPSEC VPN laufen. (Opnsense 26.7.4_1)

Das VPN läuft und soweit ich sehen kann, ist eigentlich alles okay.
Aber:
Ich sehe im "Status Overview" meine Phase 1, jedoch wird in der zugehörigen Phase 2 das Child doppelt angezeigt.
Ich kann mir darauf keinen Reim machen und frage hier besser noch mal nach.

1) In der Phase 1 habe ich beidseitig ein DPD Delay von 10 Sekunden eingetragen
2) In der Phase 2 habe ich auf beiden Seiten (Start Action ="Trap+Start"); (Close Action ="Trap"); (DPD Action ="Trap") eingetragen.

Tja...
Wieso wird zwei Mal das Child in der Phase 2 angezeigt?
Habe ich ein Problem und sehe es nicht?

Vielen Dank für Eure Gedanken!

Beste Grüße
Wolfgang

#2
Hallo Zusammen,
und eine Entschuldigung, dass ich so ein Thema schreibe.
Ich bin genötigt, eine Telekom DSL Verbindung zu bauen.
Ich habe ein Draytek167, also sollte das kein Problem sein. (Ist es bestimmt auch nicht)

Nun meine Fragen.

Gleichzeitiges VLAN-Taggen von Opnsense und Draytek ist wohl nicht mölich/schlau/funktionell, oder?

Ist es geschickter, das Draytek das VLAN-Taggen zu überlassen, oder sollte man das die Opnsense machen lassen?
Die Standardeinstellungen des Draytek waren tatsächlich so, dass VLA-Tag "7" voreingestellt war.

Wenn ich Draytek das Taggen überlasse, komme ich mit der Doku nicht recht klar, da ich bei der Konfiguration der WAN-Schnittstelle nicht PPPOE angezeigt bekomme.
Hier habe ich ausnahmsweise mal den ConfigWizzard rangelassen, der dann was konfiguriert hat.
Kann man dem Wizzard trauen?

Ansonsten habe ich keine Infos gefunden, wie ich bei einer 26.7. vorgehen soll, wenn das Draytek Taggen soll.

Vielen Dank für die Geduld
Wolfgang
#3
Hallo liebe Leute,
ich hab da mal ein Verständnisproblem.
Ich betreibe diverse IPSEC-VPN zwischen unser Zentrale und den einzelnen Standorten, die "fremdgehostet" werden.

Bei den allermeisten VPN war das "straight forward" Phase1 aufgesetzt, Partner definiert und ein Child aufgesetzt, in dem drei lokale Netze mit einem Remote-Netz bekannt gemacht werden.
Dann noch nen Shared Secret austauschen und fertig ist die Laube. (Sorry für die laxe Ausdrucksweise)

Nun habe ich einen Standort, bei dem vom dortigen Betreiber eine Watchguard als VPN-Router/Firewall eingesetzt wird.

Hier, mit der Watchguard hatte ich wirkliche Schwierigkeiten, das Ganze ans Laufen zu bekommen.
Ich bekam immer nur ein einzelnes Netzwerk im Child ans Laufen. Die jeweils anderen Netzwerke waren angeblich installiert, jedoch null Datenverkehr (kein Ping, nix)
Noch toller: bei jedem Neustart der Verbindung lief (statistisch verteilt) immer ein anderes Netz und die beiden anderen nicht. Mal Netz"A" Netz"B" oder Netz"C".

Ich hab ne Weile gebraucht, um genau das zu bemerken.

Nun habe ich pro Netz ein Child definiert und alle drei Netze laufen.

Meine Frage ist nun:
Warum klappt das mit den "mehrere Netze in einem Child" mit den anderen VPN-Routern. (Da sind auch eineige OPenSenses dabei)
Warum gibt es Zicken mit dieser Wireguard?

Vielleicht könnte mir jemand klären, was der Unterschied ist zwischen "Mehrere Netze in einem Child"<->"Ein Netz pro Child"

Vielen Dank für Eure Gedanken im Voraus
Wolfgang

#4
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
#5
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
#6
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