kenne ich den provider nicht solltest du von deinem provider informationen bekommen haben wie du deinen router/firewall einrichten sollst wenn du schreibst das ist ein modem meinst du damit dann einen medien konverter von glas auf ethernet? ich habe bei meinem provider keine modem (sonder wie schon geschrieben einen medienkonverter) und habe einfach meine sense drangehängt und muss die einwahl über pppoe machen. habe mir dein angehängtes dokment ein wenig angeschaut, steht doch alles drin was du machen musst (einfach die entsprechenden bereiche der doku abarbeiten wie z.b. pppoe). alles ganz simpel. den reste findest du unzählige male behandelt im forum (wie IPv6, dualstack, telefonie was alles noch auf dich zu kommt) einfach den wizard der sense durch arbeiten dann sollte danach deine sense laufen.

@marcfunk said in IPSEC, nur eine Seite erreicht die Netze:

Die FritzBoxen sind eigenständige Router mit eigenem Netz und leiten Ports weiter. Das habe ich jetzt zu Exposed Host geändert - an beiden Seiten.

Vorsicht vor den Fritzboxen und Port Forwardings bzw. Exposed Host. Gerade wenn die Fritze mal wieder semi intelligent versucht für ihr Netz"Home" die Geräte automagisch zu erkennen kommt da oft Murks bei raus.

Da die Fritten auch selbst IPsec können, kann es sein, dass Port Forwards nicht reichen, das gab es in der Vergangenheit bei älteren Firmwares schon, dass dann IPsec einfach nicht weitergeleitet wurde.

Was für ordentlichen exposed Host oft hilft:

Fritz Port Forwarding und exposed host etc. löschen In der Netzübersicht/Homeview das Device, das die pfSense ist löschen Dann fix zum Forwarding/Freigabe Screen wechseln solang sie noch kein neues Gerät angelegt hat Exposed Host anlegen nicht auf ein "vorhandenes benanntes Gerät" sondern auf "IP Adresse" und manuell die IP eingeben, die die pfSense hat (hoffentlich eine STATISCHE!) speichern

Klingt doof, aber wir hatten jetzt schon mehrfach Fälle auch mit neueren FBs hinter denen eine Sense hing, dass exposed Host eben nicht sauber geklappt hat und Ports verschluckt wurden etc. oder kein Ping lief
Erst löschen dieses komischen MAC/ARP/IP Gerätewirrwarrs auf der Fritz und Anlegen des Exposed Hosts mittels IP (was sie blockt wenn es schon ein bekanntes Gerät gibt mit der IP, darum vorher löschen!) hat den Knoten gelöst und innerhalb von 1-2s ging plötzlich ein Dauerping und Verbindungstest von extern, der vorher konsistent gescheitert ist.

Einfach als kleiner Tipp aus der Praxis

@slu Wenn du nicht offloadest eher nicht, da dann weder HTTP Header noch sonstige Dinge unverschlüsselt zur Verfügung stehen. Das Einzige IMHO ist der SNI Header der dann noch zu lesen ist um überhaupt die Zustellung zu machen. Für alles andere müsste er die Verbindung annehmen.

@nocling

Danke Dir echt, das war der gordische Knoten ;-) Ich honk hab den Gateway
nicht korrekt gesetzt. Der lag noch bei der UDMPro. Manchmal sieht man den
Wald vor lauter Bäumen nicht und braucht ein weiteres Paar Augen.

Vielen Dank nochmal und weiter frohe Ostern !

@nocling Danke für den Hinweis.
Ja so hab ich es an sich jetzt eh gemacht.

Ein Switch-Uplink (ich habe 2 ubiquiti EdgeMAX Switches) für das reguläre LAN und einen extra Port für die ganzen tagged VLANs.

Funktioniert soweit bis jetzt prächtig 😃

8608c51c-4712-4e5e-b0b8-ef964ea3a941-image.png

3d159b7e-17b6-436e-9f46-57f97283acb7-image.png

