Messages

121

German - Deutsch / Re: VPN eines einzelnen Clients (PS5) über die OPNsense

« on: January 15, 2023, 04:04:53 pm »

Wann und Warum entscheidet OPNsense ich route jetzt Traffic eines Clients durch den VPN Tunnel anstatt weiter ins Internet?
Durch ein angelegtes GW welches eine höhere Prio (niedrigerer Wert) hat? oder durch eine Floating Regel?

Kommt darauf an was für ein VPN du eingerichtet hast.

Bei IPsec wird das bei klassischem IPsec durch die Phase 2 definiert, wer zu wem geroutet wird. Bei IPsec VTI (geroutet) oder OpenVPN oder Wireguard wird meistens nur ein Transfernetz (die beiden virtuellen Endpunkte auf jeder Seite des Tunnels) erstellt und wer oder was darüber geroutet wird, liegt dann an dir. Das sind dann meist bei klassischem S2S VPN eine statische Route auf jeder Seite die auf die andere Seite zeigt - bei OpenVPN kann das durch die Config dann meist selbst direkt beim Aufbauen erledigt, WG und VTI brauchen meist manuell eine statische Route.

Was du aber möchtest ist ja konkret nicht alles darüber zu routen wie normal, sondern lediglich eine einzelne IP. Da kommen PBR - policy based rules - ins Spiel. Also definierst du eine Firewallregel auf dem IF, auf dem die PS5 hängt, als Source die PS5 IP rein und als Ziel dann sehr wahrscheinlich entweder "any" oder "!RFC1918" (also nicht in private Netze - ergo externe IPs) und gibst dort dann als Gateway gezielt das VPN GW ein, das du eingerichtet hast mit deinem VPN. Die Regel muss natürlich über andere die Traffic vom LAN erlauben, also potentiell recht weit/ganz nach oben.

Floating ist da unnötig und IMHO macht es den Regelsatz eher chaotisch wenn man nicht gleich sieht, was wo konfiguriert ist.

Ich würde aber drüber nachdenken, das VPN gegen deinen Host/Server im Internet zu bauen, statt zu einem anderen Home Anschluß. Die Heimanschlüsse haben mehr Latency und mit Traffic rein und wieder raus macht es nicht besser. Zudem bist du abhängig davon, was die andere Seite grade macht. Wenn da nen größerer Download läuft o.ä. hast du ggf. im Spiel auch keinen Spaß mehr. Daher würde ich als Host lieber einen VPS o.ä. nutzen. Dort kann man mitunter inzwischen auch relativ einfach ne OPNsense installieren (lassen) und sich das dann auch recht simpel zusammenklicken.

Cheers
\jens

122

German - Deutsch / Re: Dienst über bestimmtes Gateway

« on: December 01, 2022, 09:19:48 am »

> Ich müßte nun einige Dienste dazu bringen immer das Telekom Gateway zu nutzen.
> Beispielsweise SMTP und eine Hotelsoftware über Port 5555.

Am Besten die Ziele für die du das festlegen möchtest in Aliase packen. Also die SMTP Server oder die IP der Hotelsoftware mit Port 5555. Dann die Regeln auf das Interface packen, auf denen die Dienste dann hängen (LAN? Mehrere LANs? DMZ?). Da wirst du ja bereits eine Regel drauf haben, die die Dienste ins Internet lässt (wahrscheinlich mit Ziel any).

DAVOR packst du dann eine Regel (damit die vor der "allow any" greift) mit bspw. "Ziel Hotelsoftware" oder "Ziel SMTP Server" und ggf. dem Port und am Ende der Seite gibt es "Gateway" das normalerweise auf "nothing selected" steht. Also */default quasi. Dort kannst du jetzt gezielt dein DSL Gateway auswählen, dann wird der Traffic mit Ziel Hotelsoft oder SMTP Server o.ä. direkt via dem DSL Gateway rausgeschickt. In der Tabellenübersicht sollte die Gateway Spalte dann statt * das entsprechende DSL_GW haben. Wichtig nur, dass die Regel über den anderen steht, damit sie auch genutzt wird und keine andere Regel vorher greift die den Traffic ggf. via Starlink/default erlaubt.

Cheers
\jens

