[Info] Informationen zum Einsatz vom pfSense

welches denn wenn man fragen darf?

Bei mir werkeln inzwischen 3 APU2C4 (als Accesspoints) und ein Jetway JNF9HB-2930 (als Router/Firewall). Bessere Hardware fuer diesen Zweck kenne ich nicht. Das Jetway deswegen weil ich damit 6 Ethernetports fuer diverse Subnetze realisieren kann.

grauGolz schrieb:

und rennt wie Schmitz Katze.

Zum Vergrößern anklicken....

was soll das besagen? Es ist keine Aussage im wissenschaftlichen Sinne.

sparkie schrieb:

Es ist keine Aussage im wissenschaftlichen Sinne.

Zum Vergrößern anklicken....

Und nicht mal richtiges Deutsch ... sollte es nicht "wie dem Schmidt seine Katze" heißen?

vielleicht wollte er 'Dotcoms Katze' sagen?

lieber grosser und grauer Golz!

Danke dass du nach langer langer Zeit mal wieder eine Feststellung (die keine Werbung ist) zum Besten gibst. Ich habe schon befuerchtet du bist am Ende womoeglich doch noch ins F!B Lager uebergelaufen

Viel Spaß bei der Inbetriebnahme eines IP-Telefons hinter einer pfSense-Firewall, wenn dieses Telefon nicht von sich aus das "Offenhalten" einer ausgehenden UDP-Verbindung als NAT-Session zum Provider (SIP session keep alive - RFC 5626) unterstützt und der seinerseits nicht damit klarkommt, wenn da irgendein gammeliger NAT-Router sich als ALG für SIP versuchen will (es hat wohl seinen Grund, daß es die Optionen zum Abschalten des ALG gibt).

Ich glaube ja schon lange nicht mehr an konkrete Antworten (spätestens seit dem "bashing" in Richtung AVM im Zusammenhang mit dem Buffer-Overflow in den Lantiq-Quellen und meinem Hinweis, daß die in dem von Dir so stolz vor Dir hergetragenen Speedport 221 genauso vorhanden sind) ... aber ich kann ja trotzdem mal gespannt auf die Erklärung sein, wie man in diesem Szenario eingehende Anrufe über ein SIP-INVITE nach dem Ablauf der UDP-Session im Connection-Tracking der Firewall realisieren soll ohne irgendwelche Port-Forwardings. Überrasche mich (sicherlich auch andere) doch einfach einmal positiv mit einer fundierten Erklärung.

Und wenn Du schon mal dabei bist, kannst Du uns Unwissenden ja auch gleich noch erklären, wie ein externer SIP-Client sich ohne solche Einstellungen an einem SIP-Registrar hinter einer pfSense-Firewall registrieren soll (ein auch nicht unüblicher Einsatzfall) - alternativ nehme ich auch die Registrierung direkt an der Firewall als Ausweichlösung, wobei das schon wieder gegen die "reine Lehre" gehen würde. Auch eine VPN-Lösung würde ich hier nicht als ernsthaften Vorschlag ansehen, weil z.B. ein Heimarbeitsplatz mit einem PC und einem IP-Telefon nicht automatisch auch eine passende VPN-Verbindung ohne zusätzliche Technik oder zusätzliche Programme realisieren kann, über die sich dann das IP-Telefon als externer Client an einer SIP-TK (die wiederum hinter der pfSense-Firewall steht) registrieren könnte.

Beides sind Einsatzszenarien, wo eine FRITZ!Box als "high end"-Produkt praktisch direkt nach dem Auspacken und dem Einrichten der Internetverbindung ihre Stärken ausspielen könnte (einige andere Geräte auch, damit da keine "ungesunde Fixierung" auf eine FRITZ!Box diagnostiziert werden kann) ... manchmal hat eben so ein universell einsetzbarer Router (der definitiv auch seine Grenzen hat) auch echte Vorteile gegenüber anderen Lösungen (und das ist keine Werbung) ... aber wem will ich das erzählen.

Wenn Du dann mit der Erklärung hier fertig bist, kannst Du ja auch gleich noch Deinen eigenen Beitrag zur Weiterentwicklung von pfSense leisten und die (Teil-)Dokumentation für solche Szenarien entsprechend korrigieren. Ein lohnender Einstieg wäre dann vermutlich diese: https://doc.pfsense.org/index.php/PBX_VoIP_NAT_How-to

MfG

ein oberschlauer User

... der sich aber falsch zitiert fühlt - wahrscheinlich hast Du aber nur ein weiteres Mal etwas Falsches verstanden, denn ich würde natürlich niemals eine pfSense-Firewall durch den Einsatz einer FRITZ!Box hinter einer solchen "entweihen". Daß eine FRITZ!Box in der Tat in der Lage wäre, entsprechende NAT-Sessions am Leben zu erhalten, versteht sich praktisch von selbst ... irgendetwas muß sie ja schließlich zumindest in Ansätzen beherrschen, wenn sie sonst schon nichts kann (bzw. nichts richtig kann).

PS: Jetzt ärgere ich mich schon vor dem Absenden über mich selbst, daß ich überhaupt wieder darauf angesprungen bin ... manchmal ist mein Glaube an das Gute im Menschen eben doch zu groß und meine Naivität in Bezug auf die Lernfähigkeit einzelner Teilnehmer sollte mir vermutlich peinlich sein. Aber nachdem ich das nun schon mal geschrieben habe ... wäre ja schade um das Futter.