Die pfSense ist der Mittelpunkt des Netzwerks, ich bevorzuge für diese die .1, da sie das Gateway bereitstellte. Clients fangen bei mir bei der .11 an, bis .199, dann folgen Reservierungen für Geräte die ich im Regelwerk gerne mit einem Alias entsprechend hinterlegen können will.

Du kannst, leider nur auf dem einen managed Switch alles sauber mit VLANs voneinander trennen.
Willst du den dump Switch weiter verwenden, könntest du hier das Großraumbüro anschließen und dann mit einem Link weiter auf den Managed Switch in das entsprechende VLAN ( ist dann ein Access Port).
Wenn hier jedoch feste Mitarbeiter sitzen, dann würde ich das schon trennen wollen, sprich meine Angestellten sind dann im Work VLAN und die Sharing Plätze im Share VLAN, letzte brauchen ja nur Internet und keinen Zugriff auf das NAS.

Wichtig ist das du dir überlegst, wer in welches VLAN soll, dann hast du erstmal eine Aufteilung.

Dann kennst du die Anzahl der VLANs, dann geht es weiter.
Ich habe gern, dass das 3 Oktett zur VLAN ID Passt, also das Netz dann wie folgt aussieht.
VLAN 1 ist dann 10.0.1.x
VLAN 2 ist dann 10.0.2.x

Wenn du einen VPN Tunnel mit jemandem anderen dauerhaft aufbauen willst, dann ist jetzt der richtige Zeitpunkt gekommen mit ihm zu sprechen.
Denn noch kannst du deine IP Netze festlegen wie du willst, am besten so, dass jedes Netz nur auf einer Seite besteht, das erleichtert das Routing.
Haben deine Mitarbeiter oder du Selber eine FritzBox im Heimnetz, dann ist 192.168.178.0/23 für dich Tabu, ebenso wie 192.168.0.0/24, welches die ganzen Speedport Kisten haben.

Also ggf. ein 10er oder ein 172.16.x Netz aus der RFC1918 wählen.

Clients laufen bei mir auf DHCP, besondere mit Reservierung, Server, NAS Systeme zählen dazu, wie auch Switche sind dann mit statischer IP konfiguriert. Denn diese muss ich auch bei einem Ausfall erreichen können. Wobei das, wegen dem Management Netzwerk inkl. VLAN dann komplexer ist.
Hier kannst du dir z.B. einen Port auf dem Switch für den Notfall freihalten und dieser ist dann dem Management VLAN zugehörig.

@viragomann ich bin bisher davon ausgegangen, dass es zur Wahrung der Integrität der Antwort genügt, wenn der verantwortliche autoritative Nameserver DNSSEC unterstützt, aber jetzt, wo du nachfragst, bin ich mir nicht mehr sicher, ob das stimmt. 🤔

Naja die CAM Table von einem Switch ist da schon mal sehr Echtzeit.
Da schaut aber nur ein NAC wirklich gern rein.

Stimmt, dachte aber (da der Patch aktiv ist), dass es eher nicht dieser Bug ist.

Edit: Teste es dann trotzdem nach Möglichkeit nochmal!

Hi Community,
ich habe eine Lösung gefunden. Also wie es scheint, haben proxys Probleme bei SRV Lookup. Somit konnte das Update nicht sauber funktionieren. Daher habe ich ein paar Veränderungen vorgenommen.
-) Zuerst habe ich die pkg.conf angepasst, so dass pkg immer den Proxy benützt.

* italicised text*/usr/local/etc/pkg.conf to -> PKG_ENV { HTTP_PROXY = 172.21.100.8:3128; HTTPS_PROXY = 172.21.100.8:3128; SSL_CA_CERT_PATH = /usr/local/share/certs; }

Weiters habe ich die URL statt dem SRV record, den DNS record benützt.
/usr/local/etc/pkg/repos/pfSense.conf

pfSense-core: { url: "pkg+https://files00.netgate.com/pfSense_v2_6_0_amd64-core", mirror_type: "srv", signature_type: "fingerprints", fingerprints: "/usr/local/share/pfSense/keys/pkg", enabled: yes }

