Eine APU ist ja ganz nett.
Jedoch werde ich mir keinesfalls eine APU2X an Land ziehen. Ich habe da ein anderes Teil im Radar.
Jedoch werde ich mir keinesfalls eine APU2X an Land ziehen. Ich habe da ein anderes Teil im Radar.
[Info] Informationen zum Einsatz vom pfSense
- Ersteller grauGolz
- Erstellt am
sparkie
Aktives Mitglied
- Mitglied seit
- 13 Nov 2005
- Beiträge
- 1,610
- Punkte für Reaktionen
- 26
- Punkte
- 48
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.
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.
Fragen darf man immer!
Natürlich die beste eierlegende Wollmilchsau eines hierzulande sehr beliebten "alles für das Heimnetz" werbenden Herstellers. Kleiner Scherz.
Die derzeit bei mir werkelnde APU1D wird durch diverse VPN Tunnel geknechtet welche das Teil zum Kochen bringen. Das gefällt mir nicht auf Dauer.
Deshalb wird das Teil früher oder später in Rente geschickt werden. Ich tippe mal auf früher. Der Klimawandel ist lästig.
Es gibt ganz nette Boards (C2000 Series) von Supermicro. Mehr als zwei Kerne brauche ich nicht. Etwas ECC-RAM draufgepappen und Spaß haben.
Das A1SRI-2358F (entspricht der SG-2440 Klasse von pfSense) könnte den Zuschlag bekommen.
Natürlich die beste eierlegende Wollmilchsau eines hierzulande sehr beliebten "alles für das Heimnetz" werbenden Herstellers. Kleiner Scherz.
Die derzeit bei mir werkelnde APU1D wird durch diverse VPN Tunnel geknechtet welche das Teil zum Kochen bringen. Das gefällt mir nicht auf Dauer.
Deshalb wird das Teil früher oder später in Rente geschickt werden. Ich tippe mal auf früher. Der Klimawandel ist lästig.
Es gibt ganz nette Boards (C2000 Series) von Supermicro. Mehr als zwei Kerne brauche ich nicht. Etwas ECC-RAM draufgepappen und Spaß haben.
Das A1SRI-2358F (entspricht der SG-2440 Klasse von pfSense) könnte den Zuschlag bekommen.
Nun, pfSense (nur eine Festellung) ist auf 2.3.1 und rennt wie Schmitz Katze.
Tipp:
Haproxy als Frontend mit OpenVPN als Backend macht Spaß.
Viele liebe Grüße aus Pakistan (man beachte den Kontext) sendet der
grauGolz
Tipp:
Haproxy als Frontend mit OpenVPN als Backend macht Spaß.
Viele liebe Grüße aus Pakistan (man beachte den Kontext) sendet der
grauGolz
sparkie
Aktives Mitglied
- Mitglied seit
- 13 Nov 2005
- Beiträge
- 1,610
- Punkte für Reaktionen
- 26
- Punkte
- 48
was soll das besagen? Es ist keine Aussage im wissenschaftlichen Sinne.und rennt wie Schmitz Katze.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,329
- Punkte für Reaktionen
- 1,770
- Punkte
- 113
Und nicht mal richtiges Deutsch ... sollte es nicht "wie dem Schmidt seine Katze" heißen?
pfSense 2.4, basierend auf FreeBSD 11, wird ARM unterstützen und dabei nicht zur eierlegenden Wollmilchsau mutieren.
pfSense 2.3.1 ist nicht tot. Schmitz Katze auch nicht. Sie rennt und rennt und rennt...
https://blog.pfsense.org/
https://blog.pfsense.org/
Ein oberschlauer User meint, man müsse Ports in einer auf pfSense basierenden Firewall aufreißen, um mit einer eierlegenden Wollmilchsau VOIP nutzen zu können.
Viel Spaß und Schaffenskraft beim Aufbohren seiner "high end" Produkte wünscht der
grauGolz
Viel Spaß und Schaffenskraft beim Aufbohren seiner "high end" Produkte wünscht der
grauGolz
sparkie
Aktives Mitglied
- Mitglied seit
- 13 Nov 2005
- Beiträge
- 1,610
- Punkte für Reaktionen
- 26
- Punkte
- 48
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
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
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,329
- Punkte für Reaktionen
- 1,770
- Punkte
- 113
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.
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.
Ein ALG kann dann natürlich auch nichts mehr machen.
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,329
- Punkte für Reaktionen
- 1,770
- Punkte
- 113
@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.
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.
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.
Zuletzt bearbeitet:
Keine Panik. Ich kann der Versuchung, eine eierlegende Wollmilchsau aus der Klasse der "high end" Geräte als Firewall zu verwenden, noch widerstehen.
Genutzt für Telefonkram hinter pfSense machen sie keine Probleme.
Genutzt für Telefonkram hinter pfSense machen sie keine Probleme.
pfSense droht wieder mal mit Update.
Die Version 2.3.2 kommt. Eine Version 2.3.3 wird es nicht geben.
Mit der Version 2.4 stirbt die Unterstützung für die 32-Bit Plattform.
Naja, eine ALIX-Kiste reicht für Telefonkram und OpenVPN-Gateway in der Pampa.
- - - Aktualisiert - - -
Die Version 2.3.2 kommt. Eine Version 2.3.3 wird es nicht geben.
Mit der Version 2.4 stirbt die Unterstützung für die 32-Bit Plattform.
Naja, eine ALIX-Kiste reicht für Telefonkram und OpenVPN-Gateway in der Pampa.
- - - Aktualisiert - - -
Zuletzt bearbeitet:
sparkie
Aktives Mitglied
- Mitglied seit
- 13 Nov 2005
- Beiträge
- 1,610
- Punkte für Reaktionen
- 26
- Punkte
- 48
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?
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?
Neueste Beiträge
-
Keine Multicast-Unterstützung mehr per WLAN?- Letzte: NDiIPP
-
Interne SIP-Telefonie ohne Anbieter- Letzte: stoney
-
[Frage] Welche DECT-Basis an Fritz!Box von Vodafone Cable
- Letzte: sunnyman
-
Fax mit Java API
- Letzte: sunnyman
-
Fritz 7590AX update 8.02 wan nur noch 100 Mbit
- Letzte: JoergFl
-
Fritz!Box 6690 8.02 trennt "idle" Verbindungen (SSH...)
- Letzte: dash2055
