Freut mich :)

@mike69 said in Anfängerfragen zur Konfiguration der Firewall: Regeln: Block RFC 1918, Block Bogon, wäre es hier nicht schlauer die Regeln zu Löschen? Denn wenn ich es richtig Verstanden habe ist alles was nicht erlaubt ist eh Verboten oder? Prüft die Firewall dann nicht zusätzlich? Wie reagiert der WAN Port wenn eine anfrage kommt? Wird Blockiert oder Abgewiesen? Gab es hierfür nicht eine Einstellung in der pfSense oder irre ich mich? Die beiden Regeln verhindern, dass Anfragen vom Heimnetz nach draussen gehen. wenn die Sense sich einwählt, die Haken lassen. Anfage von wo? Von draussen ist alles zu, bist du was öffnest, zB Portfreigaben. Von drinnen lässt WAN alles durch, dafür setzt du auch Rules für LAN, OPT1 etc... Wenn keine Rules vorhanden sind, geht nichts raus. Das stimmt leider nicht ganz, was Mike schreibt. Zuerst mal: Die Bogon und RFC1918 Block Regeln sind sinnvoll hier. Sonst gäbe es die Optionen nicht ;) Es geht darum, dass - wenn diese Haken auf dem Interface gesetzt sind - die Block Regeln über allen anderen Regeln auf dem WAN eingefügt werden. Sprich: somit gelten die vor irgendwelchen Freigaben, die man ggf. auf dem WAN einrichtet um bspw. VPN oder ähnliches erreichbar zu machen. Ja, wenn man nichts freigibt sind sie quasi überflüssig aber durchaus sinnvoll, da diese Regeln im Log extra gefiltert und kenntlich gemacht sind. Man sieht somit, dass etwas gegen diese Regeln verstoßen hat und kann sich ansehen warum und weshalb. Gibt man dann aber mal tatsächlich etwas frei - bspw. VPN für ein RoadWarrior VPN - wird trotzdem der Zugriff darauf von Bogon und RFC1918 Netzen verboten, denn aus denen sollte auf dem WAN keinerlei Traffic ankommen! Daher sind diese durchaus sinnvoll. Die pfSense allgemein reagiert IMMER an jedem Interface - solange nicht anders definiert - mit einem block any. Kein reject, somit also blockieren, nicht abweisen und rückmelden. Eine generelle Einstellung dafür gibt es nicht, man kann selbst bei Regeln natürlich auswählen, was man nutzen möchte. Vom LAN aus wird gern mal reject statt block genutzt. erlauben Schnittstelle: LAN, IPv4, alle Protokolle, Quelle (LAN-Net?) Ziel LAN-NET oder LAN-Adress oder Netzwerk mit 192.168.1.1/24 (was wählt man hier, das Intern alles erlaubt ist?) Um das was Mike schreibt vielleicht etwas verständlicher zu machen: ein Router (und pfSense ist fürs LAN erstmal primär genau das), bekommt Pakete nur wenn sie nicht im lokalen Netz zugestellt werden. Somit muss gar nichts getan werden um vom einer LAN IP an eine andere zu senden, das bekommt die Sense nämlich nicht mit. Intern wird immer direkt zugestellt. erlauben Schnittstelle: LAN, IPv4, TCP, Quelle(LAN-NET?), Ziel: WAN-NET oder WAN Adress Zielports: Alias mit (80, 443, 465, 993, 995 Nochmals für alle die darüber stolpern sollten: Die Auswahl XY_Net bzw. XY_Address beziehen sich nur auf die IP Adresse oder das Subnetz, was am entsprechenden Netzwerkinterface anliegt. WAN_NET ist NICHT das Internet, sondern nur das Subnetz, welches auf dem WAN Port konfiguriert ist bzw. aufliegt. Das Internet wäre rein technisch gesehen any ohne den RFC1918 und Bogon Bereich -> also alle Public IPs. erlauben Schnittstelle: LAN, IPv4, TCP, Quelle(LAN-NET?), Ziel: WAN-NET oder WAN Adress Zielports: Alias mit (80, 443, 465, 993, 995 Wie gesagt WAN-Net ist nicht das Internet, s.o. Ansonsten wenn dir diese wenigen Zielports genügen, ist das durchaus legit. Ich vermute aber du wirst mehr öffnen müssen ;) brauche ich noch eine Regeln für Port 53 und 123 ? Je nachdem wer das bedient, natürlich. Soll es die Sense tun, dann bräuchte es einen Filter wie "pass udp from LAN_Net to LAN_Address port 52,123" der das auf dem LAN IF erlaubt. Generell werden Regeln da erstellt, wo das Paket zuerst auf der Sense auftrifft. Und nur dort. als letztes dann Abweisen Schnittstelle: LAN, IPv4/ IPv6, alle Protokolle, Quelle LAN-Adress, Ziel WAN und diese Regel dann protokollieren Für ein striktes Ruleset mit nur definierten/wenigen offenen Ports und wenn du es extra Loggen möchtest richtig, ja. Ansonsten würde die default block rule greifen. Ist es möglich eine Email zu bekommen wenn das WAN-Gateway eine Zeit lang nicht funktioniert hat ? Jein. "Eine Zeit lang" - nein. Wenn es down ist bzw. wieder up geht, ja. Gibt es weitere Empfehlungen? Das hängt ganz davon ab, was du eigentlich genau erreichen möchtest!? Davon habe ich nichts gelesen. Auch nicht ob du überhaupt keine Segmentierung o.ä. anstrebst da du einen VLAN fähigen Switch angibst. Oder welche Art Traffic/Verkehr du hast/erwartest.

Ich danke dir, Test und Prod Durchlauf waren beim ersten versuch erfolgreich ! Das ich weniger Informationen angeben muss und nicht mehr, das hatte ich jetzt echt nicht erwartet. Vielen lieben dank nochmal, nun kann ich ein paar Subdomain Zertifikate löschen <3 leonor

Bandbreite ist immer ein Faktor. Ein anderer sind etwaige Zusatzdienste und Co. Da muss man sich selbst rantasten, was da in Frage käme. Bei ~300-400 Mbps wäre bei meinem normalen Setup eine APU recht hart am Limit, da würde ich eher auf was Stärkeres schielen, aber das ist auch eine Preisfrage. Bei Durchsatz und VPN Performance wird das natürlich gleich nochmal härter. Andere (teurere) Alternativen für mehr Bandbreiten wäre nach Ablöse der Lanner 1010/1020er inzwischen die 6907 von Aewin (scope7-6907) die dann nen Dual-Core N3350 mitbringt und gleich noch (für Lab/Homeoffice toll) nen HDMI mit an Bord hat um direkt am Gerät zu debuggen ohne serielle Console (kann man wenn man möchte). Schickes Ding und fast genauso klein wie die scope7-1010/1020, dafür aber auch nun mit 4 Ports. Von da an gehts dann eigentlich nur noch sinnvoll größer mit Kisten wie den kleinen und mittleren Atom C3000ern. So ein C3558 ist schon was Schuckeliges (scope7-1510 oder Netgate SG-5100 -> gleiches Gerät im Prinzip). Aber die Kisten sind natürlich auch teu(r)er - dafür mit sehr starker Perfomance für ihre Größe und den Preis. Da sind dann auch mal 300-500 Mbps verschlüsselte Übertragung drin ohne Murren :) Grüße