Das Updaten funktioniert nur auf der CLI sowie Packages zu installieren.
Warum es in der GUI nicht funktioniert, habe ich leider nicht herausgefunden. Tippe mal, dass die GUI irgendwelche andere Config Files benützt.

LG

@dollarsign IGMP General Membership Queries werden von außen an die Adresse 224.0.0.1 geschickt. Deswegen sollte die auf jeden Fall offen sein. Die gruppenspezifischen Membership Queries werden an die Gruppenadresse geschickt. Da IGMP nicht weiter problematisch ist, habe ich da das Netz nicht enger gezogen. Du kannst aber mal probieren, eine Regel für 224.0.0.1/32 und eine für 232.0.0.0/16 anzulegen. Das sollte auch klappen. Halte ich aber wie gesagt bei IGMP für unkritisch.

@jegr Joar, ich hatte inzwischen Hilfe von einem Experten zum Thema.
Danke @nonick !

@anonymnuss
Dann scheint mir die pfSense an der Misere gar keine Beteiligung zu haben.
Da würde ich das Problem erst mal zwischen Switch und Proxy suchen.

Die pfSense kennt damit ja nicht mal die MAC-Adresse des Proxys, was das erste wäre, das ich untersuchen würde.
Dass die pfSense weiß, wo sie die Paket hin zu schicken hat, zeigt ja das Traceroute.

Ich habe deine beschriebenen Einstellungen vorgenommen. Funktioniert nun. Vielen Dank für deine Hilfe, @NOCling

@megbyte0469 said in Pfsense 2.6.0 letzte Version, Installation Mini PC mit einen Ethernet Port:

Ist das ein Bug oder fehlt noch was in der Konfiguration ?!

Hast du mittlerweile eine Lösung gefunden?

@greeneyedandy Ahso, das sollte ja kein großes Problem sein?
Ich habe hier halt den Vorteil, dass ich das selbe Gerät, welches ich jetzt hinter der Firewall nutze, davor vor der Firewall genutzt habe und so die meisten Einstellungen halt eh noch richtig gesetzt sind, was Telefonie betrifft.

Habe jetzt deinen Setup nicht mehr im Kopf, aber vielleicht kann es ja auch auf dich zutreffen.

@herry2 said in Externe IP bzw. Port über einen VPN auf eine Interne IP Umleiten:

Hi,

Ok sollte man wohl angeben, es ist ein OpenVPN und wird nur für diese Verbindung benötigt.

Peer to Peer (Shared Key)
tun - Layer 3 Tunnel Mode

Mfg

Heribert

Nochmal da die Frage ignoriert wurde: Ist das ein VPN Tunnel der dafür gedacht / erlaubt ist, dass die IP weitergeleitet wird und bei welchem die IP überhaupt auch geforwarded wird? Und wie wird sie das? Oder kontrollierst du beide Enden und auf der Seite mit der öffentlichen IP steht auch ne Sense? Was ist da konfiguriert?

Nur weil du über den Tunnel raus kommst, heißt das ja nicht das eingehend das gleiche einfach so schnippidiwipp funktioniert :) Darum bitte mal eine Aussage dazu, was das überhaupt für ein Tunnel ist (ja OVPN Shared Key ist jetzt klar) und ob es überhaupt sinnvoll möglich ist den eingehend zu benutzen. Sonst kommt da überhaupt kein Traffic für dich an und alles weitere was man ggf. auf der pfSense einstellen kann ist schlicht unnötig wenn nie Traffic ankommt.

Cheers
\jens

@bob-dig Ja, weil es mir effektiv nichts bringt mit "einer einzigen" IPv6 draußen unterwegs zu sein. Wenn ich alle dutzende Devices intern auf eine einzelne IPv6 ausgehend mappe, habe ich dadurch genau nichts gewonnen außer dass ich doppelte Buchführung machen darf und jede Regel zweimal abklopfen muss, ob sie mit IPv4/6 sauber funktioniert und auch alles korrekt ist.
Alle Vorteile von IPv6 für mich verschwinden und nur die Nachteile mit IPv4 bleiben. Hab ich nicht wirklich nutzen dann davon.