@JeGr
an was hast du Gedacht ?

Einen Provider zum Beherbergen deiner Rufnummern oder hauptsächlich zum raustelefonieren.

Meine Rufnummern hab ich momentan gesplittet, ein Teil meiner Rufnummern liegt bei Dus.net und ein anderer bei Sipgate.
Sipgate ist aber bei mehr als einer Nummer nur zu empfehlen, wenn du einen Asterisk Server betreibst. Ansonsten kannst du bei einem Basic Sipgate Anschluss nicht unterscheiden, auf welche Rufnummer angerufen wurde, weil du nur einen Sipaccount hast. Bei Dus sind es derweilen 5.
Beide Provider verlangen für das Beherbergen der Rufnummer einmalig für das Portieren Geld. Ab dann kostet es nichts mehr.

Da aber sowohl Sipgate als auch Dus nicht die günstigsten Verbindungspreise besitzen, kann ich für ausgehende Gespräche folgende Provider empfehlen…
Wer eine preiswerte Festnetz-Flat benötigt, der kann sich mal bei Toplink-Xpress umsehen. Dort kostet die preiswerteste Flat 2,90€ (Eine Leitung als Analog Ersatz), 5,80€ (Zwei Leitungen als ISDN Ersatz) und 11,60€ (4 Leitungen)

Für preiswertes Telefonieren (Fest und Mobil) ohne Flat, kann ich Voip2GSM empfehlen. 3,8ct/min ins Mobilfunknetz bzw 0,8ct/min ins Festnetz. Taktung ist 30/30

Beide Provider erlauben Clip no Screening, d.h. man kann die Ausgehende Rufnummer am Endgerät festlegen. (Ein Feature das nicht jeder anbietet.)

Aber nur bei Toplink kannst du ne echte Nummer beantragen, oder portieren lassen. Falls man alles bei einem Provider haben möchte.

Zickig ist meiner Erfahrung nach hauptsächlich Dus.net (Bei eingehenden Verbindungen). Aber wenn die Konfig passt, läuft auch Dus.net problemlos.

Vielen Dank,
Ich habe es mit einzelnen virtuellen netzwerken hinbekommen, verzeiht mir bitte für meine schlechte beschreibung.

mfg Kamil

Danke :)

Danke geht wieder

Hey,

danke, das war der entscheidende Tipp.
Ich hatte in der OpenVPN Interface Gruppe eine Deny all Regel am Ende. (Ich weiß es ist nicht notwendig, aber ich leg die trotzdem immer an, damit ich den Deny Traffic sehe und irgendwie aus Gewohnheit ;D )
Da diese natürlich immer gegriffen hat, ist die pfSense nie in das VPN Interface gesprungen.
Nachdem ich diese nun entfernt hat, funktioniert alles perfekt.

Danke dir.

Gruß
Jerico

Danke für den Tipp hornetx11,

mir fällt gerade ein das genau deswegen ein Schreiben ankam, in dem steht das wir auf wundersame Weise keine Zugangsdaten mehr benötigen  :o

…weil mit BNG die Zugangskennung und das persönliche Kennwort für die PPPoE-Verbindung wegfallen. Es gibt dann eine Line-ID, die fest mit dem Anschluss verknüpft ist

Also muss ich zwangsweise 2 Router mit den jeweiligen PBX noch vor meine pfSense schnallen? Dann kann ja alles außer die PCs gleich gekapert werden :P Besten Dank DTAG

@simpsonetti:

Ein Ping geht aber noch nicht raus. Da muss ich noch eine weitere Regel einbauen?

Scheint so, oder?
Ping nutzt als Protokoll ICMP, da würde ich mal schauen.

Was meinst du mit

dann werden einige Geräte ausgeblendet.

?

Der gewählte Bereich ist aber schon innerhalb "available range"?

100 IPs sollten ja reichen, oder? Die Leases müssen aber eventuell gelöscht und die Geräte neu gestartet werden.

Der Bereich muss nur in dem Subnetz des Interfaces liegen (IP und Maske), sonst ist es egal. 192.20.20.* ist allerdings keine gute Wahl, in diesem Bereich sind öffentliche Adressen. Ein privates Netz musst du schon wählen.
https://de.wikipedia.org/wiki/Private_IP-Adresse