@yakuraku said in OpenVPN: ssh ok, scp geht nicht: Versuche ich aber per SCP grössere Dateien zu Senden oder etwas via PIPE in den SSH tunnel zu spielen bekomme ich einen Abbruch "Broken Pipe" Von wo aus sind die Clients verbunden die nicht funktionieren? Wo ist der Unterschied zwischen denen, bei denen via VPN dann ein SCP funktioniert und denen die nicht gehen? Mac+Debian von oben in "fehlerhaft" -> von gleicher Location zu deinem VPN Server verbunden? Der funktionierende MAC von woanders verbunden? Die Fehlerbeschreibung (leider ohne irgendwelchen Logs :( ) legt eher den Schluß nahe, dass die von einem DS Lite Anschluß kommen bzw. eben ein Carrier mit Carrier Grade NAT und ähnlichem chichi am Start. Hat(te) mein Kollege auch das Problem bei unserem VPN in der Firma. Alle anderen -> geht problemlos, er bei SSH "yay", bei größeren Dateien "nay" und connection loss. Manuelles fixen seines Clients auf kleinere MTU (1280 und ggf. kleiner, muss man sich rantasten was geht) mit mssfix und Co. haben die Problemlösung gebracht. Abhilfe war dann das VPN Dual-Stack aufzubauen, damit sich sein Client nativ per v6 verbinden kann - dann gabs auch kein MSS/MTU Gefrickel mehr und SSH/SCP liefen problemlos.

Bei deinem Tunnel network ja. -Rico

Die pfSense muss nicht zwingend das Gateway im LAN sein, eine statische Route dahin tut es auch, wenn auch unschön. Die Route könnte via DHCP auf die Clients verteilt werden, vorausgesetzt, alle Clients verwenden DHCP. Ich weiß ja immer noch nicht was du damit meinst: @pipen1976 said in DNS Frage: Beide Netze sind geroutet. Funktioniert das bereits? Zusätzlich zum DNS Domain Override musst du auch noch den Zugriff auf den DC aus dem VLAN erlauben und dem DC auch so konfigurieren, dass er die Anfragen (die aus seiner Sicht von extern kommen) beantwortet. Die LAN Hosts müssten dann aus dem VLAN mit <hostnamen>.<domain> aufgerufen werden. Alternativ kannst du im Forwarder auch Host Overrides für jeden einzelnen Host setzen, der aus dem VLAN erreicht werden soll.

@Wonko2k Danke für die Antwort, die ein bis zwei reboots im Monat sind verschmerzbar, da ich die Sicherheitsupdates auch immer selbst durchführe. Hatte mir jetzt doch noch eine i350-T4 bestellt, dann bin ich zukünftig flexibel was getrennte Netze angeht, kann den zweiten LAN Port vom DrayTek anschliessen um die Daten auszulesen etc. Gab es auch keine Probleme mit MagentaTV?

Der Händler hat mir die SG-1100 unkompliziert und schnell ausgetauscht, jetzt geht auch der WAN Port online :)

