@roline said in pfSense 2.7.2 Einrichtung:

pfSense => per LAN-Kabel => am Switch verbunden

Hat der Switch auch eine IP adresse? Eventuell dort einmal das Kabel abziehen
und wieder anstecken so dass der Switch den IP Wandel auch mitbekommt.

@micneu said in Probleme mit RDP über VPN-Zugang zur pfSense:

Hey, ich lebe in der Apple Welt und habe mit OpenVPN & DNS keine Probleme auf Apple Systemen (Setze es Beruflich wie auch Privat ein)

Dann freue dich ;)
Apple macht aber viel eigenen Scheiß und verbricht damit auch viel Unfug. Es ist ja schön und gut, dass APPLE diktieren will - weil es angeblich Privacy ist - wer mit welcher Domain welchen DNS Server fragt, das ist aber eben in einem Firmenkontext teils übler Quatsch, gerade wenn man mehrere Domains hat. Zumal wenn sich plötzlich Konfigurationsparameter in ihrer Funktion ändern, die bei ALLEN gleich funktionieren BIS AUF Apple.

Das ist dann einfach nur nerviger Mist. Und wenn auf jeder Kiste eben drin steht:

wenn du DNS Server gepusht bekommst, dann löse ich jetzt über den gepushten DNS Namen auf...

und Apple daraus macht

wenn du überhaupt einen DNS Server gepusht bekommst, dann löse ich nur die gepushte Domain und nur die über diesen DNS auf und alles andere schicke ich an deinen Router daheim...

dann wirst du halt einfach sauer weil nichts gescheit funktioniert mit diesem iMist 😅

@NOCling said in VPN Passthrough IKEv2 auf der pfSense:

Achtung mit Routen in der Kocobox.
Wenn du ein /x einträgst und das mit dem IP Netz in dem die Box selber per LAN IP liegt, ist die tot.

Das (ganze TI) Zeugs ist der letzte Rotz.

Also bastle mal am Wochenende oder außerhalb der Öffnungszeiten ein wenig rum.

Wenn der parallel mit einem Link laufen soll, geht aber dann unterschiedliche Netzbereiche für die pfSense Netze und das Netz der Kocobox verwenden.

Genau das. Ich würde da stark versuchen, die Kiste in ein extra Segment der Sense zu packen. Also WAN/DMZ/LAN bspw. und die Box in die DMZ packen. Verbindung aufbauen lassen und gut. Kiste sitzt dann bspw. in 192.168.102.0/24 während das LAN in .101.0/24 aufgebaut ist. Dann sollte auch nix Routing-technisches nötig sein, da die Kocobox eh die Sense als Gateway hat und da alles hinschickt.

Aber asym. Routing über die Drecksbox sollte man tunlichst vermeiden, damit man sich nicht irgendwelche miesen Seiteneffekte eintritt. Also Box und LAN im gleichen (wie MIC es gezeichnet hat) vermeiden. Dann sollte weder Einwahl noch Betrieb große Probleme sein (Regeln muss man natürlich trotzdem machen und verstehen ;))

Cheers

@vantage09
das dürfte genau dieses Problem sein:
https://forum.netgate.com/post/1140882

In dem Thread gibt es auch eine Lösung:
https://forum.netgate.com/post/1140955

Wie Mic sagt, da gehen ja nur State Infos rüber also ein Bruchteil der Nutzdaten.
Da reich 1G locker aus, das reicht sicherlich sogar noch wenn du 20-25G Durchsatz machst.

Neue States pro Sekunde sind da eher das Problem, aber da muss die Kiste auch wieder richtig Power haben wenn die pro Sekunde paar hundert States aufbauen kann.

@NSuttner
Normalerweise sollte auf der Gegenseite keine Anpassung nötig sein. Da gibt es ja eine P2 zu deinem LAN, und in diesem bekommt deine Maschine ein IP.
Aber offenbar funktioniert das nicht bei allen Geräten, sowie manche Leute berichten.
Bei einer pfSense als Gegenstelle funktioniert es beispielsweise klaglos.

