[Info] Informationen zum Einsatz vom pfSense

Hurra! Ich kann jetzt wieder ruhig schlafen!

Warum?

pfSense sagt mir jetzt:

2.3-RC (amd64)
built on Thu Mar 31 23:48:37 CDT 2016
FreeBSD 10.3-RELEASE

Das pöse pöse BETA-Stadium ist dahin.
 
und wo ist bitte der Hinweis "Wie immer keine Werbung, nur eine Feststellung." ???

Bitte ergaenzen. Danke.
 
Feststellung, Tatsache, Fakt. Kann sich jeder was raussuchen oder auch nicht.

- - - Aktualisiert - - -

Dieses unerträgliche PPTP (Server) wurde von pfSense 2.3 als VPN Protokoll ausgemerzt.

grauGolz sagt DANKE.
 
grosser grauGolz ich blicke zu dir auf und moechte dir (auch im Namen der vielen interessierten Mitleser) fuer die aktuellen Informationen danken, die du hier unermuedlich postest.
 
Ich schließe mich an und fordere hiermit einen deutschen Hersteller dieser unseligen eierlegenden Wollmilchsäue (dessen Namen ich nicht nenne, aber es ist keine Werbung) ultimativ auf, ebenfalls auf PPTP in der Firmware zu verzichten ... ansonsten werde ich mich anderen Herstellern zuwenden und keine Gelegenheit versäumen, gegen diese Geräte (mehr oder weniger versteckt) Stellung zu beziehen.

So geht es ja nun nicht ... wie es richtig funktioniert, machen große Hersteller wie Cisco oder Bintec vor.

Zwar jährt sich der (praktische) Todestag von PPTP mit MSCHAPv2 dieses Jahr zum vierten Mal (https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/), aber man kann immer noch bei Bintec Lizenzen für 25 PPTP-Clients erwerben.

Es wird Zeit, daß das Internet dagegen aufsteht ... aber "uns aus dem Elend zu erlösen, können wir nur selber tun.". Also sollte man das auch bei anderen Produkten einfach nicht mehr einsetzen, dann gibt es auch keinen Grund mehr für die Hersteller, entsprechende Server zu implementieren.

Laßt uns den Herstellern von pfSense folgen ... nieder mit PPTP (und eierlegenden Wollmilchsäuen) !!11elf!

EDIT: Werft die Produkte mit der Ananas am besten auch gleich in den Orkus oder entledigt Euch ihrer bei der nächsten Passage des Marianengrabens. Wer besonders perfide sein will, stiftet solche Geräte seinem örtlichen NSA-Residenten, denn diese Geräte sind Teil des Problems: https://support.apple.com/de-de/HT201533
 
Zuletzt bearbeitet:
Nette Möglichkeiten bietet pfSense mit dem Paket HAProxy. Stichworte sind hier zum Beispiel OpenVPN und stunnel.

Kann ich mich noch auf die Konditionierung verlassen? Bin gespannt.
 
Einige obscure Pakete (asterisk und viele andere) wurden mit pfSense 2.3-RELEASE in die ewigen Jagdgründe geschickt. :)

Was hat man denn so?

Squid, haproxy, openvpn-client-export.

Was braucht man noch?
 
Zuletzt bearbeitet:
Einige obscure Pakete (asterisk und viele andere) wurden mit pfSense 2.3-RELEASE in die ewigen Jagdgründe geschickt.

@GrauGolz:
Was ist denn an Asterisk Software obscure (verworren) ?
Bitte um sachliche Beiträge und keine Software verunklimpfen!

an die IPPF Leser,
Asterisk wurde von Mark Spencer https://de.wikipedia.org/wiki/Mark_Spencer vor mehr als 10 Jahren entwickelt und zeichnet sich u.a. durch Multiplattformsupport und hervorragenden Wählplan (Dial Plan) aus;
Inzwischen gibt es zig-tausend Asterisk-Nutzer weltweit, die dieses Produkt als PBX einsetzen.
Ob man TK-Software (Asterisk, SIP-ALG, ...) auf einem Firewall-System haben möchte oder nicht, dies hängt von den jeweiligen Security-Rules ab und muß jeder für sich abwägen.

