@Michael9876 Bei pfSense gibt es ja öfters verschiedene Wege zum Ziel, schwierig das nun zu bewerten.

Einige der Punkte, die Du ansprichst, kannst Du ja selbst testen, wie z.B. funktioniert dein VPN-Killswitch überhaupt, wie ist das Ergebnis, wenn Du einen DNS-Leaktest aus dem Web nutzt, etc.

Ich kann für mich sagen, dass ich noch kein Outbound NAT nur für einen einzelnen Port machen musste und dass ich meinen VPN-Killswitch via tagging umgesetzt habe. Für DNS nutze ich DNS Query Forwarding mit SSL/TLS im Resolver, also mein ISP sieht da eh nichts, oder ich vergebe den DNS-Server direkt über DHCP, was dazu führt, dass der betreffende Host die Verbindung zum DNS-Server automatisch über die VPN-Verbindung herstellt. Die DNS-Server meines VPN-Providers nutze ich wiederum nirgends, weil mir zu lahm und letztlich überflüssig.

@JeGr said in APU2C4 und IPv6:

Nach deiner Auflistung: Vielleicht liegts auch an deinem Windows 10 PC?

Danke noch mal für deine Hilfe JeGr. Das Problem lag tatsächlich an Windows 10 PC.
Habe jetzt ein Funktionsupdate drauf gespielt, seitdem läuft IPv6 ohne erkennbare Probleme.

@Bob-Dig

Vielen Dank für die Info:)

@viragomann

Netz habe ich soeben geändert auf /8. Ich werde das nacher nochmal tracern und so versuchen.

@JeGr

Ops, mein fehler habe ich wohl das falsche Bild hochgeladen, hab den überblick verloren von den ganzen Printscreens xD.

Ich würde ggf. versuchen statt untagged/tagged zu mixen einfach nur tagged zu sprechen auf einem physischen Interface - da bin ich pingelig und mag es lieber ordentlich. Aber geht natürlich beides.

@Wireguard said in Teilweise falsche Zeitangaben:

in Grunde waren alle Logs von der Zeit her falsch. Ich habe die pfSense mal neu gestartet, nun passen alle Zeiten wieder. Echt seltsam....

Wahrscheinlich umgestellt und danach nicht neu gestartet, dann werden Syslog Server etc. nicht neu durchgeladen und haben nicht die aktuelle Zeitzone drin.

Wichtig auch drauf zu achten, dass DHCP in GMT gezeigt wird (Lease Time), das kann man im DHCP Server selbst aber umschalten (Checkbox für local time reinmachen).

Am besten mit einer Block-Regel.

Ich nehme an, dass die betroffenen Geräte dennoch mit anderen internen Adressen kommunizieren können sollen. Dann dürfen diese Zugriffe nicht geblockt werden.
Bewährt hat sich hier, einen Alias zu erstellen, der sämtliche RFC1918 Netze enthält (andere verwendest du intern hoffentlich nicht).
Dann eine Block-Regel erstellen, mit Protocol = any, Source = <das gewünschte interne Subnetz>, Destination = "invert." angehaken und den RFC1918 Alias als Ziel eintragen.
Diese Regel blockt dann alles außer RFC1918 Adressen und passt auch noch, wenn du an denen internen Netzen etwas änderst.

Bedenke wie immer bei Firewall-Regel, dass Floating-Regeln oder welche auf Interface Gruppen Prio vor Regeln auf Interfaces haben.

@Fredd Gerne!

Muss ja was gegen diese doofen Gerüchte tun, dass es immer heißt, hier wären alle so ernst, belehrend und unfreundlich ;)

@simpsonetti said in Keine updates der Pakete möglich:

@JeGr
Ähh, hust hust,
wie mache ich denn updates von den Packages auf der console?

um das nochmal zu erklären: Es gibt im Konsolenmenü ein "Update from Console" Punkt (13) der die Pakete aktualisiert. Gibt es kein OS/Firmware Update, aktualisiert das alle anderen Pakete die Updates haben.

Will man es komplett aus der Konsole, geht es mit

pkg upgrade pfSense-pkg-X (wie das Paket heißt)

also bspw.

pkg upgrade pfsense-pkg-filer

wie gesagt, es geht auf nur upgrade aber Vorsicht, dass ihr dann kein unbeabsichtigtes OS Update macht

@johndo Ich hätte damit einfach das lan ersetzt der XG und dein eigentliches LAN als neues Extra Interface

Habe jetzt alle Gateways erneut angelegt, dabei wurden auch die aktuellen (Interface-)Namen vorbelegt. Hatte ja etwas Schiss, ob die Sense das wirklich alles auf die Reihe kriegt, aber es läuft. 😁

Hi,

ich konnte es mir selbst beantworten. Habe mal ein Factory Image installiert. Es wird automatisch erkannt das zwei Festplatten vorhanden sind und somit wird es als RAID1 eingerichtet.

Nach der Installation ist das im WebUI unter Diagnostics > GEOM Mirrors zu sehen.

b4f1a895-993e-4714-8953-ae803c777f9b-grafik.png

Boradcast in andere Netze weiterleiten ist echt nicht lustig.

Wir hatte mal einen Bug auf einem Core, der hat dann alles aus einem Netz ist ein anderes gebrückt.

Dem Netzwerk war es egal das da ein paar 10k pps fliegen, die Clients sind aber immer wieder aus dem Netzwerk geschossen worden.
Die halten es halt einfach nicht aus, wenn die so viele Pakete fressen müssen, vor allem irgendwelche Ramsch NICs.

Multicast Routing kann man machen, dann muss man das aber sehr zielgerichtet einbinden.
Wichtig ist zu beachten, das die Netze dann ja gekoppelt sind und sicherheitstechnisch wie eins zu betrachten sind, wenn hier was ausbricht ist die Verbreitung ins andere wahrscheinlich.