@Artefakt
Wenn der einzige Zweck der VPN ist, dass du über diese von der Ferne auf die dortigen Geräte verbinden kannst, da aber nichts von dort über die VPN zurück muss, setze einfach eine Outbound NAT Regel am LAN (Masquerading) auf die Interface-Adresse.

@JeGr Vielen lieben Dank :)

@heiko3001 Eventuell das andere WiFi mit anderen Optionen wie das Standard WiFi konfiguriert? Bei Omada mal nachgehakt/gefragt ob das da bekannt ist? Von VLAN Tagging abgesehen - was ich nicht glaube, da das VLAN nur zwischen Client und AP besteht und m.V.n. dann einfach getaggt vom AP zur Sense geht - könnte das auch schlicht ein Problem mit multiplen SSIDs oder Settings sein.

Mit einem Unifi AP der auch mit multi VLANs tagged spricht und an ner Sense hängt, kenne ich das Phänomen nicht, außer in meinem IoT Subnetz, dessen SSID nur 2.4 und nur 20er Band spricht und daher absichtlich klein gehalten und langsam ist (da streamt nichts). Im Medien bzw. Client Netz im 5GHz Band fluppt dann aber alles mit >150Mbps Durchsatz am AP, egal welche SSID.

@viragomann
Danke schon mal für die schnelle Antwort :D

Anscheinend kann ich nicht lesen, da ich nach Netgear Foren gesucht haben und das als 2 Vorschlag kam hab ich nicht weiter auf die Domain geachtet. Sorry dafür :/

Aber danke für deine Erklärung die hat mir schon mal sehr weitergeholfen. Ich werde mal überprüfen ob vielleicht am Switch 2 was falsch konfiguriert ist.

Ich werde natürlich keine weiteren Updates mehr bringen, da falsches Forum.

Ich wünsche trotzdem noch einen schönen Abend und danke noch mal :D

@saxandl Ok, und warum nutzt du schon KEA. In den Realese Notes haben sie doch geschrieben das noch nicht alles Umgesetzt ist was der ISC kann?
https://docs.netgate.com/pfsense/en/latest/releases/23-09.html#rn-23-09-kea

@cybero2912 said in Wireguard Peer Config Export:

super Antwort, selbst auf Consumer Geräten lässt sich die wg_config exportieren

Das hier ist aber eine professionelle Firewall und eben kein Consumergerät. Zumindest aus der Sicht der zahlenden Kundschaft.

@richie1985 said in aliasmod:

Grössere Subnetze "würden" gehen, aber irgendwo nie so sauber. Beispiel 192.168.0.0/16 würde ja dann den Traffic der Fritzbox (192.168.178.0/24) auch in den Tunnel jagen. Genau das will ich ja nicht :)

Antworten

Nö, warum würde es das? Größere Subnetze stechen NIE die kleineren Definitionen. Sondern spezifischere Netze (/24) stechen unspezifischere (/16). Wenn du also /16 ins VPN jagst aber ein Netz davon mit /24 lokal an der Firewall anliegt, wird das nicht einfach weggeroutet. Lokale Host/Netzwerkrouten stechen IMMER irgendwelche manuellen Routingeinträge.

Davon abgesehen würde ich trotzdem hart abraten, mit nem Alias in OpenVPN rumzustochern. Darf man fragen warum du das überhaupt machst? Das sollte ja für nen Tunnel eine relativ statische Sache sein. Dazu kommt, dass du die Einstellungen ja nicht nur im OpenVPN Server selbst brauchst, sondern ggf. auch noch im Client Specific Override (je nachdem ob du Server oder Clientseite bist) und da bin ich mir sehr unsicher, dass die in einem CSO berücksichtigt werden.

Wenn du unbedingt dynamische Routen machen willst - warum dann nicht mit OSPF gleich ordentlich Routen draufpacken und announcen? Ein bisschen overkill - sicher - aber einfacher als manuell mit Aliasen zu basteln.

@richie1985 said in aliasmod:

