[SOLVED] FAIL: Upgrade auf 20.7 via ssh ...

[white_rabbit]

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 ...

[mimugmail]

Und kannst du testweise mal auf ein privates Netz statt diesem CGN stelleN?

[white_rabbit]

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.

[mimugmail]

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?

[white_rabbit]

... noch eine Beobachtung hinterher: Ich habe von zu Hause aus versucht:

Code: [Select]

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.

[white_rabbit]

Mach doch mal auf dem WAN einen packet capture auf port 51820 und schau ob da was ankommt.

Ich habe es so versucht:

Code: [Select]

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

[mimugmail]

Kannst du den output von dem tcpdump hier posten?
Und dann auch gleich mit interface wg0

[white_rabbit]

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.

[mimugmail]

Bitte, den output von tcpdump

[white_rabbit]

Dump würde ich per PM schicken ... geht das?

Mir ist noch etwas aufgefallen:
Wenn ich den Service neu starte, erhalte ich:

Code: [Select]

[#] 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

Code: [Select]

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:

Code: [Select]

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:

Code: [Select]

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'


[mimugmail]

komm mal ins IRC .. dann schauen wir schnell per teamviewer

[white_rabbit]

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...

[mimugmail]

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

[white_rabbit]

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.