Hallo,

ich nutze verschiedene Systeme an verschiedenen Stellen für unterschiedliche Aufgaben und auch
zu unterschiedlichen Zwecken, also nicht nur und ausschließlich pfSense.

OpenBSD + BGPD

Quagga

RouterOS

OpenWRT

DD-WRT

pfSense

ClearOS

ZeroShell

IPFire

Danke!

Ich hab jetzt eine 128 GB SSD eingebaut. Mal sehen …

LG
esquire1968

Traceroute aus pfsense heraus gibt mir bei strato.de sofort  *chen  zurück und wrote 40 =-1  . Bei anderen Inetseiten, die nicht im 192er Netz liegen funktioniert Traceroute tadellos.

Save am NAT Tab werde ich heute abend noch testen.

Ergänzung:

Save am NAT Tab hat leider auch nicht geholfen.
Noch wer eine Idee? :))

@Alixfl:

hast du auch die richtigen Anschlüsse verwendet. WAN und LAN. Standard ist WAN wohl der mittlere Anschluß von den 3 Netzwerkbuchsen?

Das hat mich erst auch irritiert, den bei Miller78 ist WAN vr0 und müsste damit der äußerste sein.
Sollte aber auch egal sein, die Netzwerk Ports kann man zuweisen wie man möchte. LAN bleibt dennoch LAN und damit ist dort auch die Standardregel für Zugriff nach überall gesetzt.

Und wäre WAN nicht mit der Fritzbox verbunden, würde die Schnittstelle von deren DHCP keine IP erhalten.

Hi,

du könntest LAN und WLAN brücken. Dann sind sie zwar auch im selben Subnetz, pfSense hat aber immer noch die volle Kontrolle über den Traffic.

Ich hab zwar keine Ahnung, welches Protokoll deine Fernbedien-App fährt, aber ich tippe mal auf Multicasts, weil dieses Verfahren auf dem Gebiet üblich ist.
In diesem Fall könntest du dir mit einem IGMP Proxy Abhilfe verschaffen. Services > IGMP proxy
Das sollte übrigens, anders als hier fälschlicherweise erwähnt, auch bei Bonjour helfen.
Eventuell mal im Forum nach dem Thema suchen.

Grüße

Besten Dank für eure Antworten :) Hat danach alles wieder funktioniert :)

Okay, dann hat sich ja schon alles geklärt!

danke für die die schnelle Hilfe und Aufklärung!!  ;) :D

schönen Tag euch noch  :)

Nice job :D

Ist für mich verständlich jedoch sprechen wir da bei mir nicht von Minuten sondern von Stunden und Tagen.

Ich hab nach dem Update auf 2.2.1 im certmanager für die usert Zertifikate erstellt und im usermanager die Berechtigung "User - System - Shell account access" zugelassen.
Jetzt bekomm ich keine Fehlerbenachrichtigung oben rechts. Jedoch startet der sshd immer noch nicht.

beste Grüße
G

@bitboy0
Die Routen werden nur gesetzt, wenn das irgendwo konfiguriert ist. Zumeist wird es am Server konfiguriert mit den "Local Network/s" bzw. mit "Redirect Gateway", dann bekommt der Client die Routen per push-Kommando gesetzt. Es kann aber auch unabhängig von der Server-Konfiguration direkt am Client konfiguriert werden.

@flix87
Der Sinn des setzen von Routen ist, dass nicht zwangsweise der gesamte Traffic über die VPN muss sondern nur bestimmte Netzbereiche. Wenn ich mich zu Wartungszwecken in ein Netz verbinde, benötige ich die VPN nur, um dieses Netz zu erreichen und möchte nicht Audiostreams oder sonstiges Übel über die VPN schicken.

@orcape:
Das hast du schon richtig erkannt, die IPs bekommen wir von der T-Com.

Ich kann das irgendwie leider nicht mehr bearbeiten, bietet mir nur "Quote" an. shrug

Hallo und Danke für die Rückmeldung.
Ich blocke die nun mal weg.

Ja, ich habe einen "Business Tarif" und deshalb funktioniert der Bridge-Modus mit der Firtzbox.
Bei mir war es übrigens so, dass ich durch die Umstellung auf Business nicht mehr bezahle. Ich musste früher 5 EUR für die ISDN Option bezahlen. Die fällt in diesem Tarif weg nun weg.

Zum Glück habe ich meinen Abteilungsleiter hinter mir, dem ich das mit " Jeder poppt mit Jedem und nachher über den Tripper heulen" übersetzt habe  :o

PRUUUST Bitte nicht so nen Satz wenn ich heißen Tee im Mund hab. Mist, jetzt brauch ich ne neue Tastatur ;D
Den Satz möchte ich bitte im Standard Repertoire jedes Netzwerkers haben. Den bekommt ab jetzt jeder Azubi und Kollege im Team ab :D
immer noch vom Stuhl fällt

