Hat funktioniert, musste aber pfsense komplett neu per serial drauf machen. Dann noch die Konfiguration. Ich hatte mal die pfBlockerNG-dev drauf und dann wieder zurück auf die Standard. Vielleicht lag es daran. 👍

Danke! Endlich kein Traffic mehr über LTE. Ich habe die Gateway Zuordnung bei den DNS Server entfernt und musste die Kiste neu starten. Ein Unbound Restart reichte nicht.
Nun hat der Spuk ein Ende. Wobei interessanterweise die Telekom scheinbar nicht die DNS Anfragen über LTE billed...

Ahhhh! Super, danke. Stimmt, manchmal ist man wirklich blind (blöd)!☺ ☺

Schönen Sonntag noch und Gruß

Sven

@raaalf said in pfBlocketNG/DNSBL: Es werden keine Pakete gefiltert:

Oder sehe ich hier etwas komplett falsch?

Nein. Gibt es ein Problem beim booten hilft SSH nicht. Bei Installationen sieht es schon
anders aus, wenn es um die Verwendung von USB-RS232 Adaptern usw. geht.

Beispiel:
Installation von FreeBSD auf einer ALIX-Kiste. Die ALIX-Kiste bootet nur von CF Card.

Kein Problem. Die Installation von FreeBSD erfolgt nicht auf der ALIX-Kiste selbst,
sondern auf einem anderen Rechner. Danach werden von fstab, loader.conf, ttys,
sshd_config, rc.conf modifiziert. CF Card in die ALIX-Kiste stecken, booten
und dann weiter mit SSH.
Ab APU1 bootet FreeBSD/pfSense ja von USB und man greift auf die serielle
Konsole bei der Installation zurück. Da gibt es eben mehrere Möglichkeiten.

LG

@bsa66 said in Portweiterleitung: pfSense als ExposedHost - WebServer im Subnetz hinter pfSense:

obwohl natürlich jeder Rechner mit Netzzugang wohl als begehrtes Ziel gilt, vor allem wenn da noch ein Server drauf läuft...

Wirklich jeder Rechner? Eine kühne Aussage.

LG

Moin moin,

leider hat es mit der Antwort etwas gedauert, kam leider nicht vorher dazu.

Aber gut, dann habe ich den Resolver ohne Forwarding richtig verstanden und eigentlich ist es auch genau das, was ich möchte. Ich möchte unverfälschte DNS-Antworten vom Root-DNS/SOA ohne Zentralisierung auf einen Dienst bzw. DNS-Anbieter.

Die derzeit eingetragenen DNS-Server greifen halt nur wenn ich Forwarding an mache, was ich nun erst einmal nicht tun möchte.

Bleibt für mich jedoch die Frage wieso ich www.avm.de (ignorieren wir mal ohne www) nicht aufgelöst bekomme. Hin und wieder treffe ich halt auch andere deutsche Domains - interessanterweise gefühlt immer nur DE-Domains.

Wenn ich nun per dig einen Google DNS anfrage, dann erhalte ich für www.avm.de die IP-Adresse 212.42.244.122 Schaue ich nun in die Statistik meines DNS Resolvers, dann finde ich dort diese beiden IP-Adressen: 212.42.244.66 und 212.42.244.67 für avm.de (vermutlich die NS von AVM) Die SOA von avm.de ist die ns1.avm.de und dies besitzt 212.42.244.66, ns2.avm.de hat die 67 (okay, Vermutung bestätigt) Wenn ich einen der NS für www.avm.de direkt "andigge", dann bekomme ich die gleiche Antwort wie von Google Rufe ich einmal www.avm.de über die pfsense Funktionalität "Diagnostics/DNS Lookup" auf, dann sehe ich den korrekten Record. Hier werden nun jedoch auch die externen DNS angefragt, ich kann daher nicht sehen woher die Antwort kommt Digge ich direkt von meinem PC, ohne Angabe eines DNS, mit "dig www.avm.de" dann erhalte ich eine leere Antwort

DNSSEC habe ich einmal deaktiviert. Dies hat keine Änderungen bewirkt.

Da ich von meinem PC und meiner Leitung direkt mit dem DNS von AVM sprechen kann vermute ich keine Blockade oder ähnliches. Dennoch würde ich gerne dieses Problem lösten, da Forwarding für mich eigentlich keine Option ist. Hier würde ich dann doch gerne meine Privatsphäre schützen.

Hallo @Overlord,

es gibt einen Abschnitt "Statistics". Dort steht wahrscheinlich etwas unter "Stats Password" drin. Leere bei Statistics alle Felder und deaktiviere die Funktion. Eventuell kurz aktivieren, damit die Felder sichtbar werden.

Viele Grüße

Ich bin mir inzwischen ziemlich sicher dass meine PFSENSE Installation "was weg hat"...

Habe heute noch ein 2. Board mit Quad NIC getestet - zieht sich sofort IP sowohl von Telekom an WAN1 als auch Vodafone an WAN2...

