Subcategories

  • 106 Topics
    1k Posts
    micneuM

    Ich habe keine ahnung was 1&1 liefert, mein Provider hat einen Meidenkonverter Installiert (von GLAS --> Ethernet) somit kann ich direkt mit dem Ethernet Kabel in meine Sense gehen.

  • 81 Topics
    440 Posts
    M

    @Bob-Dig

    ja und nein, das Handling und Layout gefällt mir bei pfsense einfach besser. Aber das waren nicht meine Fragen.

  • This topic is deleted!

    1
    0 Votes
    1 Posts
    16 Views
    No one has replied
  • This topic is deleted!

    1
    0 Votes
    1 Posts
    22 Views
    No one has replied
  • NAT Reflection

    6
    0 Votes
    6 Posts
    207 Views
    V

    @tpf
    Eine FW-Regel für den Zugriff auf die private IP hast du?
    Die braucht es schon, denn das NAT geschieht vor der FW.

  • [gelöst] Konfiguration VoIP mit C430A GO an 1&1 DS-Lite

    7
    0 Votes
    7 Posts
    273 Views
    E

    Vielen Dank an @JeGr für die Hinweise !!!

    Die Telefonie funktioniert nur und das Hauptproblem hatte nichts mit der pfsense und deren Konfiguration zu tun.

    Entscheidend war mein Nachtrag von gestern Abend, nämlich dass die Diagnostics -> States für die 192.168.0.4 ausschließlich Verbindungen zu 5060 anzeigten, aber keine zu den STUN- oder RTP-Portts.

    Voreingestellt im C430A GO sind die RTP-Portts 5004 - 5020.

    Bei 1&1-Verstate gibt es auch eine Konfigurationsanleitung für das C430A GO, in dem diese Prots so eingetragen sind wie von mir bis jetzt verwendet. Das 1&1-Hilfecenter schweigt sich zur RTP-Konfiguration gleich komplett aus.

    Dennoch hat mich das RTP-Problem nicht losgelassen. Den entscheidenden Hinweis fand ich im Tutorial: 1und1 VoIP mit Fritz!Box HINTER opnSense aus dem OPNsense Forum
    Dort findet sich prominent der Hinweis auf die von 1und1 genutzten RTP-Ports 5070 - 5079. Damit nun funktioniert die Telefonie einwandfrei.

    Was bleibt ist ein extrem schaler Beigeschmack hinsichtlich des Supports von 1&1 und deren Tochtergesellschaften wie Drillisch. Man will die Privatkunden offenbar mit aller Macht zur Nutzung von FritzBoxen zwingen. Informationen zur korrekten Konfiguration sowohl von DSL- wie Glasfaser-Internet und der Konfiguration der 1&1 Telefonie-Verbindungen gibt es ausschließlich für Fritten. Auch telefonisch erhält man lediglich die Auskunft: "wir supporten NUR FritzBoxen". Für 4,99 Miete/Monat senden die einem aber gerne eine 7510 (Kaufpreis ab rund € 100) zu ...

  • FritzBox<->pfSense IPsec VPN

    4
    0 Votes
    4 Posts
    179 Views
    JeGrJ

    @jogovogo said in FritzBox<->pfSense IPsec VPN:

    Guten Abend zusammen!

    Vielleicht wird dieses Thema ja noch beobachtet...

    Wir hatten stabile VPN Tunnel am laufen haben die FRITZ!Box auf die Version 8.03 updated nun bauen sich diese leider nicht mehr auf.

    An der Config hat sich selbsterklärend nichts geändert.
    Es kommt folgende Meldung, IKE-Error 0x2026 "no proposal chosen.

    Hört sich irgendwie nach Phase 2 an, ob sich da seitens Fritz OS irgendwas geändert hat? Ggf. hat ja einer ähnliche Erfahrung und kennt die aktuellen Chiffrewerte.

    Cheers
    Ron

    Hi,

    leider hast du dich an einen ganz anderen Thread drangehangen, darum ging die Frage auch komplett unter. Bitte tatsächliche Probleme/Support hier in den Forenteil packen und nicht ins Allgemeine Netzerkthemen Laber-Unterforum :)

    Es kommt folgende Meldung, IKE-Error 0x2026 "no proposal chosen.

    Am Einfachsten ist es da die pfSense auf der remote Seite im Log zu untersuchen, da wirst du auch das NO_PROP finden. Davor findet sich dann auch meistens ein IKE Austausch mit "Die Crypto bot mir die Fritte an", "die hab ich selbst" - "kein match".

    Damit kann man eigentlich immer gut sehen, was tatsächlich übermittelt wurde egal was man bei AVM eingestellt hat und was man selbst konfiguriert hat. No Proposal heißt in dem Zusammenhang mit fast 100% Sicherheit, dass das Setting mit AES-SHA256-DHmode nicht mehr stimmt und die Fritte mit dem Update die Einstellungen resettet hat und ggf. einen anderen Hash, DH Modus oder ne andere Crypto gewählt hat. Was und welche genau siehst du aber nur auf der Sense im Log.

    Am Besten bei sowas die Sense in Phase 1 auf "responder only" schalten, so dass die nur auf eingehende Requests antwortet und dann im Log die Strings vergleichen was ankommt und was die Sense anbietet - wird sicherlich nicht übereinstimmen weil AVM mal wieder Settings geändert hat :)

    Cheers :)

  • Default ipsec_get_keystate: no keystate

    2
    0 Votes
    2 Posts
    116 Views
    JeGrJ

    @fms said in Default ipsec_get_keystate: no keystate:

    @bon-go said in IPSec-Tunnel - received NO_PROPOSAL_CHOSEN error notify:

    IKE log: 173835.242284 Default ipsec_get_keystate: no keystate in ISAKMP SA im Lancom trace

    Hallo,

    Kann mir jemand sagen, was no keystate bedeutet? Was bewirkt diesen Fehler? Ich finde dazu leider nichts im Web.

    Danke und viele Grüße, fms

    Hi,

    das hat nichts mit pfSense zu tun und war in diesem alten Thread aus einem Capture(?) von einer Lancom Gegenstelle, darum wird dir hier kaum jemand dazu antworten können. Wenn du allerdings das Problem mit einer Sense als Gegenstelle hast, kannst du gern das IPsec Log der Sense dazu hier posten, dann können wir dem gern auf den Grund gehen, was der Fehler sagt.

    Ich würde annehmen, dass es entweder schon beim Key Exchange scheitert (Phase 1, Passphrase oder Crypto Cipher) oder dass die Verbindung abgebrochen wurde und daher keine IKE Phase mehr besteht.

    Cheers

  • Innerhalb IPSec kein Ping in das Local Network möglich

    9
    0 Votes
    9 Posts
    258 Views
    JeGrJ

    @Hugh86 Ich habe da noch nicht verstanden, warum überhaupt NAT gebraucht wird. Wenn deine P2 Policies auf beiden Sense Seiten korrekt eingestellt sind, müssten beide Seiten sich gegenseitig problemlos pingen lassen. Von Geräten - nicht von den Sensen aus, denn IPsec mit Policies hat ja kein Interface was pingen könnte. Also geht es nur von einem Netz aus, das auch in der Phase 2 im Routing definiert ist. Ich verstehe aber wie gesagt nicht ganz, warum du hier NAT brauchst, das klingt eher, als wäre am VPN was falsch konfiguriert, denn im Lab bei uns kann ich da zwischen 2 Sensen kein Problem sehen :)

    Vielleicht kannst du ja nochmal etwas genauer die Screenshots posten und von wo nach wo du testest und was nicht geht, dann klappts vllt. auch ohne NAT und mit sauberem Routing :)

    Cheers

  • LAN mit zwei Gateways

    9
    0 Votes
    9 Posts
    305 Views
    JeGrJ

    @nanu said in LAN mit zwei Gateways:

    Wenn ich aus dem Internet mit OpenVPN über Pfsense1 (192.168.1.1) einwähle komme ich eine http Verbindung zu webserver1 (192.168.1.100) und auch auf das Webinterface von Pfsense2 (192.168.1.2) kann ich aufrufen.

    Ich bekomme aber keine http Verbindung zu webserver2 (192.168.1.200). Per ping ist der Server erreichbar.

    Umgekehrt ist es vergleichbar. Also Einwahl über Pfsense2 erreichbar per http sind webserver2 und Pfsense1 aber nicht webserver1.

    Was fehlt hier?

    Das ist asymmetrisches Routing² und wird dir gern und immer dann wenn du nicht damit rechnest tolle Probleme bescheren. Das Setup ist ziemlich "kaputt". Zwei Gateways mit jeweils eigenem Internet und VPN die dahinter ins gleiche Netz verbunden sind, ist kein Setup was man empfehlen würde. Wenn man das so hart trennen mag, dann sollte man das LAN von pfSense1/2 trennen und dort wirklich nur deren Webserver anhängen. Die Sensen aber untereinander und mit den Webservern ins gleiche Netz zu packen schreit nach Problemen.

    Wenn man ein sinnvolles MultiWAN Konzept bauen möchte, dann sollten beide WANs auf der gleichen Sense - oder besser auf einem Cluster aus 2 Geräten - aufliegen. Dann kann auch gern eine ausfallen, es kann ein WAN ausfallen, etc. etc. - alles wäre sinnvoll redundant. Aber so ist das eine Art "poor-mans-choice-of-redundancy" was einem dann wegen der Routen über Kreuz und der gleichen IP Ranges gern jederzeit um die Ohren fliegen kann. Gerade dann wenn auf den beiden pfSensen1/2 auch vielleicht noch das gleiche VPN Einwahlnetz verwendet wird :) Denn dann ist für die Geräte das Chaos komplett ;)

    Und es ist super, dass es jetzt erstmal geht, aber wie gesagt die Asymmetrie des Netzes ist dadurch nicht behoben und das kann zu jeder Menge Fehlersituationen führen, die man eigentlich vermeiden möchte. Im Support bekommen wir solche Sachen leider ständig und nur weil es jetzt vielleicht (noch) funktioniert, würde ich trotzdem dazu raten, das Setup grundlegend zu überdenken :)

    Cheers! :)

  • 0 Votes
    8 Posts
    309 Views
    micneuM

    @swk said in Loadbalancing Failover legt alle WAN Verbindungen (& VPN) für 5-15 Sekunden lahm:

    Netgate_Firmware_Upgrade 23.05.00

    du solltest mal Updates einspielen, aktuell ist 24.11

  • IP Adressen blocken

    4
    0 Votes
    4 Posts
    192 Views
    S

    @unique24
    falls doch pfBlockerNG mit DNS zum Einsatz kommt unbedingt die RAM Disk aktivieren:
    https://forum.netgate.com/topic/189820/how-do-i-find-out-what-write-continuously-on-my-pfsense-ssd

  • DHCP über IPSec

    3
    0 Votes
    3 Posts
    170 Views
    I

    @micneu
    Ganz einfach.
    Wir lösen unsere OnPrem-Landschaft auf und verlagern alles in ein Cloud-RZ.
    Damit habe ich an keinem Standort noch Hardware, auf welcher ich einen Domaincontroller laufen lassen könnte.
    Da unsere Intrusion-Detection-Lösung am DHCP-Server unter Windows andockt, muss es leider ein zentraler Server für alle Standorte sein und ich kann die DHCP-Server-Funktion der PF nicht verwenden.
    Die DCHP-Discover-Pakete der Clients kommen an der PF an, dort ist DCHP-Relay aktiviert, die Pakete werden aber nicht in den Tunnel weitergeleitet, sondern einfach nicht beantwortet.
    Würde statt Relay die PF die IP-Helper-Funktion unterstützen, dem Client die Serveradresse mitteilen und der Client von Broadcast auf Unicast switchen, würde das Paket in den Tunnel gehen.

  • Zwei Netze (bzw zwei IP-Blöcke) am WAN

    4
    0 Votes
    4 Posts
    167 Views
    V

    @CharlyTango said in Zwei Netze (bzw zwei IP-Blöcke) am WAN:

    und ich erkenne gerade, dass di beiden Netze das gleiche Gateway nutzen.
    Was hat das für Auswirkungen in der pfSense?

    Keine.

    Brauche ich da dann eigentlich nur virtuelle IPs und gut ists?

    Damit wird es auf jeden Fall funktionieren. Virtuelle IPs sind für alle Zwecke geeignet, ob geroutet oder nicht.

    Nachdem mir aber nicht klar ist, ob das zusätzliche Subnetz geroutet ist und welche IPs davon tatsächlich nutzbar sind, würde ich das zuvor gerne herausfinden.
    Dazu brauchst du nur die Netzwerkadresse oder Broadcast von außen pingen, während du am WAN ein Paket Capture laufen lässt, das auf die Ziel-IP filtert.
    Wenn diese ankommt, ohne dass die IP auf der pfSense angelegt ist, kannst du den gesamten Bereich nutzen, auch ohne virtuelle IPs.

  • Errors In auf LAN Interface Intel X520

    1
    0 Votes
    1 Posts
    121 Views
    No one has replied
  • Statische IP-Adresse via DHCP: Ursache für IP-Konflikt ermitteln

    4
    0 Votes
    4 Posts
    229 Views
    altmetallerA

    @micneu Nein. Was mir noch aufgefallen ist ist der Umstand, dass das DNS die betroffene IP revers auf den alten Hostnamen aufgelöst hat.

    Nach dem Neustart des DNS war zumindest dieser Spuk verschwunden.

  • Protokolleinträge von Firewall Regel "im Auge behalten"

    6
    0 Votes
    6 Posts
    371 Views
    JeGrJ

    @altmetaller Dann sollte es mit einer Match Regel aber klappen, denn das wird im filter.log in /var/log dann entsprechend gekennzeichnet. Dort werden die Logs ja auch länger aufbewahrt als in der UI anzeigbar, da solltest du notfalls mit Logfile Größe und Anzahl erhöhen schon was finden können :)

    Cheers

  • Namensauflösung auf MacOS mit DNS - Resolver funktioniert nicht

    17
    0 Votes
    17 Posts
    1k Views
    T

    Vielen Dank Leute,
    als Nicht-Mac-User bin ich hier fast durchgedreht als einer unserer Mitarbeiter mit seinem Mac antanzte und er die lokale Domain beim besten Willen nicht auflösen wollte! Ihr seid Großartig!

  • Pfsense+ kostenlose Version für den Heimgebrauch

    10
    0 Votes
    10 Posts
    459 Views
    micneuM

    @Beerman dann kaufe dir doch eine Hardware direkt bei netgate, wie es einige von uns gemacht haben. Ich glaube das wurde hier auch schon erwähnt. Ich habe den Kauf meiner 6100er nicht bereut.

  • Fritz!App Fon (Handy VLAN A) zu FritzBox (VLAN B)

    19
    0 Votes
    19 Posts
    1k Views
    JeGrJ

    @Tobi said in Fritz!App Fon (Handy VLAN A) zu FritzBox (VLAN B):

    Das ist zwar für mich ganz dünner Boden, weil ich nun mal kein "Netzwerker" bin. Woher soll die Sense denn wissen, was sie mit einem neuen/ ankommenden Paket machen soll?
    Es wird doch von innen nach außen alles geroutet aber von Außen nach Innen?

    Außen & Innen sind keine Dinge, die ein Gerät kennt. Es hat lediglich Routen. Jedes lokal anliegende Netz hat implizit eine Netzroute mit fast höchster Prio. Die Sense weiß also in welchen Netzen sie steht und wo sie Pakete zwischen den Netzen hin und her verteilen soll. Alles was sie NICHT weiß, schickt sie an die Default Route - dafür ist sie da :)

    In der klassischen Situation:

    FB <--> pfSense <==> Netz(e) intern

    wie man sie oft antrifft, steht ja die Fritte als Provider Kiste vor der Sense, ergo ist der Weg dahin für die Sense immer einfach -> es geht ja eh alles raus, was nicht intern bekannt ist. Problem hat hier die Fritte, denn die hat nur die Sense als Nachbarn, sieht aber die internen Netze nicht und hat da keinen Schimmer von und da ihre Default Route raus ins Internet geht, kommt da dann ohne NAT ausgehend aus der pfSense kein Paket von innen mehr dorthin zurück - außer man setzt statische Routen in der Fritte.

    Umgekehrt: Wenn die FB aber in einem internen Netz parkt, wie alle anderen auch und die Sense direkt Internet hat/macht oder es eine andere Kiste davor gibt, dann ist die Default Route der Fritte ja die Sense selbst. Alle Netze an der Sense sind dann problemlos erreichbar, weil die Pakete von/zur Fritte dann ja immer über die Sense laufen und dort die Netze alle bekannt sind. Die Fritte kennt sie zwar nicht, aber da diese auf dem Rückweg eh alles an die Sense schickt - kein Problem, denn die kann dann regeln und kennt wieder den Absender. Ergo ist hier intern hinter der Sense zwischen den Netze kein NAT nötig, die finden sich alle.

    Cheers

  • Captive Portal mit externem DNS-Server

    2
    0 Votes
    2 Posts
    518 Views
    S

    @wschmidt

    ich weiß das Thema ist alt aber der Vollständigkeit halber:

    Wenn man den Gästen z.B. den Google DNS (8.8.8.8) per DHCP zuweist muss dieser im Captive Portal unter Allowed IP Addresses eingetragen werden.

  • Captive Portal mit externem DNS Server und https Anmeldung

    1
    0 Votes
    1 Posts
    84 Views
    No one has replied
Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.