@viragomann:

Hallo,

mit dem "aktuellen Status" meinst du wohl den den Gateway-Status, der über dpinger ermittelt wird?
Dieser wird aber auch in ein Log-File geschrieben, /var/log/gateway, und bleibt da bis das Log überschrieben wird.
Die Historie lässt sich auch grafisch darstellen: Status > Monitoring > Gateways
Falls nötig, lässt sich die Log-Größe auch erweitern, wenn du genug Speicherplatz hast, allerdings nur für alle Logs im gleichen Maß, doch sollte es beim Gateway ohnehin nicht so viel zu loggen geben, dass das so bald vollläuft.

Ich glaube das ganze hat sich wohl etwas geändert:
unter Status->Monitoring muss man in den Settings auf quality stellen und dann kann man beim Graph das GW aussuchen. Leider ist bei mir die Auflösung bei z.B. 1 Monat mit einer Stunde zu ungenau.
Ich habe da einen externen Dienstleister nixstats.com und der zeigt mir das ganz gut an.

Hmm, ich habe mit allen VPN Protokollen das selbe Problem.

Kann mir jemand Rules für die Freischaltung des LAN Zugriffes mitteilen? Solangsam blick ich wirklich nicht mehr durch :-(.

Welche Rules bauch ich wo für L2TP, IPSec und Open VPN?

22%?
Go Go Go  8)

@viragomann:

@Shadow27374:

ich kann eine Verbindung zum OpenVPN Server herstellen, die Rechner anpingen, auf das Intranet über Port 80 und 443 zugreifen und den Exchange nutzen.

bist du sicher, dass diese Verbindungen über VPN laufen? Verwendest du die interne IP, um auf diese Services zuzugreifen?

Ja, ich habe es auch per Android probiert und auch von zu Hause aus. Sobald die Verbindung steht, kann ich jeden Rechner anpingen und manche Dienste wie Intranet und Exchange nutzen.

@viragomann:

@Shadow27374:

Als Distribution für OpenVPN verwende ich pfSense, bzw. ich nutze pfSense als OpenVPN Gateway.

Das klingt, als würde diese pfSense nicht das Standardgateway im LAN sein.

Das ist richtig, die pfSense läuft imselben Netz unter 192.168.67.248. Der Standard-Gateway ist ein TP-Link mit openWRT.

@viragomann:

Wenn dem so ist und die pfSense ist Teil des LANs, benötigst du auf allen Geräten, die du via VPN erreichen möchtest eine Route für das Tunnel Subnetz, die auf die pfSense zeigt.

Am Wochenende habe ich nochmal alles mögliche ausprobiert, ich konnte mich sogar auf einen SSH-Server und einen alten XP-Client per RDP verbinden. Wenn etwas mit den Routen nicht stimmt, dürfte das ja auch nicht gehen.

@viragomann:

Alternativ kannst du auf der pfSense eine SNAT-Regel einrichten, um die Qelladressen der VPN-Pakete auf die des pfSense LAN IP umzusetzen.

Bessere Lösung, du schließt die pfSense an deinen Router (Standardgateway) an ein eigenes Subnetz an, wenn der das erlaubt, und erstellst auf diesem die statische Route. Wenn nicht, mach die pfSense zu deinem Router und Gateway ins Internet.

Muss ich mir alles noch mal sehr genau ansehen, bin da noch nicht fit genug.

Vielen dank für eure Unterstützung. Ich hatte den Reiter für OPT1 garnicht.
Der Fehler lag im Detail. Die IP für mein OPT1 Interface hatte ich falsch gesetzt.
192.168.1.1/32 geht natürlich nicht :))
auf /24 gesetzt… alles OK

Sorry, das "dein" war im Sinn: "Dein Posting" zu verstehen. Es ist mir klar, dass das nicht dein Video war. :) Ich sage nur, dass der Vergleich vielleicht nicht ganz fair ist zwischen einer konkret ausgearbeiteten Präsentation mit Folien und einer "Live Demo".

Und nachdem ich für einige Kunden jetzt auch pfSense Service spezifische Schulungen gemacht habe (kürzlich OpenVPN) kann ich da nur beipflichten: bei der Vorbereitung geht wirklich massig Zeit in Recherche und Zusammenstellung drauf um allein die Redepunkte und Inhalte dazu zusammenzutragen.