123

German - Deutsch / Re: github wird von FireHOL L3 geblock - ich checks nicht?

« on: December 01, 2022, 09:13:55 am »

Wie gesagt ist das auch kein Problem per se, sondern einfach ein Fakt, dass man im Hinterkopf haben sollte. Alles ab Level3 kann eben false positives haben und da sollte man sowas wie Negativ-Aliase schonmal parat haben, um die abzufiltern. Generell so einbauen wie das in der Doku angegeben ist hilft da schon ungemein. Gerade weil auch in Level1 ja u.a. CGNAT, RFC1918 und Multicast IP Ranges drin sind und sich viele dann wundern, wenn interne Sachen nicht mehr gehen

124

German - Deutsch / Re: opsense - NAT - VLAN

« on: December 01, 2022, 09:11:49 am »

> Ich konnte den Fehler finden, es war tatsächlich noch ein Routingproblem auf meinen Switch. Ich weiß es sollte nur einer routen ;-)

OK freut uns natürlich zu hören, aber auch für die Zukunft an andere die hier mitlesen:

Bitte schildert eure Probleme organisiert und sinnvoll, damit man euch helfen kann. Du schreibst nämlich jetzt schon wieder in den Replys erst "nein die ist in VLAN100", dann "Ja sie ist in allen VLANs", dann aber wieder "Sense in VLAN100, Jellyfin100 geht  aber 145 nicht". Davon, dass die Sense - hoffentlich - Interfaces in allen VLANs hat wie mehrfach gefragt steht da nichts

Darum wird ja u.a. von Mic auch gerne per default schon eine Netz-Skizze oder Plan angefragt, eben weil wir uns sonst nicht vorstellen können, was genau bei euch los ist und wie man am Besten helfen kann.

Darum: Macht es uns doch ein klein wenig einfacher euch zu helfen mit genauerer Beschreibung!

Cheers
\jens

125

German - Deutsch / Re: opsense - NAT - VLAN

« on: November 29, 2022, 12:18:06 pm »

> Die "Rule JELLYFIN" wurde automatisch erstellt. Warum funktioniert das nur beim VLAN100 (in dem auch die opnsense) ist. Das erklärt sich mir nicht.

Was heißt eigentlich "warum nur im Netz in dem die OPNsense ist"? Ist die im VLAN145 nicht drin? Oder im 50er? Wie soll die dann dahin Pakete schicken wenn sie da nicht drin ist? 

126

German - Deutsch / Re: fremde private Netzwerke auf meinem WAN normal?

« on: November 29, 2022, 12:16:12 pm »

> Wieso nicht einmal einen Dump dieser Pakete machen?

Außer aus Neugier wäre das irrelevant weil es ihn nichts angeht. Solang sein WAN läuft und sein Internet steht, ist alles sonstige DHCP Geblubber irrelevant und uninteressant.
Bei Kabel Anschlüssen (UM/KD, etc.) ist es recht "normal", dass da auf der WAN Seite DHCP läuft und da DHCP nunmal Broadcast ist, siehst du alle Requests im gleichen Netzsegment wie dein WAN. Kabel ist da shared medium daher sieht man das.
Auch bei dem ganzen GPON Glasfaser MultiMurks Gedöns ist das ähnlich, dass auf der letzten Meile dann eben keine eigene saubere Leitung für dich ankommt, sondern das nen geteiltes Medium für alle Parteien der letzten Meile am gleichen Strang ist. Dadurch sieht man da eben viel Blah Pakete die einen nicht interessieren und die man wegblockt und da der ISP da keine public IPs verbraten will sprechen die natürlich Netzintern dann mit privaten IPs.

Warum wirds geloggt? Na weil per default die default blocks aber auch die RFC/Bogon Blocks geloggt werden. Kann man aus machen, klar. Aber man kann auch einfach mal fragen was es sein könnte wenn man neugierig ist - ist ja nichts dabei.
Wichtig ist es nicht, kann also weg

Cheers

127

German - Deutsch / Re: Kernel/Crashdump

« on: November 29, 2022, 12:07:34 pm »

Noch kurze Info zur HW von mir weil die schon über meinen Tisch gelaufen ist:

Ich will es nicht kategorisch ausschließen, aber HW Fehler halte ich erstmal für eher unwahrscheinlich. Bevor die Box an @rabo zurück ging, hatte ich die früher im Jahr schonmal auf dem Tisch und sowohl mit pfSense also auch einer älteren OPNsense Version bespaßt und mehrere Tage laufen lassen. Da kam es nicht zu den Effekten, dass die Kiste "einfach so" in einen Crashdump/KernelDump Modus gelaufen ist, daher würde ich eher vermuten, dass es mit einem der letzteren Updates zu tun hat.

Ich bin allerdings nicht so tief im KDB Stacktrace lesen also ein paar der anderen Kollegen hier, daher jeder Input willkommen. Mich wundert aber tatsächlich der ZFS Part ein wenig, den ich im Dump sehe. Vielleicht was beim Schreiben oder am ZFS Pool selbst seltsam?

Cheers
\jens

128

German - Deutsch / Re: github wird von FireHOL L3 geblock - ich checks nicht?

« on: November 29, 2022, 12:03:36 pm »

Firehol Level3 hat das auch in seiner Beschreibung stehen:

> An ipset made from blocklists that track attacks, spyware, viruses. It includes IPs than have been reported or detected in the last 30 days. (includes: bruteforceblocker ciarmy dshield_30d dshield_top_1000 malc0de maxmind_proxy_fraud myip shunlist snort_ipfilter sslbl_aggressive talosintel_ipfilter vxvault)

Da die Liste aus 30 Tagen rückläufig erstellt wird und auch Reports drin sind, kann sich da immer mal wieder ein false positive drauf verirren. Im Gegensatz zum Level1 (sehr safe) oder Level2 (ebenfalls recht safe da aus den letzten 48h generiert) hat man da im dümmsten Fall einige Zeit lang ne falsche IP drauf. Github hat bspw. einen localen Knoten in Frankfurt, der bei github.com via GeoIP/Anycast ausgespielt wird. Der taucht aber gerne mal in irgendwelchen Listen auf, weil ein paar Leute gern in ihrem Github oder in Gists irgendwelche Virensignaturen speichern oder hinterlegen und ein paar tumbe automatische Systeme beim Abgrabbeln das dann als "Virenschleuder", Malware Verteilung o.ä. erkennen. Aus dem gleichen Grund landet auch immer mal wieder der eine oder andere Discord EU-West FRA Node auf der Level3 Liste.

Entweder also "use with care and knowledge" oder dann eben damit rechnen, dass man das ggf. mit einem negativ-Alias (wie es in der Doku steht) entblocken muss.

Cheers
\jens

129

German - Deutsch / Re: Netzwerk, Security & Firewall Usergroup

« on: November 28, 2022, 06:49:09 pm »

Kurze Erinnerung daran, dass diese Woche Freitag dann die erste Runde in kompletter Besetzung und im neuen Rhythmus stattfindet

130

German - Deutsch / Re: OpenVPN über virtuelle IP ?

« on: November 22, 2022, 12:05:26 am »

Wofür sind die Typ CARP Regeln? Die sollten IMHO automatisch erstellt werden und unnötig sein. Selbst wenn nicht machen die nichts weiter als CARP freigeben, damit die VIP ordentlich funktioniert und von A nach B schwenken kann. Mehr nicht. Da erlaubt aber noch nichts irgendwelche Zugiffe auf die VIP wenn du keine einrichtest.

Ohne mehr Details oder Screenshots kann man somit da leider sonst recht wenig zu sagen.

Cheers

131

German - Deutsch / Re: VLANs auf andere Netzwerkkarte übertragen

« on: November 22, 2022, 12:02:52 am »

Eben das! Und wenn das in proxmox läuft, ist es ja in Theorie noch egaler wenn man Zugriff auf den Proxmox behält und dort in der Konsole ggf Änderungen wieder zurückrollen kann. Selbst wenn man sich aussperrt hat man dann Zugriff via Konsole.

132

German - Deutsch / Re: Netzwerk, Security & Firewall Usergroup

« on: November 20, 2022, 05:04:12 pm »

Somit wären die nächsten Termine:

🌍🔗 https://meet.qwertiko.de/NSFW_UserGroup
Ausgabe #025 - 2022-12-02 - 17:00
Ausgabe #026 - 2022-12-16 - 17:00
Ausgabe #027 - 2022-12-30 - 17:00

133

German - Deutsch / Re: Netzwerk, Security & Firewall Usergroup

« on: November 20, 2022, 04:55:15 pm »

Moin zusammen,

wie schon in der letzten Ausgabe der Usergroup angesprochen werden ein zwei kleinere Änderungen etabliert, die sich nach 2 Jahren angekündigt und eingeschlichen haben 😄

Das sind dann bspw. diese Punkte hier:

• Der Name: dieser wird in Zukunft das pfSense verlieren und sich generell Netzwerk, Security und (OSS) FireWall 😉 Themen öffnen
• Das Format heißt zwar weiterhin offiziell "Usergroup", ist aber gefühlt eher ein lustig/gemütlicher Stammtisch und darf das auch gern bleiben und darin wachsen
• Die Namensänderung kündigt es schon an: es wird (vom Namen) nicht exklusiv OPNsense behandelt, sondern auch über Cousin pfSense oder andere Netzwerk-Tools & -Services und Dinge über dem Gartenzaun wird gequatscht. Das war bislang eh schon meistens der Fall - dann können wirs auch offiziell machen 😃
• Da ich dann keine getrennten Partys mehr werfen muss für unterschiedliche Produkte und Themen, kann ich diese alle zusammenfassen und die bisherigen Teilnehmer zusammenbringen und wir haben alle noch mehr Freude. Bislang kennen sich eh schon relativ viele der Teilnehmer der verschiedenen Usergroups (bspw. pfSense und OPNsense Gruppen)
• Ebenfalls weil keine getrennten Veranstaltungen mehr: es gibt dann einen neuen Raum-Link für alle der dann einheitlich ist - keine Unterschiede oder Chaos bei der Planung mehr 😅
• Und zuletzt: auch weil keine einzelnen zusätzlichen Meets mehr dazu gebraucht werden - können wir die Schlagzahl reduzieren auf alle zwei Wochen
• Vorteil dann bei zweiwöchentlicher Runde: keine lange Wartezeit bis zum nächsten Stammtisch und wenn man einen Monat mal nicht kann muss man nicht gleich einen ganzen Monat warten. Und da es dann alle zwei Wochen sind, ist auch die Chance geringer, dass wieder Ausgaben mehrmalig ausfallen müssen weil bspw. Urlaub, Ferien oder sonstige Dinge zusammenfallen.
• Zudem: einfacher zu merken, da wir dann nicht 1. Fr/2. Fr im Monat o.ä. haben, was teils verwirrend war wenn der 1. im Monat ein Freitag war und die Leute es dann komplett übersehen hatten. Wir starten einfach zum Jubiläum (schon 2 Jahre!) am 2. Dezember mit dem 14-Tages Rhythmus. Wenn mal eine Folge ausfallen muss - wie gesagt wg. Feiertagen etc. - kein so großes Problem weil man ja dann 2 Woche später weiter machen kann.

So das waren die wichtigsten Punkte. Was habe noch vergessen? Ah ja der neue Raum-Link. Durch den obigen neuen Namen (Netzwerk, Security & FireWall) haben wir jetzt einen noch besseren Raumnamen 😂

🌍🔗: https://meet.qwertiko.de/NSFW_UserGroup

Kommentare? Fragen? Anmerkungen?
⤵ Wie immer gerne hier drunter ⤵

Cheers
\jens

134

German - Deutsch / Re: VLANs auf andere Netzwerkkarte übertragen

« on: November 20, 2022, 04:47:11 pm »

Womit haste dir denn die Konfig zerschossen? Man sollte natürlich nicht unbedingt das "Netz" über das man auf die FW zugreift umziehen solang man keinen anderen Weg auf die Kiste hat. Das geht natürlich schief.

Aber wo ist sonst konkret das Problem?

Ich würde rangehen und erstmal ein VLAN anlegen auf dem neuen bxe0 IF das ich umziehen will was jetzt auf igb1 liegt. Eben NICHT das LAN über das ich draufgehe sondern was anderes.
Dann im Assignment einfach das Interface (OPTx oder wie dein Name ist) von igb1.vlanID auf bxe0.vlanID ändern, speichern, prüfen obs geht. Dann das VLAN auf igb1 löschen und nächstes.