@GrauGolz:
dein Spruch "Wer keine Ahnung von dieser Software hat sollte besser schweigen" aus Posting 2051104 solltest Du bzgl. Asterisk selbst beherzigen.

LG Tuxedonet
 
Telefonkram hat auf einer Firewall nichts zu suchen. Deshalb ist die Entfernung des Paketes Asterisk in pfSense 2.3 zu begrüßen.

Diese Entscheidung der Entwickler von pfSense hat nun gar nichts mit der "Nützlichkeit/Qualiät" von Asterisk zu tun.

Nicht nur das Paket Asterisk wurde in pfSense 2.3 als obscurer, sinnloser Ballast entfernt. :)

Folgerung:
Ich weine dem Paket Asterisk auf pfSense keine Träne nach.

Es soll Nutzer von pfSense geben, welche igmpproxy benötigen. Selbige schauen mit pfSense 2.3 in die Röhre.
Das Teil rennt (noch) nicht.
 
Zuletzt bearbeitet:
@GrauTroll:
Bitte keine Fehlaussagen hier verbreiten!
diese Postings mit Meinungsverfälschung/Lügen will niemand.
siehe #69 vs. #70

@unrealzocker
Danke für den Link

an die interessierten Leser:
Asterisk wurde aufgrund "no package maintainer, not converted" aus pfSense 2.3 entfernt.

LG tuxedonet
 
Zuletzt bearbeitet:
Ws etwas störend ist, ist das Thema IPv6 in pfsense:
- Leider wird die dynamische Zuordnung des Präfix, wie sie die DTAG vornimmt, in pfsense nicht unterstützt.
- Schaltet man einen Consumerrouter davor (z.B. Fritzbox), kommt es zu dem seltsamen Phänomen, dass nach Neuzuweisung des Präfix zwar die Endgeräte neue IPv6 bekommen, die alten aber nicht als deprecated gekennzeichnet werden (jedenfalls nicht zuverlässig, so passiert auf meinem Asterisk-Server.)
Da ich pfsense nicht missen möchte, habe ich jetzt DautschlanLAN bestellt, damit ivh kein wechselndes Prefix mehr habe.

Was Pakete auf einer Firewall angeht: Natürlich ist das immer ein Risiko - ob es aber grundsätlich höher ist, als wenn man die entsprechenden Ports öffnet, auf die gleiche Software auf einem dahinter in eigenem Netz reagiert, ist natürlich so eine Sache. Das Hauptproblem, das bei Paketen auf der Firewall besteht, ist m.E., dass die Pakete nicht unbedingt so aktuell sind, wie es die Software auf einem eigenen dedizierten Rechner für diesen Zweck sein kann. Insofern ist der offizielle Grund, warum das Paket Asterisk rausgeflogen ist, letztlich auch der Grund, dass die Sicherheit ohne jemanden, der sich um das Paket kümmert und aktuell hält, nicht gegeben ist.

Für mich gilt letztlich: Auf eine Router/Firewall gehört nur das, was unbedingt dort sein muss.
 
Ich werde das "Thema" igmpproxy auf pfSense kurz und endgültig abhandeln.

Dieser "Dienst" dient nur zur Verschwendung von Lebenszeit.
 
Ein in "policy routing" verwendetes Gateway für "OpenVPN TAP Clients" funktioniert nun mit pfSense 2.3.

Bei "OpenVPN TUN Clients" gab es zuvor keine Probleme bzgl. Gateways.

Ich wollte eigentlich meine Regeln in den LAN-Netzen auf das zu erwartende Verhalten ausrichten. Dann trat dieses Problem auf und
ich mußte in den Regeln auf das WAN-GATEWAY setzen. Weniger Flexibiltät und mehr graue Haare. :)