Werde das ganze wohl neu aufsetzen müssen

Jetzt funktioniert meine Konfiguration. Vielen Dank für deine sehr wertvolle Hilfe, viragomann!

Abschließende Anmerkung: Offenbar habe ich meinen Fehler – aufgrund dem der Paketmanager (zumindest unter deaktivierter WAN-IPv4-Konfiguration) nicht mehr lauffähig war – identifiziert.
In den DHCP-Einstellungen war bisher das Kontrollkästchen „Statisches ARP“ aktiviert. Sobald ich jedoch besagte Option deaktiviere funktioniert der Paketmanager anstandslos (mit eintragen des DNS-Servers in den allgemeinen Systemeinstellungen sowie setzen der FritzBox-IP als Standardgateways im Routing).
Zudem meine ich mich zu erinnern, dass dieser Menüpunkt – bei der „Normalkonfiguration“ (WAN bezieht seine IP via DHCP, LAN statisch, keine Brücke) der pfSense – zu keinen Funktionseinschränkungen des Paketmanagers geführt hat.

Hi,

nein, hier bei Cablecom in der Schweiz kommt am Cablemodem im Bridgemodus eine direkte Verbindung an, ich hole dann per DHCP die externe IP (keine 198er, 10er oder sonstwas). Wenn aus irgendeinem Grund die Verbindung zusammenbricht am Modem, steht am WAN-Interface nur noch n/a statt der externen IP. Dann deaktiviere ich das Interface, aktiviere es wieder und bekomme wieder eine IP.

Beste Grüsse,

SnakeZZ

Hallo und danke dir
Ich werde das nochmals testen.
Habe mich jedoch entschieden einfach nochmals 1 Quad Port Karte zu kaufen.
Und das IPTV einen einzelnen Nic zur verfügung zu stellen.

Gruss und melde mich nach dem Test.

@grimson
OK Dankeschön

Hi

Ok - aber das das darf dann im VPN Bereich nicht das gleiche Subnet sein oder ?

@viragomann said in WAN auch DSN Name möglich?:

meinst du hier, man muss sich aktiv auf dem Web-Admin Interface einloggen oder den DNS-Eintrag updaten?

Schlecht ausgedrückt von mir, da hast du recht. Du musst dich mit deinem Account mal einloggen, dann ist (bei ihm) alles wieder gut. Update der Adresse ist m.W. kein refresh.

@achim55 said in WAN auch DSN Name möglich?:

Die PfSense, die als VPN Server dient, läuft ja unter Proxmox als Gast. Der Wirt muss sich ja dann um den DNS kümmern.

Ohne das böse zu meinen, aber ich glaube du hast dein eigentliches Problem immer noch nicht wirklich verstanden ;)
Es ist völlig gleich, ob du in einem RZ eine physische Kiste, VM, Cloud-Dingsbums oder sonstwas als pfSense hast. Und ob diese wiederum ihre IP dynamisch, statisch oder sonstwie bekommt. Hauptsache deine VM/Maschine läuft bei dem Provider. Die IP die du vom Provider bekommst, das ist diejenige, die eine Rolle spielt. Du hast in deinem RZ irgendeine IP von deinem Provider, die du der pfSense unter Proxmox zugewiesen hast. Und die muss logischerweise zur Einwahl von Clients erreichbar sein. Ändert sie sich weil du deinen physikalischen Kram nimmst und in ein anderes RZ gehst oder woanders eine VM mietest - ist das dein Problemfall. Dann gibt dir der neue Provider eine neue IP. Dann passt man natürlich seinen Proxmox/whatever und die pfSense Installation an, damit wieder was geht - aber Mist: die Clients.

Genau deshalb richtet man die Clients mit ner DNS Adresse ein (vpn.blafasel.test) und ändert nach seinem RZ Umzug die IP der DNS Adresse auf die neue und fertig ist der Lack. Wie, wo und warum du was für eine Anbindung auf egal welcher Seite (Client/Server) hast oder ob das echte Hardware oder virtueller Kram ist - völlig wurscht. :)

Moin,

Gerne. Laufen bei euch mit den Einstellungen auch die Streams in VLC?

VG

Klingt für mich nach einem Routingproblem.
Überprüfe mal die Routen auf allen Standorten und führe ein Traceroute auf den LAN-Rechnern aus.

Welche Bandbreite hat denn die Außenstelle?
Klar erzeugt Verschlüsselung Overhead und Latency, aber das ist i.d.R. nicht nennenswert.
Im RDP Client kannst du unter 'Anzeige' bei den Clients mal die Farbtiefe heruntersetzen (je nach Anwendung sieht man eh keinen Unterschied) und unter 'Leistung' auch noch etwas nach unten gehen.

-Rico

Das doch super :) Ging auch nicht ums "einsehen", sondern eher wofür der da ist. Hätte zudem auch funktionieren können/sollen wenn er richtig konfiguriert ist. Aber vielleicht war da der Haken. Anyway schön dass es jetzt läuft!