Aber im Ernst: Solche Kommentare kommen eben genau von Leuten mit extrem gefährlichem Halbwissen. Denn dass dann eben auch jeder depperte (L)User mal eben hergehen kann und mit seiner Mühle einfach mal ganze Abteilungen lahmlegen (hey wir switchen mal alle IPs durch…) oder mal nen schönen Broadcaststurm anfachen... das geht natürlich niemand in Kopp. Spätestens wenn man sich dann mal fragt, wie Info X außerhalb von Team Y bei Firma Z aufgetaucht sein kann... aber dann ist eben schon Aua.

Gruß

Nur VPN ist bei Auswall des grade benutzen WAN erst mal weg … ist ja aber auch logisch. Dann muss man die IP des anderen WAN ansprechen.

Lässt sich aber auch einfach lösen, indem du einfach VPN Client Configs erzeugst, in denen beide Server IPs nacheinander drinstehen. Erreicht er dann die erste nicht, wählt er automatisch die zweite. Auch bei einer Zwangstrennung durch Verbindungsverlust. Kann man - wenn man Last verteilen möchte - auch RoundRobin eintragen, so dass mal die eine mal die andere gewählt wird, aber in deinem Fall ist nacheinander wahrscheinlich der gewünschte Zustand ;)

Ich nehme an, das einige die LAN->WAN allow(any) Regel entfernen und dann nur Portweise irgendwas ausgehendes erlauben…

Mache ich auf unserer großen DC Firewall auch. Natürlich. Aber das hat eben zur Folge, dass ich den Kunden erklären muss, warum von ihrem Server XY nicht einfach mal eben so geht. Sobald man das erklärt ist das auch selten ein Problem.
In Unternehmen ist das aber oft schwierig, denn wenn Chef A seine Lieblingsseite B nicht mehr aufmachen kann, gibts schnell mal Streß ;)

Was mache ich falsch? Mache ich einen Denkfehler??? Funktioniert IPv6 noch gar nicht eigenständig????

Doch, eigenständig schon. Mit allen Anbietern, die v6 Adressen für ihre Systeme nutzen. Da gibt es leider noch nicht so viele, wie mir lieb wäre. Deshalb raten da viele auch zu anfänglichem DualStack Betrieb (v4/v6) oder/und dazu, entsprechende Dienste extern via Proxies verfügbar zu machen (also quasi selbst ein v4->v6 Gateway zu bauen). Hierfür geht Squid sicher für die meisten Web-Dienste, sollte allerdings was anderes als HTTP/HTTPS benötigt werden, wirst du entsprechend andere Proxies oder Connectoren brauchen (SOCKS fällt da ins Auge). IPv6 only zu nutzen ist daher momentan nur mit etwas Aufwand möglich, da man abwägen muss, was die User benötigen um das bereitstellen zu können.

Wenn du v4 am Client komplett abschaltest, muss natürlich der Proxy auch via v6 erreichbar sein und funktionieren, ansonsten wirst du nur bspw. Google oder Facebook über deren v6 Adressen aufrufen können.

Gruß

Fehler gefunden!

Der DNS Eintrag im DHCP Server sollte der IP des PFSense Servers enstrpechen…  :-[

Gruß
Lothar

Neues Problem: snort

Also ich bin mir nicht sicher ob es an snort liegt aber das ist wohl naheliegend. Gestern lief noch rdp, ssh und ftp ohne Probleme. Danach habe ich Snort nach Anleitung instaliert Einstellungen gesichert und bin ins Bett.

Jetzt von der Arbeit versuchte ich mich per rdp auf den Server einzuloggen. Der Start lief problemlos, ich wurde aufgefordert die Daten einzugeben. Nach Eingabe der Daten wurde die Leitung gekappt und alle Ports zur PFsense geblockt. Es wurden ssh, ftp, rdp usw. gekappt. Auch der Versuch von anderen IPs zeigte das die Ports dicht sind.

Ist das ein Fehler meinerseits, habe ich bei Snort etwas nicht verstanden? Order muss ich noch ne whitelist für Ports etc. erstellen? Eigentlich habe ich auf dem Server schon eine Software die genau das gleiche bei ausgewählten Ports wie Snort macht. Ist dann snort dann noch notwendig oder kann ich drauf verzichten?

Update:
Nach Neustart von pfsense ging der FTP, leider habe ich den Fehler gemacht das ich wieder versucht habe mit rdp auf den Server zu kommen. Und wieder das gleiche Muster, nach Eingabe der Anmeldedaten, sind sofort wieder alle Ports dicht.