Viel Spaß noch mit "policy routing"wünscht der

grauGolz
 
Ein in "policy routing" verwendetes Gateway für "OpenVPN TAP Clients" funktioniert nun mit pfSense 2.3.


@GrauGolz:
so ein "da gibt's was, aber ich sage nicht wo man weitere Informationen findet" Spiel ist doch Bullshit;
Bitte lerne doch mal, wie man Quellenangaben macht, und wende dies an,
so dass nachfolgende Leser deine Postings und deren Sachverhalt ohne Klimmzüge nachvollziehen können.

an die pfSense-Interessierte:
ich denke es geht um pfSense Bug #5835: "Improve OpenVPN client gateway detection in edge cases where the remote does not send gateway information"
siehe: https://redmine.pfsense.org/issues/5835
weitere Infos zu Neuigkeiten oder Änderungen zu pfSense sind hier zu finden:
https://doc.pfsense.org/index.php?title=2.3_New_Features_and_Changes

LG Tuxedonet
 
Mein Beitrag #74 in Bezug auf "OpenVPN TAP Clients" hat NICHTS mit dem in Beitrag #75 erwähnten Bug in pfSense zu tun.
Wer pfSense wie ich seit vielen Jahre nutzt, wird das angesprochene Problem sofort einordnen können.

Ich schätze der Autor von #75 hat nur "dünne" Kenntnisse von pfSense, muß aber zwanghaft andere Nutzer belehren. Was soll das?


Viel Spaß noch mit "policy routing" wünscht der

grauGolz
 
Wer pfSense wie ich seit vielen Jahre nutzt, wird das angesprochene Problem sofort einordnen können.

@GrauGolz:
Toll für Dich, dass Du so "schlau" bist:wink: ... man könnte auch sagen "Eigenlob stinkt";
das Nichteingehen auf andere Leser ist für mich jedoch mehr ein Zeichen der Lernresistenz;

@interessierte Leser:
policy-based Routing (PBR) ist kein Alleinstellungsmerkmal von pfSense-Systemen, dies wird u.a. auch auch von DD-WRT Routern bereitgestellt.

Gruß
PantaRhei
 
Ein paar Hintergrundinformationen zum Beitrag #74.

Wenn man in pfSense einen OpenVPN Client einrichtet wird auch ein Gateway (Typ ist dynamisch) angelegt, welches für "policy routing" verwendet werden kann.
Die Übermittlung der beim Start des Clients ausgehandelten IP-Adresse an das System erfolgt mittels "vpn_gateway".
Dummerweise macht das OpenVPN zur Zeit nur wenn man "vpn_gateway" beim Anlegen einer Route verwendet (z. B. "route a.b.c.d 255.255.255.255 vpn_gateway").
Dieses Verhalten von OpenVPN ist sicher hinderlich im Zusammenhang mit "policy routing".

Das ist bei OpenVPN Clients zu beachten wenn man nicht nur mit dem Holzhammer "redirect-gateway def1" arbeiten möchte.

Der in Beitrag #74 angesprochene Fehler und in pfSense 2.3 behobene Fehler bei "OpenVPN TAP Clients" betraf die fehlende Auswertung von "vpn_gateway"
unabhängig vom Wert dieser Variablen.

Viel Spaß noch mit pfSense und "policy routing" wünscht der

grauGolz
 
Zuletzt bearbeitet:
Ein paar Bemerkungen zu VOIP hinter pfSense mittels "gefreetztem Speedport W701V hinsichtlich Telekom als VOIP Anbieter.

Ports auf pfSense zum AVM-Teil aufreißen ist NICHT erforderlich. Einfach "Outbound-NAT" für das AVM-Teil auf "static port" setzen und Spaß haben.
STUN ist auch nicht nötig.
 
das aktuelle APU2C4 ist inzwischen guenstiger zu haben als das alte APU1D4. Bringe doch am besten mal den Thread-Titel auf den neuesten Stand.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.