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 …

Ist das bei Dir wie bei Beerman? Nur mit abgeschalteten IGMP-snooping läuft das Bild durch Da mußte ja das IGMP-Snooping des Switch irgendeinen Einfluß auf die Unterbrechungen haben: Da der Multicast-Traffic nicht im Switch, sondern schon in der pfSense unterbrochen war (siehe weiter oben im thread), war meine Vermutung, daß Teile des IGMP-Traffic (Antworten des Media Receiver auf membership queries o.ä.) vom Switch verschusselt werden. Daher war der Vorschlag zuletzt den IGMP-Traffic aufzuzeichnen. Damit hätte man das erhärten können. Wenn das IGMP-Snooping problematisch ist, dann kann man darauf verzichten, wenn man hilfsweise den Multicast-Traffic für das IPTV in ein eigenes VLAN legt. Bleibt auch bei Dir bei einer Unterbrechung des Empfangs der IPTV-Traffic schon in der pfSense aus? Das sieht man ganz einfach im Traffic Graph auf dem Dashboard.

Hehe, ich sehe mein Problem auch nicht (klar) ;) Also: LAN: 192.168.2.0/24 DMZ: 192.168.3.0/24 RW: 192.168.9.0/2 (ipsec mobile, hier sind in den PH2 Definitionen die Subnets des VPNs eingetragen, das funktioniert soweit … ich sehe entsprechende Zugriffe in den pass Rules) Site 2 Site VPN: Mapped auf local 192.168.8.1 ipsec, ich kann hier an den Gegenstellen nicht viel ändern da vorgegeben Über das VPN (es werden später mehrere Site2Site VPNs werden) werden mehrere Subnetze gerouted über mehrfache PH2 Definitionen wie z.B: Mode: tunnel Local Subnet: LAN Local Subnet NAT/BINAT: 192.168.8.1 Remote Subnet x.x.x.x/24 In der Config ist das VPN übers LAN erreichbar, nicht jedoch über DMZ und Roadwarrior (entsprechende Rules sind dort drinnen) Wenn ich beim Local Subnet statt LAN DMZ nehme dann ist das VPN über die DMZ erreichbar, ich kann aber nicht über DMZ Rules z.B. nur einzelnen DMZ Hosts Zugang ins VPN gewähren, geht alles anden Rules vorbei durch. Dann ist das VPN nicht mehr über LAN oder Roadwarrior erreichbar... Deswegen meine Grundidee beim VPN ähnlich wie bei ipsec Mobile als Local Subnet ein eigenes Subnet ala 192.168.7.0 zu definieren ... wie und obs was bringt hab ich noch nicht rausgefunden P.S. Derzeit sind die Site2Site VPNs über einen OpenVPN Tunnel und 2 weitere Router an unserem alten Lancom VPN Router angebunden, die Roadwarrior können drauf zugreifen, das LAN und auch die DMZ. Ich versuche jetzt einfach den Lancom und den OpenVPN Tunnel wegzurationalisieren (anderer Standort) und die Site2Sites direkt an die pfsense anzubinden

So hab nun dich einige posts zu dem Thema gefunden….. Das Problem lässt sich soweit eingrenzen INFO: ISAKMP-SA expired Somit wird die entsprechende SA gedropped und die Verbindung aufgelöst. Die Frage ist nur ... warum? Die Parameter sind auf beiden Seiten identisch (ttls der keys usw). Auch die Tipps mit "Nat-N disable, DPD off oder Policy Generation auf unique) bringen keine Änderung..... Und ....  nach einem restart von racoon sind alle vpns per default offline