Hallo.
Ich habe gerade das Upgrade auf 20.7 angeworfen -- so wie ich es zuvor schon x-fach gemacht habe.
Der Unterschied nun war jedoch: Ich war mit Wireguard -> ssh verbunden und dann .... ja: "epic fail": der wireguard socket wird ziemlich zu Beginn des Upgrades entfernt und das war's.
Meine Frage ist nun natürlich, wie/ob ich das Upgrade "gefahrlos" wieder aufnehmen kann, wenn ich das nächste Mal vor der Kiste sitze?
Hallöchen,
"ziemlich zum Beginn" ist etwas wage.
Entweder so früh, dass die Shell terminiert und das Update nicht durchgeführt wird oder so spät dass der Reboot kam und das Update dann durchläuft...
Wahrscheinlicher ist letzteres weil das Update nicht mit Wireguard oder SSH interagiert, d.h. wenn es nicht der Upgrade Reboot war dann ist einfach die Verbindung abgebrochen.
Grüsse
Franco
...es gibt vereinzelt Hinweise auf "Startschwierigkeiten" mit Wireguard nach updaten auf 20.7
z.B. https://forum.opnsense.org/index.php?topic=18497.0
Ja, bitte nicht per WireGuard. Es schwirrt ein Howto irgendwo rum wo man dem WireGuard Endpoint die Netze hinterlegt die er gepusht bekommen soll. FreeBSD 11 hat das einfach ignoriert, bei 12 startet er nicht.
Ok, also vermutlich hängt der Upgrade-Prozess jetzt -- jedenfalls komme ich nicht mehr per ssh drauf.
Wie gehe ich nun vor, wenn ich vor Ort bin? Einfach auf der Konsole erneut die "12" oder was ist der beste Weg?
Ok, ein Kollege war vor Ort und hat gesehen, dass V20.7.1 aktiv ist ... zudem ist immerhin im Webinterface das Symbol für den Wireguard-Service auf "grün". Dennoch kommt keine Verbindung mehr zustande.
Ist das nun ein Bug oder was ist zu tun?
Kein Bug, falsche WireGuard config.
Der Kollege soll für deine IP Zugriff auf die UI freischalten (ohne VPN), dann schaust du mal.
Hi.
Ja, davon ist ja auch im zitierten englischen Thread zu lesen -- aber mir ist nicht ganz klar, was nun zu ändern ist. Bezieht sich die Netzmaske /32 auf die Client-Seite (also hier lokal) oder bezieht es sich auf die Endpoint-Konfiguration in der WebUI? Wo genau soll die /24 durch die /32 ersetzt werden?
Und so wie ich es verstanden habe, hat das nicht überall geholfen. Bei einigen lag es auch an einem anderen Problem??
Im Endpoint /32 in Local /24
Ich kann's zwar erst Montag nachsehen, aber damals bin ich dieser Anleitung gefolgt:
https://www.ja-ki.eu/2019/02/19/wireguard-vpn-mit-opnsense-und-tunsafe/
Da steht für die Endpoints bereits /32.
Ich hatte gehofft, dass die Anleitung einen Fehler hatte ... daher die Frage hinterher: Was tun, wenn bei den Endpoints bereits /32 steht?
Kannst du Mal ein anderes Netz nehmen und nicht das CGN? Eventuell zählt das zu Bogon
Du meinst, dass evtl 100.64.0.0/24 nicht (mehr) als Wireguard-Netz aktzeptiert wird?
Was hat sich denn im Vergleich zu 20.1 so grundlegend geändert, dass es daran liegen könnte??
Ich rate nur wenn du keine detaillierten Screenshots postest
Ok, jetzt bin ich vor Ort ... also die Endpoints stehen alle auf /32 -- der Wireguardserver auf /24.
Das sollte also stimmen.
Wenn ich den VPN-Tunnel z.B. vom Smartphone aus öffne, gibt es keine Fehlermeldung -- aber in den LiveLogs auf der OPNSense erscheint auch nichts. Ich meine, dass sonst zumindest der Verbindungsaufbau auf Port 51820 quittiert wurde??
Screenshots von local und endpoint
Ok, hier zwei Screenshots ... an der Konfiguration wurde wie gesagt nichts geändert.
In den Firewall-Logs erscheint aber auch keine Meldung mehr, dass auf Port 51820 eine Verbindung aufgebaut wird ...
Und kannst du testweise mal auf ein privates Netz statt diesem CGN stelleN?
Ich habe es testweise umgestellt auf 172.18.18.0/24 -- ändert leider nichts. Die Verbindung kommt nicht zustande. Zudem habeich auch alle anderen Endpoints außer meinen deaktiviert -- ebenfalls ohne Änderung.
Es bleibt weiterhin die Frage: Was hat sich von 20.1 --> 20.7 diesbzgl geändert? Woran kann das noch liegen?
Mich wundert auch weiterhin, dass die Protokolldateien (LiveLog) nicht das geringste zeigt ... oder wird das erst nach erfolgreichem Handshake angezeigt?
Auf der WAN Schnittstelle ist die Option "Block private Networks" aktiviert -- das hatte ich auch nicht geändert. Auch wenn ich diese Option deaktivere, ändert sich nichts.
Mach doch mal auf dem WAN einen packet capture auf port 51820 und schau ob da was ankommt.
Wenn ja, checken ob wieder was raus geht, wenn nicht, schauen ob du PBR machst? Oder MultiWAN?
... noch eine Beobachtung hinterher: Ich habe von zu Hause aus versucht:
nmap -sU -O -p51820 <mein-dyn-dns.name.de>
Das Ergebnis:
PORT STATE SERVICE
51820/udp closed unknown
Von "innen" (gleiches Subnetz wie die Firewall) bekomme ich da aber
51820/udp open|filtered unknown
Normal?
>> schauen ob du PBR machst? Oder MultiWAN?
Nein, beides nicht.
Quote from: mimugmail on August 24, 2020, 04:04:31 PM
Mach doch mal auf dem WAN einen packet capture auf port 51820 und schau ob da was ankommt.
Ich habe es so versucht:
tcpdump -i em0_vlan132 udp port 51820
Das ist das WAN Interface. Da kommen ein paar Pakete an, wenn der VPN-Tunnel offen ist und ich z.B. von hier aus einen ping absetze ... aber eine Antwort erhalte ich weiterhin nicht.
Also sieht es für mich danach aus, als ob die Verbindung von außen nach innen zwar klappt aber es dann nicht weitergeht
Kannst du den output von dem tcpdump hier posten?
Und dann auch gleich mit interface wg0 :)
Quote from: mimugmail on August 24, 2020, 04:59:22 PM
Kannst du den output von dem tcpdump hier posten?
Und dann auch gleich mit interface wg0 :)
Da steht nichts besonderes drin: Es erscheint nur immer wieder die Meldung:
"Handshake Initiation", zu der es offenbar aus irgendwelchen Gründen nicht mehr kommt.
Wenn ich den tcpdump auf wg0 loslasse, wird nichts in die Datei geschrieben.
Bitte, den output von tcpdump
Dump würde ich per PM schicken ... geht das?
Mir ist noch etwas aufgefallen:
Wenn ich den Service neu starte, erhalte ich:
[#] ifconfig wg0 inet 172.18.18.254/24 172.18.18.254 alias
[#] ifconfig wg0 mtu 1420
[#] ifconfig wg0 up
[#] route -q -n add -inet 172.18.18.10/32 -interface wg0
In diesem Beitrag steht allerdings:
https://forum.opnsense.org/index.php?topic=18386.msg83609#msg83609
ifconfig wg0 inet 10.1.1.1/32 10.1.1.1 alias in der ersten Zeile -- dort steht also auch wieder die kleine Netzmaske ... kann es damit zusammenhängen?
... und noch eine andere Beobachtung, von der ich auch nicht weiß, ob sie damit zusammehängen könnte:
dmesg meldet des öfteren:
wg0: link state changed to DOWN
tun0: link state changed to UP
tun0: changing name to 'wg0'
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
pflog0: promiscuous mode disabled
pflog0: promiscuous mode enabled
in_scrubprefix: err=65, prefix delete failed <<< was ist das!??
und auch:
pflog0: promiscuous mode enabled
wg0: deletion failed: 3 <<< was ist das!??
wg0: link state changed to DOWN
tun0: link state changed to UP
tun0: changing name to 'wg0'
komm mal ins IRC .. dann schauen wir schnell per teamviewer
Das Problem ist Dank der Hilfe von mimugmail gelöst.
Ich hatte eine Regel bzgl GeoIP aktiviert, die siche offenbar mit Wireguard in die Quere kam.
Die Ursache war also gar nicht Wireguard sondern die zusätzliche Regel -- sobald diese deaktiviert wurde, war der Tunnel wieder da.
Vielen Dank nochmals für den tollen Support! Darauf wäre ich nie gekommen...
Quote from: white_rabbit on August 25, 2020, 03:43:06 PM
Das Problem ist Dank der Hilfe von mimugmail gelöst.
Ich hatte eine Regel bzgl GeoIP aktiviert, die siche offenbar mit Wireguard in die Quere kam.
Die Ursache war also gar nicht Wireguard sondern die zusätzliche Regel -- sobald diese deaktiviert wurde, war der Tunnel wieder da.
Vielen Dank nochmals für den tollen Support! Darauf wäre ich nie gekommen...
Eventuell das da:
https://forum.opnsense.org/index.php?topic=18628.msg85768#msg85768
Quote from: fog on August 25, 2020, 01:44:04 PM
The cause were empty files *IPv4 in /usr/local/share/GeoIP/alias/.
Daran liegt es hier nicht ... die Dateien sind da und mit Inhalt gefüllt. Ich vermute eher, dass meine öffentliche IP aus irgendwelchen Gründen blockiert wurde.