Grössere Subnetze "würden" gehen, aber irgendwo nie so sauber.

Definiere sauber :)

@viragomann said in aliasmod:

Da steht aber das Kommando, das add, an der falschen Stelle.

Nichts desto trotz war dein ursprüngliches Kommando falsch und das add/mod war an falscher Stelle. Also wenn dus mit dem Alias weiter probieren willst - Command fixen? :)

@richie1985 said in aliasmod:

Funktioniert super, nur füge ich da ein Netzwerk hinzu startet instend der openvpn server neu, was alles gerade verbunden openvpn user raus schmeisst und die sich erneut verbinden müssen :( daher würde ich das gerne "nachts" machen.

Antworten

Na das wird auch via Konsole passieren, denn wie soll sonst die OpenVPN Instanz lernen, dass die Netze sich geändert haben? Alias hin oder her, das Alias wird ja nur beim Starten der OVPN Instanz tatsächlich eingelesen, das ist OVPN spezifisch, da kann Alias oder pfSense nix für :)
Wenn du das Routing wirklich dynamisch brauchst/willst, dann geht das IMHO nur per OSPF. Ansonsten sollte man ggf. die Netze und Netzstruktur überdenken (soweit möglich) und die sinnvoll aufbauen, dass sie nach Möglichkeit alle in einem größeren Netz liegen, das man fürs Routing einfach greifen kann (bspw. mit nem /19 oder /20 etc.)

Cheers
\jens

@papajuliett Moin :)

Snort ist gruselig, würde ich gerade zu Beginn erstmal HART davon abraten den anzufassen. Erstmal Grundsetup wieder herstellen und ordentlich ans Fliegen bekommen, dann mit pfB-NG nachlegen und warm werden mit dem Ganzen.

Wo klemmt es denn jetzt genau noch, wo stehst du bzw. wo kann man helfen?

Cheers

@Owly Wenn es zur gleichen Zeit von intern geht, kann man da leider relativ wenig sagen. Wenn es von extern nicht mehr geht wäre es am Einfachsten, wenn man dann von intern mal den Packet Capture anwirft und sich anschaut, ob von extern wirklich überhaupt was ankommt. Also bspw. nen Handy mit OVPN Client via LTE versucht connecten zu lassen. Oft stellt sich dann nämlich raus - nanu! da kommt gar nichts an. Dann wäre das Problem beim Provider/Modem davor zu suchen, nicht bei der Firewall, darum sollte man erstmal eingrenzen wo es herkommt. Wenn nach langem Warten via HTTPS der 504 kommt wie oben - nunja der kommt wie gesagt von einem Timeout von PHP - dann sind wohl alle Worker ausgelastet und können keine Antwort geben. Das sollte aber bspw. dann den OVPN nicht tangieren, der hat da kaum Abhängigkeiten zu und wenn der sich trotzdem nicht connecten will, dann scheints andere Probleme zu geben. Wenn das Problem Richtung PHP liegt, könnte die Kiste auch einfach überlastet/ausgelastet sein, das kann dann auch an Fehlkonfiguration oder einem schieflaufenden Paket liegen. Kann man leider alles nicht so einfach hellseherisch debuggen :)

Cheers
\jens

@Timo-1 said in PFSense mit echtem statischen IPv6 Subnet:

von meinem Provider habe ich ein nicht geroutetes statisches IPv6 /48 Netz erhalten wie z.B. (2a05:bec0:1234::/48 Gateway 2a05:bec0:1234::1)

Hi,

was ist denn ein "nicht geroutetes, statisches IPv6/48 Netz" in deiner Definition? Ein /48er sollte eigentlich immer geroutet werden, da es 0,0% Sinn macht, jemand auf einem Interface ein /48er Netz draufzuwerfen. Das sollte wenn überhaupt ein Netz wie

2a05:bec0:1234::/48 geroutet auf 2a05:bec0:1234::2 /64 mit GW ::1 /64 sein

