Messages

Hallo Zusammen,
danke für die Aufklärung.

Nur als abschliessende Frage:
Gibt es einen funktionellen Unterschied?

Liebe Grüße
Wolfgang

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

Hallo Zusammen,
Dann werde ich mir mal etwas mehr Zeit nehmen, die Logs zu inspizieren.

Vielen Dank erstmal.
Herzliche Grüße
Wolfgang

Hallo Zusammen,
entschuldigt bitte, wenn ich den Kaffee noch einmal aufwärme.

Ich bin heute Nacht bei der Migration nach instances über die "Renegotiate time" gestolpert.
Bei meiner legacy conf hab ich die auf Null gesetzt und die 2FA Verbindungen liefen superstabil durch.

Nun, bei "Instances" bekommt der user "gefühlt" nach einer Minute einen Abbruch und muss sich neu authentifizieren.

Also gehe ich davon aus, dass in meiner Conf bei den Zeiten und Intervallen noch Fehler stecken.

Daher sind meine Einstellungen:
"Renegotiate time" nicht gesetzt, also Standardwert 3600
"Auth Token Lifetime" 43200

Ist das nun der finale "Königsweg" meinen Anwendern eine stabile 12h Verbindung zu ermöglichen?

Oder hab ich da was Grundsätzliches mit den Parametern nicht verstanden?

Herzliche Grüße
Wolfgang

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)