Messages

Frage selber beantwortet.
Habe am Satelliten die Start-Action auf "Trap" gestellt.

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

Hallo meyergru,
vielen Dank. Ich denke, ich werde das Taggen der opnsense überlassen.
Dann kann ich mich auch exakt an die Anleitung halten.

LG
Wolfgang

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

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