pfSense: OpenVPN Port ändern schlägt fehl!

[Tommes]

Hi!

Aktuell betreibe ich auf meiner pfSense erfolgreich den OpenVPN Server. Der OpenVPN Port wird dabei über eine vorgeschaltete Fritzbox an die dahinter liegende pfSense durchgereicht. Die pfSense ist somit nicht als "exposed Host" in der Fritzbox deklariert.

Internet -> Fritzbox -> OpenVPN Port -> pfSense -> ....

Wie gesagt, das funktioniert alles wunderbar und ich kann mich von diversen Clients aus per VPN verbinden. So weit. So gut!

Im Zuge eines DDNS Anbieterwechsels, war ich gezwungen, meine OpenVPN Konfiguration auf der pfSense entsprechend anzupassen. Auch alles kein Problem. Funktioniert alles wie gehabt.

Dann habe ich mir den Spaß erlaubt und wollte den OpenVPN Port ändern, und zwar von einem alternativen UDP Port, nennen wir ihn 54321, zurück auf den Standard UDP Port 1194. Und genau das funktioniert bei mir nicht, trotz das ich in der Fritzbox die Portweiterleitung auf 1194 UDP umgestellt habe und ich auf der pfSense die WAN Rule ebenfalls auf Port 1194 angepasst habe.





Ebenfalls habe ich die geänderten OpenVPN Konfigurationen über die "Client Export" Funktion der pfSense auf meine Clients überspielt. Eine Verbindung kommt jedoch nicht zustande. Stattdessen spuckt mir die pfSense immer das hier aus...



... und im OpenVPN Protokoll auf meinen Clients wird mir das bestätigt.

Ich weiß grad nicht weiter, aber irgendwas muss ich wohl vergessen haben, umzustellen. Die Frage ist nur: WAS? Aus den Protokolleinträgen werde ich irgendwie nicht schlau. Ich wüsste auch nicht, wo ich nach einer "Default deny rule IPv4" suchen sollte. Hat jemand von euch vielleicht eine Idee, wie ich dieses Rätsel enträtseln kann?

Tommes

 

[Barungar]

Ich kenne mich nicht speziell damit aus; nur allgemeine theoretische Grundlagen.
Mit fällt auf, dass die Meldung Deiner pfSense sich auf eine default deny rule bezieht.
In den meisten Firewall-Implementationen werden die Regeln "von oben nach unten" abgearbeitet.
Eine Regel, die IP-Verkehr zu Port 1194 erlaubt, muss demnach in der Regel-Tabelle oberhalb der default deny rule stehen.
Vielleicht hilft das?

 

[Tommes]

Eine Regel, die IP-Verkehr zu Port 1194 erlaubt, muss demnach in der Regel-Tabelle oberhalb der default deny rule stehen.
Vielleicht hilft das?

Nein, das hat nicht wirklich geholfen, weil es auf dem WAN Port, oberhalb der OpenVPN Rule nur einen "Block bogon networks" Eintrag gibt.

Indirekt hast du mir trotzdem geholfen, denn ich konnte den Fehler grade beheben. Es lag an den Floating Rules des pfBlockers und Floating Rules haken sich ja auch an die WAN Rules an. Nachdem ich den pfBlocker einmal deaktivert und wieder aktiviert hatte und somit die Rules neu geladen wurden, funktioniert die OpenVPN Verbindung über Port 1194 nun. Fragt sich nur, was pfBlocker da zu suchen hat.

Echt verrückt. Da suchst du 3 Tage wie ein Blöder nach einer Lösung, postest aus lauter Verzweiflung einen Beitrag ins Forum und 10 Minuten später fällt einem die Lösung vor die Füße. Bescheuert, oder?

Tommes

 

[the other]

Moinsen,
ja, die floating rules habe ich auch schon vergessen gehabt und mich dann gewundert...
Aber bescheuert? Nö, menschlich. Manchmal hat mensch halt Tomaten auf den Augen oder zu wenig Kaffee am Morgen.
Bescheuert wäre es (wenn überhaupt gewesen) sich in so einem Fall nicht kurz mal im Forum zu erkundigen.
Schön, dass es sich aufgeklärt hat.

 

[the other]

Moinsen,
ist jetzt zwar off-topic, aber was mit gerade noch als Anekdote zu "bescheuert" eingefallen ist:
gestern Abend wollte ich mal eben im Netzwerkschrank ein, zwei Dinge "umstöpseln", wie immer mal "so nebenbei, auf die Schnelle" und nicht gut vorbereitet (husthust). Dabei gab es bei der ds218 dann ein "KLACK" Geräusch und das gute Ding war aus, tot. Hm, Kabel hinten am Gerät steckt fest, an der Steckdose auch...keine Reaktion beim Einschalten. Na gut, dachte ich, Shit happens...und dann vorsorglich bräsig alle hyperbackup und snapshot replication Aufgaben gelöscht. Dann recherchiert nach Ersatz, mächtig geärgert, weil eigentlich andere Dinge auf der Wunschliste für 2024 stehen, aber sei's drum...
Stunde später wollte ich das vermeintlich defekte NAS dann aus dem Schrank holen...und dabei sehe ich, dass die ds218 ja noch den Zwischenstecker hat...der natürlich NICHT eingesteckt war...alles wieder verbunden, eingeschaltet...läuft. Das "KLACK" war der fallende Zwischenstecker...Erster Facepalm!
Dann gedacht: Mist, alle Hyperbackup und snapshot replication Jobs gelöscht...verdammt! Zweiter Facepalm!
Kurz geärgert und in die Tischkante gebissen...dann Tee gemacht, die backup und snapshot Aufgaben komplett neu angelegt (stand eh mal an, da einiges umorganisiert)...

Jetzt ist alles wieder gut.
Merke: es ist selten schlau, "mal eben, auf die Schnelle" an der IT rumzufriemeln. Weiß ich ja eigentlich auch, aber...tja. Dummheit wird eben bestraft. Wenn dann noch kopflos agiert wird wie Hühner bei Gewitter...schlechte Kombination.
DAS nenne ich dann eben "bescheuert".