Zur SIP-Geschichte noch: UDP würde ich nicht empfehlen. Zumal ja zwecks TLS SIP über TCP die bevorzugte Variante ist. Die Unterstützung seitens der Provider ist da natürlich noch mangelhaft, trotzdem halte ich es für unverantwortlich unverschlüsseltes SIP zu verwenden.
Ein ALG kann dann natürlich auch nichts mehr machen.

@unrealzocker:
Wenn man tatsächlich bei Null anfängt und sich alle Technik aussuchen kann, hat man heute wirklich andere Möglichkeiten.

Aber was macht man z.B., wenn man einen (gammeligen) SIP-ATA für 2 FXS hat (und der nur SIP über UDP beherrscht) und den nun unbedingt weiterhin benutzen soll/muß, weil es eben bisher auch funktioniert hat und "der Kunde" keine neuen Geräte erwerben will?

Nicht überall kann man mit dem großen Einkaufswagen durch die virtuellen Regale im Versandhandel rennen und sich die gesamte Technik komplett neu zusammenstellen, wie man es gerade braucht. Bei einer Neueinrichtung sieht das naturgemäß anders aus.

Ansonsten ist die UDP-Unterstützung eben weiter verbreitet (und älter) als TCP ... solange es sich um den als Beispiel angeführten Heimarbeitsplatz der Telefonistin handelt (der Zugriff auf die Kundenliste erfolgt ganz ordentlich über eine TLS-gesicherte HTTP-Verbindung zu einem entsprechenden Server) und der Inhalt (RTP - die "Kommunikationsinhalte") der Telefonate und die Tatsache, daß es ein solches Gespräch gab (SIP - aka "Metadaten") alles andere als geheim ist, würde ich da gar keinen Aufwand treiben, um solche Sessions oder Streams zu verschlüsseln, wenn es nicht "abfällt" bei anderer Gelegenheit. Daß man darüber nicht die neueste Marketingstrategie bei der Expansion in den chinesischen Markt diskutieren sollte, versteht sich dann von selbst.

Wobei so ein "Lauscher" bei einem direkt über das Internet registrierten ATA schon eine recht exponierte Position einnehmen müßte, um dort RTP-Streams abzugreifen ... spätestens bei der Übertragung über einen der üblichen Provider ist das aber auch wieder alles unverschlüsselt - ich kenne praktisch keinen Provider (der gleichzeitig Access und Telefonie anbietet - zumindest keinen nicht-regionalen), der seinen Kunden verschlüsseltes RTP zur Verfügung stellt. Spätestens beim Interconnect ist dann ohnehin Schluß mit "geheim". Wenn hier jemand einen Provider mit Verschlüsselung kennt (wie gesagt, kein reiner Telefonie-Anbieter, der seinerseits den Kunden grundsätzlich nur über ein fremdes Netz erreichen kann, weil der bei einem anderen Access-Provider seinen Anschluß hat), nehme ich aber die Information dazu auch gerne zur Kenntnis - zumindest bis zum (Telefonie-)Provider wäre das dann "abhörsicher". Aber dahinter sieht es auch wieder schlecht aus ... insofern wünsche ich mir auch häufig eine bessere Welt, in der sichere Kommunikation viel weiter verbreitet wäre - die Realität sieht anders aus und die Entwicklung hin zum Einsatz von SRTP oder ZRTP sehe ich nicht.

Wobei es hier ja beim Einwand auch eher um die Verschlüsselung einer SIP-Session geht und die ist dann tatsächlich noch häufiger verzichtbar in meinen Augen, wenn die Daten hinterher ohnehin "offen" weitergeleitet werden (im INVITE beim B-Teilnehmer) oder für 10 Wochen beim Provider "gelagert" werden.

Eine RTP-Session (auch über UDP nach "hole punching") ist dann wieder ein wenig etwas anderes und da stellt sich die Frage eines NAT-Timeouts auch nicht, weil eben ständig Daten fließen (sollten), solange die Verbindung besteht und wenn die hinterher ins Timeout läuft, interessiert das niemanden mehr. RTP over TCP ist auch nicht immer zwangsweise eine richtig gute Idee, weil die Sicherungsschicht des TCP da mit Wiederholungen u.U. mehr kaputt machen kann, als es 20 oder 30 fehlende ms (in einem Paket) in einem Telefonat machen würden.

Intern kann man eh verwenden was man will, da geht auch UDP für SIP, aber alle externen Konten sollten verschlüsselt sein. Natürlich hat man dann intern kein NAT-Problem mehr. Extern kann man dann natürlich eine PBX verwenden die das kann.

Nicht zu verschlüsseln weil es "irgendwo" halte ich für wenig sinnvoll, der Ansatz sollte sein so viel wie möglich zu verschlüsseln. Das die VoIP-Provider sowas nicht anbieten ist natürlich schlecht und eigentlich hirnverbrannt.

Haa. Nutzer klagen wiederholt ueber die schlechte Performance und alte Treiber von OpenBSD/pfsense:

APU2C4 max throughput?

die Probleme kann ich z.B. auf Debian nicht nachvollziehen. Siehe die exzellenten Debian-Performancewerte, die dort beschrieben sind.

und, was sagst du jetzt als Frau dazu?