Alles andere ist ja bekloppt. Du willst ja nicht Trillionen Adressen auf einer Firewall oder einem Router verschwenden, sondern die weiter routen. Und wenn dein GW nicht weiß, dass das /48er HINTER deiner gehosteten Firewall liegt, dann macht das ja keinen Sinn.

Da würde ich also zuerst ansetzen und den Kollegen da sagen, sie mögen doch den Router auf der ::1 in ein /64 packen und dort in die Routing Table dein /48 dann bitte mit Ziel ::2/64 routen.

Alles andere kannst du sonst erstmal knicken, weil die Pakete sonst nie an dich geroutet werden.

Cheers
\jens

@viragomann said in Störung IPSec Aufbau nach Interntdowntime:

Eine Erklärung für das Nicht-Upgraden ist hier praktisch obligatorisch. Anderenfalls drohen schlaue Weisungen oder gar ein regelrechter Shit-Storm.

Antworten

naja der Sturm nicht ;) aber da 2.7 und 2.7.2 schon etliche Updates gerade bei IPsec gemacht haben, würde es sich natürlich SEHR anbieten, erstmal auf den aktuellen Stand zu kommen.

@hnoack85 said in Störung IPSec Aufbau nach Interntdowntime:

etzt gab es am zweiten Standort einen kurzen Internetausfall, jedoch konnte die IPSec Verbindung nach Wiederherstellung der Internetverbindung nicht mehr automatisch aufgebaut werden. Erst nachdem ich den IPSec Dienst am zweiten Standort manuell neu gestartet habe, wurde die Verbindung wieder hergestellt.
Aus dem IPSec Log habe ich dazu folgenendes heraus gelesen:

Das hört sich sehr danach an, als könnte zwar Seite A mit B aber B nicht mit A die Verbindung aufbauen, was u.a. an NAT wie @viragomann geschrieben hat liegen kann. Ich würde da empfehlen auf beiden Seiten mal in der P1 den Verbindungsaufbau zu disablen (reply only) damit keine der beiden Seiten die Verbindung aufbaut. Dann manuell disconnecten. Dann auf Seite A versuchen aufzubauen und das ganze Spiel nach nochmals mit Seite B. Dann bekommt man schnell raus, ob es in beide Richtungen sauber läuft oder nicht, was ich hier denke nicht der Fall ist.

Ansonsten ist der NO_PROP Error vielfältig, das liest sich im ersten Moment dann wie ein P1 oder P2 Encyption Fehler - also nicht exakt gleich eingestellte Phasen. Zusätzlich: wenn beide Seiten Sensen sind, dann nutzt da bitte auch AES-GCM-256 und nicht CBC wie es im proposal steht. Ich würde da beide Seiten fix auf AES-256-GCM, AES-XCBC (oder SHA-256) und DH20 stellen (ecp256 oder ecp384). Alles andere ist eigentlich unnötig überzogen. Ich weiß nie warum irgendwelche Hersteller da statt GCM sauber zu unterstützten immer noch mit "ja aber wir machen SHA512 und DH 21 mit ECP521!" - ja toll, aber das wichtige wäre GCM weils die CPU/Crypto entlastet und schneller ist und nicht irgendwelche Hashes oder Secrets die dann ultra doll verschlüsselt sind 😁

Cheers
\jens

@viragomann said in PPPOE Fehler oder Provider Störung:

@heiko3001
Hallo,

das Log zeigt einen Authentifizierungsfehler.
Wenn Username und Passwort in Ordnung sind, muss das Problem beim Provider liegen.

War eine Provider-Störung, trotzdem Danke!

@viragomann Vielen Dank für den Tipp ich habe festgestellt, das ich blöderweise eine Annahme gemacht habe. Die Interfaces sind vom Namen und Beschriftung verkehrtherum.
Demnach hast du recht da war kein Kabel dran ich habe es über den Log gesehen das:
LAN1 = igb5
LAN2 = igb4
LAN3 = igb3
LAN4 = igb2
LAN5 = igb1
LAN6 = igb0
Da ist der Fehler

Problem ist behoben.
Mit den DrayTek Modems funktioniert DNS-Auflösung nun einwandfrei.