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

Nein, DoD ist für Einwählverbindungen, die an einem Zeit- oder Volumenanschluß genutzt werden. Heute bspw. UMTS Links. Hier wird die Verbindung nur aufgebaut, wenn tatsächlich Traffic nach extern geroutet werden soll. Ist das Interface down, wird auch kein Traffic durch bspw. DNS Anfragen oder Pings an das Gateway verschwendet (sofern es andere DNSe gibt die antworten bspw.).

Somit kann man hier einen über Zeit oder Volumen abgerechneten Zugang einschränken, damit dessen Verbindung nicht versehentlich mitgenutzt wird oder unnötiger Traffic anfällt.

(Deshalb nicht bei Bedarf herstellen, sondern nur bei Bedarf - hier liegt der Witz im Detail ;) )

TTL ist notwendig für den Eintrag den du via pfSense DDNS Client setzen lässt. Wenn du also bspw. up0.dyn.domain.tld setzen lässt, wird beim TTL von 300 bspw. die IP für 5min gecached. Kleiner als 5min wird bei den meisten DynDNS Anbietern selten angeboten und reicht m.E. nach auch aus. Man kann aber bspw. auch 180 für 3min machen. Die Frage ist da eher, was dein Provider zulässt als Minimum, da seine Server für diese Adresse dann ziemlich oft gefragt werden (kleines TTL heißt auch dass ggf. nach der Zeit die Anfragen direkt wieder an den Primary DNS durchschlagen)

Öhm… bietet dir dein Provider wirklich(!) Dynamic DNS nach RFC2136 an oder willst du dir das selbst irgendwie hinfrickeln? Hier brauchst du nämlich DNSSec Daten, die auf dem DNS Server des Hosters entsprechend vorliegen müssen (du musst die dynamische DNS Zone - bspw. dyn.domain.tld - mit User/Key absichern und mit diesen Daten meldet sich dann der DNS Client beim DNS Server des Providers an). Wenn du keine Ahnung hast, was du dort eintragen musst, bezweifle ich, dass der Hoster das anbietet, denn sonst hätte der die Informationen mitgeben müssen. (Meistens ist es Key Type "Host" für einen direkten Eintrag wie oben - up0.dyn.domain.tld - und als Key Name wird ein sprechender Name vergeben und dann ein HMAC MD5 Key für das Key Feld)

UDP (prot). Use Public IP ist nur für dich relevant, da es beeinflussen kann, was die pfSense dann als IP in den DynDNS Record reinschreibt. Da hatte ich zu ein Ticket aufgemacht, da - anders als bei den DynDNS Diensten - bei RFC2136 immer die WAN IP benutzt wurde. Wenn man aber vorne dran noch einen Provider Router und damit ein privates Transfernetz hatte, wurde in den A Record immer die private 192er (oder sonstige) IP der pfSense eingetragen anstatt der IP, die sie extern beim Provider hat. Das Feld wurde eingebaut um das Verhalten wie DynDNS und Co zu simulieren. Dazu wird ein externer Check gemacht, wie die IP nach außen ist und das statt der WAN Adresse eingetragen.

Grüße

Das ist - sofern die DSL Lines jetzt schon sauber funktionieren - eigentlich kein direktes "Routing" Problem. Was du konfiguriert hast, geht aber nicht. 2 Interfaces dürfen nicht eine IP aus dem selben Subnetz haben! (Dürfen schon, aber nur in speziellen Fällen in spezfischen Konstellationen und das hat nichts mit deinem Problem zu tun).

Wenn bei dir Outdoor und LAN wirklich ins gleiche Netz sollen (warum?), bleibt eigentlich nur eine Bridge über LAN und Outdoor.
Der Traffic für den Outdoor Bereich (entsprechende Einteilung im DHCP vorausgesetzt), kann man dann per PolicyBasedRouting in einer extra Firewall Regel setzen.
(Eine Pass Regel mit Source <von-bis bereich="" des="" dhcp="" für="" outdoor="">zu Destination any und in advanced Settings dann nicht Default Route, sondern direkt das Gateway für DSL2)

Grüße</von-bis>

@Dodger: Über 2.1 bis 2.1.3 hin alle.

@virago / Dodger: Ist bei uns ähnlich, allerdings haben wir da 2 SSDs als RAID1 was transparent an der pfSense als 1 Laufwerk ankommt (problemlos). Einzig einige Netzwerkeinstellungen mussten wir tunen, da durch die vielen (hyperthreaded) Kerne der CPU es ein Problem mit den MBufs gab. Das ist aber auch unter doc.pfsense.org zu finden.

Einen SingleCore Kernel gibt es inzwischen allerdings nicht mehr, also keine Angst. Das war noch 2.0 und früher. Mit 2.1 gibt es nur noch einen Kernel, der automatisch multicore nutzt. Unser Problem mit den MBUFs wurde auch durch die Kerne verursacht, weswegen ich die Installation mit BootOptionen durchgeführt habe, um an den CPUs nichts drehen zu müssen. Hintergrund war, dass die Puffer pro Kern und Queue verteilt werden und es bei vielen Kernen dann zu viel für die Default Settings wurde. (https://doc.pfsense.org/index.php/Tuning_and_Troubleshooting_Network_Cards)

Grüße