Solltest du es schaffen, das zu deaktivieren, stelle bitte sicher, dass du auch die Haken bei den Interfaces nicht gesetzt hast.
Da das Update der Bogon-Netzwerkliste allerdings ein System-Cron ist, lässt der sich nicht ohne weiteres deaktivieren.

Kannst du uns vllt. aufklären, warum du das überhaupt alles abschalten willst!?

Grüße

Nein, darum gings mir aber auch nicht :)
Ich wollte lediglich darauf hinweisen, dass - nur weil man den Router bspw. gegen eine pfSense ausgetauscht hat - man standardmäßig erst einmal gar nichts ändern muss. Wenn man das muss, hat man noch irgendetwas anderes gebaut, dazugestellt, geändert, umgebaut oder sonstwie gedreht.

Und genau das muss man erstmal wissen, sonst kann ich schlecht helfen ;)

@cisto das kommt darauf an was du dafür haben möchtest, dann kann ich sie dir sicherlich fürs Labor abnehmen.

Herumärgern musst du dich sicher nicht damit, aber ich denke du hast einen einfachen Fehler gemacht, denn du schreibst nichts von einem DSL Modem, sondern nur der Buchse in der Wand. Wenn du aber DSL hast, geht es nicht ohne DSL Modem. Das hat dabei nichts mit Telekom Routern o.ä. zu tun, sondern lediglich damit, dass eben PPPoE gesprochen werden muss und nicht reines IP. Ich vermute jetzt mal mit meiner Glask,ugel dass das dein Problem ist. Nach einem Tag aber schon aufzugeben und die Hardware hinzuwerfen ist … schnell.

Grüße
Jens

Hallo Victor,

weshalb willst du die Config denn überhaupt auf andere Geräte verteilen? Du sprichst ja explizit nicht von HA, Failover oder Sync. Um was geht es denn konkret?

Grüße
Jens

Also wenn SSH läuft und du auf die pfSense kommst, ist was wirklich sehr komisch. Ich würde fast sagen, wenn du per iLO draufkommst, installiere die pfSense nochmal mit 2.1.4 komplett frisch und setz sie genau nochmal so einfach auf. Im dümmsten Fall hat sich jetzt die Autolockout Rule verklemmt oder was anderes durch die Umkonfiguration, deshalb einfach auf Nummer sicher gehen. Denn normalerweise solltest du nach einem pfctl -d auf jeden Fall dann auch per Browser draufkommen. Dann blockt der Filter erstmal gar nichts mehr, NATtet aber auch nicht etc., deshalb kann man meist dann auch nur von LAN Seite drauf. Nicht dass du jetzt unglücklicherweise die WAN Seite zum LAN gemacht hast und dort dann automatisch rausgeworfen wirst ;)

Grüße

Hallo JeGr,
habe es mit der Range ausprobiert, leider ohne Erfolg  :(

Hab langsam wirklich das Gefühl das Upnp nicht class b fähig ist oder es sich hierbei um einen bug handelt.

Danke,

werde ich mir mal ansehen.

lg, markus

Das ist doch Perfekt, es ist Immer toll wen man es selber herausfindet  ;)

@Stroker:

das hat soweit funktioniert allerdings sollte man vorher den Haken bei "Enable automatic outbound NAT for Reflection" in der Firewall/NAT Konfiguration setzen.

Das geht bei mir auch ohne.

Ich habe für das OpenVPN, DMZ und LAN Interface überhaupt keine Outbound NAT gesetzt, nur für WAN, und hier klappt es.
Ich habe auf einem OVPN Client auch einen Server laufen (XSever) und der funktioniert mit Hosts in der DMZ.

Wie erwähnt, Packet Capture ist ein feines Werkzeug und kann dir Probleme verraten.

Grüße

https://forum.pfsense.org/index.php?topic=78347.0

Laut der MAC-Adresse handelt es sich bei der Gegenstelle um eine Cisco-Komponente, die können mit der VLAN ID 0 umgehen und nutzen die wohl auch. Kann es sein, dass pfSense damit nicht zurecht kommt?

Ahoi,

ja das ist sehr mißverständlich, da Release Candidate != stable/release version ist. Ein RC ist ein Kandidat für ein fertiges Release wenn kein Bug mehr gefunden wird und momentan gibt es keine aktiven Betas oder RCs, deshalb die Verwrirrung.

Dann zur aktuellen Version einfach mal hier stöbern: https://doc.pfsense.org/index.php/Captive_Portal_Troubleshooting

Grüße

@kuemmel: ja kannst du und im jetzigen Stand solltest du das auch, da pfSense mit nur wenigen internen WLAN Karten funktioniert und noch diese noch dazu nicht die neuen Standards abdecken (n, ac) oder zumindest eher schlechtere Performance bringen. (Stand v2.1, soll mit 2.2 wesentlich besser werden).

Meine Empfehlung wäre auch die pfSense nachgeschaltet zum Gateway des Providers einzubauen und LAN und ggf. WLAN auf ein eigenes Interface zu hängen. Dafür würde dann auch bspw. eine APU Box reichen.

Grüße