Mit Zielhost meinte ich das Gerät hinter der pfSense. Das, welches du vom VPN-Client aus erreichen möchtest.
Als Client hätte ich eben letzteren verstanden.

An den OpenVPN Einstellungen kann es meiner Meinung nicht liegen. Das Routing vom Client ins LAN auf der anderen Seite des Tunnel funktioniert ja. Mehr ist bei diesem Problem auf einem Access Server nicht relevant.

Das Packet Capture am OpenVPN Interface zeigt, wie du auch festgestellt hast, nur Antworten der pfSense selbst, während du auch andere Geräte im LAN pingst.

Der VPNrechner pingt, PFsense antwortet brav.
Aber keine Spur von den Pings zu den anderen Rechnern!?

Wenn du das untersuchen möchtest, mach ein Capture am LAN-Interface (ohne Details). Das zeigt, ob die Pakete überhaupt an der pfSense ankommen. Ich vermute mal, nein.

Am WAN pingt die pfSense das eingestellte Gateway (dpinger), allerdings sollten da schon Antworten von der FB kommen, ansonsten wird das GW als offline angezeigt.

Auch interessant wäre die Routingtabelle (route, route print) vom Zielhost und ggf. ein TCP Dump an dessen Schnittstelle.

Danke
Ich Teste mal deine konf. mal schauen ob was läuft mit Windows Update  ;)

Nein, nein, so leicht lässt sich die pfSense nicht täuschen. Die Verbindung geht ja tatsächlich von einem Host in 10.1.1.0/24 nach 10.1.2.2 und die Pakete kommen in diesem Fall am LAN1 Interface rein. Daher muss auf LAN1 eine entsprechende Regel den Zugriff erlauben.

Ein Portforward-Regel kann die Firewall-Regel automatisch anlegen, entweder sichtbar oder unsichtbar.
Ein Tipp für ein kleine Erleichterung dazu: Wenn du bei "Filter rule association" "Add unassociated filter rule" wählst, wird eine von der NAT-Regel unabhängige Firewall-Regel am jeweiligen Interface erstellt. Diese kannst du dann in Firewall > Rules > WAN kopieren (Symbol rechts), danach editieren und das Interface auf LAN1 und die Source entsprechend ändern, damit sie für deine Zwecke pass.

Besten Dank euch beiden!  8)

Oh sorry, ich meinte natürlich den Fehler im ersten Post. Das andere ist dann ein fehlendes Zertifikat beim Client - zumindest wird keins vorgelegt aber erwartet.

Hallo astartusfi,

zuerst einmal: das wird sehr wahrscheinlich nicht funktionieren. Google Authenticator nutzt TOTP als Verfahren, Radius o.ä. mit OpenVPN verwendet aber M-OTP als Verfahren für Einmalpasswörter. Du bräuchtest also eine andere App dafür bzw. einen anderen Generator.

Zum anderen:

jedoch ist mir Zertifikat-und-Benutzername/Passwort zu wenig Sicherheit

Das überrascht mich dann doch, denn wieviel Sicherheit möchtest du denn bei einer VPN Einwahl noch!? Du hast mit der maximalen Stufe von OpenVPN unter pfSense ja bereits 3(!) Faktoren (nicht nur 2) die alle getrennt voneinander gegeben sein müssen:

Session Key User + Passwort Zertifikat des Users (sinnvollerweise mit CN=username matching)

Alle 3 Faktoren müssen vorhanden sein, um die Einwahl vorzunehmen. Und selbst dann - sollte jemand aus doofen Gründen komplett das gesamte Paket verlieren - ist es noch möglich, problemlos das Zertifikat per CRL zurückzuziehen und den User zu disablen (im Radius). Da frage ich mich schon, wieviel Sicherheit du noch erkaufen möchtest mit wieviel zusätzlichen Faktoren? Denn wenn du davon ausgehst, dass alle einzelnen Daten wie Konfiguration, TLS Key, Zertifikat, Username + Passwort jemand anderem in die Hände fallen können, was hält den dann davon ab, dein OTP zu klauen (sprich die App oder die Einstellungen)?

Grüße