Derelict hat dieses Tutorial diesbezüglich verfasst. Kann bestimmt dem ein oder anderen helfen. https://www.infotechwerx.com/blog/Policy-Routing-Certain-Traffic-Through-OpenVPN-Client-Connection

Hätte da jetzt noch eine Frage zu.
Habe ich es nun richtig verstanden, dass dieser "Bug" nur dann auftritt wenn man OVPN o.Ä. auf dem PC laufen hat und die VPN Connection nicht am Router terminiert? Weil UPNP anscheinend den Port für das WAN und nicht für das VPN Interface öffnet?

Gruß

Fehler gefunden - wie so oft Layer8!

@fork:

Nun habe ich die Option 'Enable authentication of TLS packets.' aktiviert und den Inhalt des Felds mit dem Schlüssel als Datei innerhalb von ~/.openvpn auf den Clients abgelegt und im Network-Manager (KDE) referenziert.

Der Fehler war, dass ich den von der pfsense vorangestellten Block:

# # 2048 bit OpenVPN static key #

mit in die Datei auf dem Client kopiert hatte.
Damit kommt openvpn nicht zurecht, diese Datei darf keine Kommentare enthalten und muss so beginnen:

-----BEGIN OpenVPN Static key V1-----

@viragomann: Schlüsselrichtung 'Client (1)' war korrekt.
TNX

Nein, die Einstellungen stimmen nicht.

Er noch viel lernen muss, junger Padawan. ::)

Habe es nach deinen Angaben so konfiguriert und den IP Bereich mit 192.168.10.8/29 eingeschränkt. Nett von Sony, dass es den Port für XBox Live gleich mit öffnet. :)

Es läuft geschmeidiger, kein NAT Type von strict oder modarate, alles offen. Werde mal sehen, was passiert, wenn beide XBoxen ins Net wollen.

Danke für die Hilfe

Edit:

Beide XBOXen gehen nicht gleichzeitig online. :-\

und wenn Du schon SIP direkt ins Internet hängst, nimm einen anderen Port als 5060, z.B. 6060.

In Zeiten, in denen NMap und ZMap durch bessere Algorithmen locker in Sekunden ganze IPs komplett abgescannt haben, bringt dieses Portverbiegen à la "Security through Obscurity" auch nichts mehr. Wenn jemand ernsthaft nach SIP scannt, scannt er nicht nur stumpf IP/Port sondern schaut sich ggf. IP Header und Paketheader an. Natürlich hilft das erstmal gegen total stumpfe Bots oder Kiddies, nur sich damit sicher(er) zu fühlen ist komplett falsch. Zudem gibt es leider genug Hardware/Gegenstellen, die SIP auf einem anderen Port gar nicht erst aushandeln wollen.

ja klar ist ja auch logisch  8)
vielen Dank

Tja das mit dem Regelwerk habe ich auch schon vorher praktiziert.
Aber als mein Ältester (12), in einem Moment der Unachtsamkeit, mir über die Schulter sah als ich das Passwort in die Pfsense eingetragen habe, hatte er als ich auf Dienstreise war einfach das Regelwerk zu seinen Gunsten angepasst. :o

Folge: Stärkeres Passwort in der Pfsense und ein HDD-Hotswapschacht im PC meines Sohnes :D

Wobei es mich mehr ärgerte, dass er sich dabei erwischen ließ. Er hätte einfach das Regelwerk nochmal zurücksetzen müssen als ich wieder zuhause war.

Weißt du ob das für andere FritzBox Modelle auch kommt?

Das sollte sich dann hoffentlich mit 2.3 und dpinger endlich erledigt haben.

Guten Abend!

Nochmal danke für die Tipps!

Der Link von magicteddy war die Lösung.

Was war der Punkt: ich hatte in putty bei sofort Connection auf "Serial" geklickt.
Richtig gewesen:
1.) Unter "Session" -> Serial auswählen
2.) Dann unter "Connection" -> "Serial" die Einstellungen machen und open klicken.

Wieder was gelernt…

Jetzt öffnet sich ein leeres schwarzes Fenster und es kann weiter gehen, ich bin gespannt und drohe schon mal an, dass bestimmt noch die eine oder andere Frage kommen wird ;-)
Danke Euch!

VG
Chris

Moin zusammen,

es scheint wirklich am Speedport gelegen zu haben. Seit dem wir das Zyxel Modem inkl. VLAN Konfig in der pfSense haben tritt das Problem nicht mehr auf.

VG
Andreas

Von solchen unergründbaren Zuständen wurde ich bislang glücklicherweise verschont.

WAN und LAN sollte wirklich nicht auf demselben Netz liegen, war aber möglicherweise ein Schreibfehler. Ist dein erstes WAN nicht 95.130.160.0/21 auf re0?
Das 192.168.4.0/24 fehlte in der Routingtabelle gänzlich. Seltsam.

Wenn der Ping von der WAN- aber nich von der LAN Schnittstelle geht und das Gateway in Ordnung ist, liegt es vermutlich am nicht konfigurierten Outbound NAT.
Bei CARP, muss das manuell konfiguriert werden, damit die WAN VIP benutzt wird.

Hallo JeGr

Herzlichen Dank für deinen Support!!
Ich habe unter den OpenVPN einstellungen von PF Sense noch die PF als DNS Server1 eingetragen und somit hat's geklapt!

Ich danke recht herzlich für diesen super Support!

Grüsse

Oki, wird ja noch etwas dauern bis die Probleme auftauchen können, wenn es grundsätzlich funktioniert ist das aber schon mal gut zu wissen.
Ich würde gerne eine längere Ausfallzeiten bei der Telefonie vermeiden.

Evtl. schau ich mal ich ich einen Versuchsaufbau hinbekomme ohne in die bestehende Infrastruktur einzugreifen.

Hatte Sixxs nicht anfänglich Probleme auf der pfSense weil es nur mit einem eigenen Client vernünftig lief? Irgendwas war da warum ich das übersprungen hatte als Test damals… aber wenn das jetzt eine Option ist, wäre das durchaus schick :)

Da es ein LCDPROC Package für die pfSense gibt und es auf der von Teddy geschilderten Seite heißt, dass alle Boards mit Chipsatz HD44780 unterstützt werden, denke ich, dass eine gute Chance besteht, dass der Kram läuft. Da er via USB angebunden wird und alles weitere dann lcdproc übernehmen sollte, könnte das ganz gut hinhaun.

Hallo,
habe am Wochende die FW neu gebootet.
Leider noch immer das gleiche Ergebnis.
Der Verkehr landet ohne statischer Route von IpSec mit Ziel 10.135. am WAN-Interface.
Setze ich eine Route, landet der Verkehr am LAN-Interface.

Wie komme ich an das Problem mit dem Routing heran?

Servus
Andi