uuups, gerade erst gesehen! Ja, tatsächlich, da ist ja eine Option für eine frei definierte Unterbrechung der Verbindung auf der pfSense GUI Seite für das WAN Interface, wenn man PPPoE wählt. Hab ich jetzt gleich eingerichtet… ;)

Dass dir das klar ist, stelle ich gar nicht in Frage :) Das war auch mehr als Hintergrund zu verstehen für andere, die diesen Thread vielleicht lesen und sich fragen, warum zum Geier die (immer) so lange für ein neues Release brauchen.

Allerdings haben schon einige Entwickler verlauten lassen, dass man sich für 2.2 wirklich darauf konzentriert, auf die neue Basis (FreeBSD10) und die wenigen Ersetzungen der Standard Applikationen wie StrongSwan, CARP, neue WLAN Treiber etc. konzentriert und keine großen neuen Features zusätzlich einführen wird. Schnellere iterativere Entwicklung ist angesagt, deshalb wird jetzt auch schon fleißig getestet und die erste Runde Problemchen wird gerade ausgedünnt (u.a. Pakete gerade kaputt, da Umstellung auf PHP 5.5 via FPM statt als CGI oder Modul).

Ich hoffe auch, dass gerade die etwas schwächeren Plattformen mit wenig RAM von der neuen Version profitieren, da PHP-FPM einen kleineren Memory-Footprint hat als die bisherige Methode, PHP 5.5 nochmal etwas schneller ist und so die WebUI auf Geräten mit wenig(er) RAM dadurch dann fluffiger laufen mag. :) Trifft vllt. nicht mehr auf die APU aber auf die älteren ALIXe zu.

Grüße

Ich muss das hier nochmal pushen.

leider weiß ich nicht wie ich die Treiber, bzw. welche Datein ich noch auf die CF Card nachladen muss damit es funktioniert.

Vielen Dank.

Ja, das dürfte das gleich Problem sein! Beim Neuverbinden wird die alte IP gecacht und nicht neu abgefragt. Da ja ein manueller Neustart funktioniert, wäre es doch eine Möglichkeit, die IPsec Verbindung automatisch zu einer bestimmten Uhrzeit neu zu starten!? Ich stelle die Internetverbindung täglich um 05:10 neu her. Wie kann ich um z. B. 05:12 einen IPsec Neustart erzwingen?

LG
esquire1968

So, Ergebnisse. Zusammenfassung:

Ich habe auch die Port-Weiterleitung von Port 5060 abgestellt. Das funktioniert auch hier problemlos.

Trotz Port-Weiterleitung war das Setup sicher. Allerdings kann der offene Port in Verbindung mit bestimmter VoIP-Hardware und Fehlern beim Setup ein Risiko beinhalten, s.u.

Zur Port-Weiterleitung für 5060 hast Du selbst schon alles nötige gesagt, insb. warum es auch ohne funktioniert. Die RTP-Ports müssen m.E. weitergeleitet werden, weil ein Verbindungsaufbau auf diese Ports vom Telefoniegerät des von Dir Angerufenen oder des Anrufers ausgeht, nicht vom SIP-Server des Providers. Hier besteht nicht bereits eine Verbindung.

Zum Sicherheitsrisiko: Wenn man ein Gerät betreibt, an dem ein IP-Telefon registriert werden kann, und dabei ein schwaches Kennwort verwendet wird, und dieses Gerät aus dem Internet erreichbar ist, dann können Angreifer ein eigenes Telefon registrieren und kostenpflichtige Telefonate führen. Das ist ein erhebliches Kostenrisiko.

Genau das meint Stefan Heck in dem von Dir erwähnten Forum:

Man sollte NIEMALS einen SIP Server in das Internet stellen. Genau das machst Du aber anscheinend. Gelingt es einem Angreife an deinem SIP-Server eine Gerät zu registrieren, dann wird er sofort anfangen kostenpflichtige Übersee Mehrwertdienste anzurufen.

und

einen Kunden von mir hat dies 9500€ gekostet, weil er sich unbedingt mit dem iphone aus dem Internet am internen SIP Gateway anmelden wollte. Da das Passwort zu kurz war, hat sich jemand aus China brute force registriert und dann fleißig Nummer gewählt.

(Quelle: https://feedback.telekom-hilft.de/questions/liste-sip-server)

In meinem Fall habe ich ältere Fritz!Box Fon 5050. Diese erlaubt keine Registrierung von IP-Telefonen. Das Angriffsszenario ist damit komplett ausgeschlossen.

Neuere FritzBoxen erlauben die Registrierung von IP-Telefonen. Nutzt man das, dann muß unbedingt ein sehr gutes Kennwort eingestellt werden. Die FB erlaubt es die Anmeldung eines Telefons aus dem Internet komplett zu verbieten, aber dieses Feature dürfte nur bei Einsatz einer FB als Zugangsrouter funktionieren.

Ob ein normales IP-Telefon (z.B. Dein Yealink-Telefon) für ein solches Angriffsszenario verwundbar ist, bezweifle ich. Das wäre dann der Fall, wenn man an dem betreffenden IP-Telefon weitere Telefone registrieren kann.

Die ganze Diskussion ist aber zum Glück nicht nötig, da man den Port ja zu lassen kann. Trotzdem alles gut zu wissen …