Da ist man wieder beim Problem des Netzdesigns, Sicherheit vers. Kompfort.

Wenn man das mit sauberen ACLs kombinieren kann, kann man den Impact reduzieren, aber es bleibt eine Brücke mit entsprechendem Risiko.

Wie ist denn die Latenz zwischen den beiden Clients über die pfsense?

Denn je nach Protokoll ist dieses mehr oder weniger Problematisch für die Bandbreite.
Die Windowsize wird zwar inzwischen oft gut mit skaliert aber das macht sich immer noch sehr negativ bemerkbar.

Über mein VPN konnte ich im Urlaub mit SMB auch nur 10-12 MBit nutzen.
FTP mit 10 Streams konnte den Tunnel dann auslasten.

Also auch ruhig im iperf mehrere gleichzeitig testen.

Hallöchen,

ja also bei mir funktioniert es nach der oben verlinkten Anleitung gleich gar nicht. In den suricata.log war nichts mit Warning oder Error hinterlegt. Seltsam. Die Pfade waren alle entsprechend richtig von mir - auch das typo hier:

@boobletins said in URLHaus - Anyone have a mod already?:

Modified /usr/local/pkg/suricata/suricata_yaml_template.inc as shown above to include

/usr/local/etc/rules.local/urlhaus.rules

sollte eigentlich so aussehen:

- /usr/local/etc/suricata/rules.local/urlhaus_suricata.rules

Dann, auch wenn unnötig dachte ich mir ich überschreibe einfach die custom.rules mit folgendem Script - jedoch ist das eine wui und da stehen dann doch noch ein paar Abhängigkeiten im Weg damit dies gelingen könnte.

#!/bin/sh fetch -o /usr/local/etc/suricata/rules.local/urlhaus_suricata.tar.gz https://urlhaus.abuse.ch/downloads/urlhaus_suricat a.tar.gz tar xvfz //usr/local/etc/suricata/rules.local/urlhaus_suricata.tar.gz -C /usr/local/etc/suricata/rules.local/ rm /usr/local/etc/suricata/rules.local/urlhaus_suricata.tar.gz rm /usr/local/etc/suricata/suricata_32296_igb1.300/rules/custom.rules mv /usr/local/etc/suricata/rules.local/urlhaus_suricata.rules /usr/local/etc/suricata/suricata_32296_igb1.300/rules/cus tom.rules chown root:wheel /usr/local/etc/suricata/suricata_32296_igb1.300/rules/custom.rules chmod 644 /usr/local/etc/suricata/suricata_32296_igb1.300/rules/custom.rules

Ist ja klar was passieren musste - in der wui unter cutsom.rules war nichts zu sehen und nach dem Refresh war die custom.rules natürlich wieder auf 0 kb geschrumpft :D

Hat hier jemand das selbe Problem ggf. auch gleich mit einer Lösung? ;)

Viele Grüße!

@marcfunk said in VPN zwischen FritzBox 7490 und pfSense 2.4.4-RELEASE-p3:

Doch wie erwähnt: Vom Fritte Netz zur pfSense läufts, vom pfSense Netz zur Fritte gehts leider nicht (und das ist eigentlich genau der Weg, den ich benötige).

OK das ist merkwürdig, denn das würde heißen die FB filtert oder macht irgendwelchen Schmuh.
Ist das Netz der FB dort direkt aufgelegt - also dieses 192.168.2.0/24?
Und Clients aus dem Netz haben auch die FB als Gateway?

Ansonsten bezüglich der FB Config: hattest du meinen letzten Post nicht gesehen zwecks main mode - weil du mode_aggressive gesetzt hast - was eigentlich nicht mehr "erlaubt" ist (zumindest bei größeren Installationen)? Auch das "editable = yes" und die keepalive_ip fehlen wobei man vielleicht keinen Host für das keepalive hat? Sonst dumm gefragt: hast du die Fritte mal neugestartet sicherheitshalber?

👍

Die o.g. private-domain Option sollte hier gar nicht nötig sein, weil der Server die Domain "intern" eh als solche erkennt. Habe ich erst gesehen.
Das ist nur nötig, falls eine vermeintliche Public Domain auf eine private IP auflöst.

Hmm, verstehe das Problem nicht. Ich ordne das nach Interfaces.

Also Kiste mit 6 physischen Intefaces bspw.:

WAN1 WAN2 SYNC DMZ "Console" TRUNK

Die benenne ich dann entsprechend:

1_WAN_DSL 2_WAN_Cable 3_SYNC 4_DMZ 5_CONS 6_TRUNK

Trunk wird nicht aktiv geschaltet und nur zugewiesen und benannt, weil da die VLANs draufkommen. Benennung und Zuweisung hilft aber, wenn man mal in der UI sucht, welches Interface draußen / an der HW was ist. 1-6 sind die HW Ports auf dem Gerät. Bei 10Gs hab ich dann ggf. auch mal X1/X2 genommen.

Dann kommen VLANs, bspw.:

10.23.1.0 LAN 10.23.2.0 IOT
etc.

die werden dann enannt:

V2301_LAN V2303_IOT
...

Damit ist alles ordentlich sortiert und gut. Ich muss nicht alles alphabetisch haben o.ä. das bringt mir nix, aber mit dem VLAN Tag mit drin hilft es mir direkt die IP Range und das VLAN Tag aus dem Namen heraus ableiten zu können.

Funktioniert fabelhaft. Und kann man auch mit Gruppen machen -> G_Infra, G_DMZs, G_WLANs, etc.

Aber man muss es ja nicht übertreiben ;)