Cheers

135

German - Deutsch / Re: OpenVPN über virtuelle IP ?

« on: November 20, 2022, 04:44:26 pm »

> Unter floating sind jede Menge automatisch generierte Regeln auch für ICMP, jeweils für IPv4 u. 6. Dann müsste es doch eigentlich damit schon funktionieren.

Nein, da es KEINE automagische Regel gibt die die Firewall auf dem WAN/LAN erstmal exponiert. WAN ist default dicht und LAN ist per Regel auf dem LAN IF erstmal per default offen. Nicht mehr, nicht weniger. Alle Regeln die da ausgeblendet automagisch angelegt sind, sind im Normalfall Regelwerk, das Grundfunktionalität sicherstellt wie eben DHCP oder AUSgehender Traffic VON der Firewall nach außen (egal wohin, LAN, WAN, whatever). Das sind meistens keine EINgehenden Regeln (außer für sowas wie IPsec oder DHCP).

Daher bin ich auch absolut kein Freund wenn man sich nicht auskennt gleich mit Floating Regeln zu spielen, weil den wenigsten Anwendern klar ist, was mit IN/OUT/BOTH bei der Richtung oder mit QUICK/non-Quick als Abarbeitung gemeint ist.

Deshalb braucht man für ICMP Echo Request erstmal Regeln sonst gibt es keine Ping Antwort. Dazu muss man auch noch beachten dass die WAN IP != der WAN VIP ist. Ggf. fehlt also eine Regel für die VIP.

> Was war noch einmal die Voraussetzung, damit eine VPN-Verbindung auch über die virtuelle IP funktioniert?

* VIP muss aktiv auf dem Knoten sein (State Master)
* VIP muss erreichbar sein (Regeln auf dem Interface)
* Routing der VIP (sofern anderer IP Range) oder auflegen der VIP (CARP IP) muss passen

> Muss da irgendwo noch eine Regel eingetragen werden?

Sicher, eine VIP wird nicht automagisch einfach freigegeben. OpenVPN erzeugt keine auto-Regeln, IPsec dagegen schon sofern nicht abgeschaltet.

> Ist es normal, dass man die FW nicht mehr anpingen kann, wenn sie sich im Backup-Status befindet, auch wenn sie eine eigene WAN Adresse hat?

Nein, dann ist etwas grundsätzlich falsch. Entweder gibt es keine korrekte ICMP Regel, die auf dem WAN Ping erlaubt (WAN address für ICMP Typ Echo Request erlauben) oder WAN address wird nicht korrekt gemappt weil noch weitere IPs existieren. Dann mit einem eigenen Alias in dem alle IPs auf dem WAN enthalten sind anlegen (IP von Master und Backup node sowie VIP sollten dann drin sein).

> kann ich die 192.168.178.34 von Debian aus, das sich im LAN der FW befindet, nicht anpingen. Ist das normal?

Ja weil das ein Nonsense-Test ist. WAN testet man nicht von LAN aus, sondern vom WAN. Alles andere geht meistens schief. Dein Debian hat jetzt nämlich den Backup Node als neuen Master und Default GW und dann versuchst du über den 2. Node den 1. Node auf dem WAN zu erreichen was meistens weird geroutet und asymmetrisch zurück kommt. Und damit gibts gern Probleme.

Wichtiger ist da eher ob die LAN von den Geräten noch geht. Also wenn es bspw. IP .1, .2 und .3 sind und .1 die VIP und .2 Master und .3 Backup Node ist, wäre es wichtig zu sehen, ob die IP .2 noch geht wenn er auf die .3 Failover macht. Und von extern muss man dann von "vorne" am WAN direkt testen.

Andernfalls müsste man ne custom outbound NAT basteln, der den Zugriff auf die externe IP der jeweils anderen Firewall über die eigene WAN IF Adresse mappt damit der Zugriff nicht asymmetrisch zurück kommt, sondern brav den richtigen Weg zurückroutet.

Hoffe das bringt Licht ins Chaos.

Cheers
\jens