Beim Forwarder lässt sich auch nicht anders als beim Resolver ein Lookup-Interface festlegen. Wobei diese Einstellung würde global gelten und du möchtest wohl nicht die DNS-Anfragen sämtlicher Clients über die VPN zu schicken. Die Einstellung hier ist für Multi-WAN Setup gedacht, damit gegeben ist, dass ein DNS Server über die zweiter WAN-Verbindung erreichbar ist, wenn eine WAN-Verbindung ausfällt.

@mike69 said in pfsense mit QUAD-Intel NIC, kein DNS auf einer dieser NICs moeglich: @Lindemann ist seit 2011 dabei, so ganz neu ist das nicht. Deutlich länger als ich! Das Neu habe ich von der Anzahl der Postings hergeleitet. Ich glaube, dass auch diese Anzahl der Schlüssel zur Aufhebung der Sperre ist, aber möglicherweise sind es auch Likes. Ich möchte es nicht suchen, mich hatte es bislang noch nicht berührt. Grüße

Hallo, die Regel einzuschränken war natürlich eine gute Idee. Ich habe jetzt einfach verboten, dass das VPN Netz auf das LAN Interface zugfreifen darf, somit habe ich nun fast alles was ich wollte.

@mike69 Okay - danke für die Info. Dann werde ich mir wohl auch einen anderen Provider/Domain suchen. VG

Hi! Habe ich auch schon versucht; keine Chance.

Moin, du sprichst doch vom Client nicht direkt das WAN Interface an, um ins Internet zu kommen, sondern die IP des LAN Interfaces (Gateway) an die der Client angebunden ist. Die Sense routet anschließend den Verkehr vom LAN zum WAN. Mit deiner Regel block LAN to WAN versuchst du den Zwischenschritt über die Sense zu umgehen, was folglich nicht möglich ist.