Messages

151

German - Deutsch / Re: IPsec site to site mit 3 Netzen

« on: October 26, 2022, 04:08:28 pm »

10.6.6.1 steht hinter der Hetzner OPNsense und ist erreichbar von A aber nicht B? Was sagen denn die Regeln dazu? Müsste ja wenn die beiden Tunnel sauber aufgebaut sind beide Netze Remote auf 10.6.x.y/16 Zugriff haben? Was für ein DNS ist das?`Der der Sense? Wenn ja ist das Unbound? Sind die ACLs dafür korrekt konfiguriert, dass die Remote Netze darauf zugreifen dürfen? etc. etc.

Ohne Regeln und mehr Details wirds beim DNS schwierig

Was die Site2Host2Site Verbindung angeht - wird schwierig. Das Problem ist dass die Fritzboxen mit Verlaub Mist sind. Sagt AVM unter der Hand auch. Zusammengedummte UI für Wenignutzer. Daher können die Boxen nur eine Phase 2 und die ist aufgebaut. Wenn du aber von A nach B willst über C, dann müssten beide Boxen eine zweite Phase 2 aufbauen mit dem Remotenetz der anderen Seite drin. Also bspw.

FritzA 192.168.0.0/24  <->  FritzB 10.100.0.0/27
und
FritzB 10.100.0.0/27  <-> FritzA 192.168.0.0/24

damit IPsec den Traffic aufnehmen und korrekt ins VPN schicken kann. Ansonten weiß Seite A mit 10.100.x nichts anzufangen und Seite B kennt 192.168.y nicht.

Man könnte vielleicht(!) was Basteln mit dem 10.6er Netz. Wenn aus dem Subnetz bei Hetzner nicht alles schon aufgeteilt und vergeben ist, könnte man zwei /24er davon abzweigen und vllt. als "1:1 NAT" für die jeweilige Seite mißbrauchen.

Also bspw.
FritzA 192.168.0.0/24  <->  10.6.255.0/24
FritzB 10.100.0.0/27    <->  10.6.254.0/27

Dann müsste man auf der OPNsense "nur"(?) den Stunt hinbekommen, dass eingehend auf dem IPsec Interface 1:1 geNATtet wird wenn die andere Seite erreicht werden will.

Sprich: du würdest dann auf Seite A mit 10.6.254.1 sprechen wenn du eigentlich 10.100.0.1 auf B erreichen willst. Umgekehrt von B würdest du 10.6.255.1 anreden, was dann zu hetzner läuft und von da 1:1 geNATtet wird auf 192.168.0.1. Da also beide Seiten ihren Kram jeweils auf 10.6.y.x umschreiben würde alles immer dank der 10.6.0.0/16er Route zu Hetzner laufen und dort dann durch 1:1 Subnetz NAT zur anderen Seite.

Das wäre aber ziemlich gebastelt und selbst mit zusätzlicher IPsec policy phase bin ich mir gerade unsicher ob es tatsächlich funktionieren würde.

Cheers

152

German - Deutsch / Re: aus dem Heimnetzwerk kein Ping an die LAN-IP der OPNsense möglich

« on: October 26, 2022, 03:57:37 pm »

Ja absolut. Und mit DNS Blocklisten im Unbound am Start läuft es noch besser, weil dann gar keine Verbindung erst aufgebaut wird - da keine IP bekannt ist. Natürlich gibts da immer wieder ein paar Problemchen mit Overblocking aber meistens sind das dann auch keine großen Verluste

153

German - Deutsch / Re: IPv6 - Multi VLAN und ULA

« on: October 26, 2022, 03:54:50 pm »

Was schade ist, denn IPv6 kann da nicht mal was dafür. Es regt aber leider nur noch auf, dass jeder neue Markteinsteiger der meint, er kann jetzt beim Breitbandausbau noch nen schnellen Euro mitverdienen (die ganzen Stadtwerke und Co.) jetzt mit Glas oder Kabel Zweitverwertung ums Eck kommen und die schnellen Bandbreiten dann mit dem ganzen uralt Mistdreck von PPPoE über Zwangstrennung bis zur unnötigen Netzanmeldung mit User/Pass (es gibt keinen Grund dafür!) und dynamischer IP bzw. IPv6 Prefixen so ziemlich alles versauen, was man auf der Checkliste abhaken könnte.

Jeden Businesskunden können sie problemlos einen Router oder Netzabschluß hinstellen, der ohne den ganzen Quatsch funktioniert. Nur der Endkunde muss sich durch Alten Technoschrott die Leitung versauen lassen.

Einzig mit einem he.net Tunnel habe ich es hinbekommen mal endlich sauber IPv6 intern auszurollen in diversen Netzen und konnte da auch endlich mal die Möglichkeiten von IPv6 ausprobieren. Statisch vergeben, dynamisch via DHCP6, SLAAC, Prefix Delegation etc. - aber das klappt wiederum nur mit nem Anschluß der zumindest ne nutzbare IPv4 hat.

Wenn jemand einen Dienst kennen sollte, der ein statisches IPv6 Prefix auf eine (dynamische) IPv6 routen kann/lässt oder das per BGP o.ä. anbietet - immer her damit. Aber mit dem dynamischen Quatsch in DE wird das immer ein rumgefrickel bleiben, das nicht sauber funktioniert.

154

German - Deutsch / Re: aus dem Heimnetzwerk kein Ping an die LAN-IP der OPNsense möglich

« on: October 26, 2022, 03:38:10 pm »

Gern. Das IP (und DNS) Blocking vom LAN ausgehend ist inzwischen eine der besten Möglichkeiten geworden, sich da etwas besser abzusichern. Eingehend erlaubt man oft ja eh kaum mehr irgendwas (wofür auch), so dass Blocking da nicht mehr viel bringt. Ausgehend kann das aber nochmal ganz andere Dimensionen abdecken, wenn man sich im schlechtesten Fall mal Malware eintritt und diese dann aber die Payload oder Control Server nicht erreichen kann um Murks nachzuladen, kann man da manchmal noch mit blauem Auge davon kommen. Und zusätzlich kann man mit den DNS Blocklisten etliches an nicht nur aufdringlicher und nerviger, sondern teils auch gefährlicher (drive-by Malware) Werbung wegdrücken. Zudem schont das oft bei Mobilgeräten noch den Akku weil die zu den geblockten Systemen - dank DNS - gar keine Verbindung aufzubauen versuchen und damit auch keine Daten senden oder Volumen verschwenden und die Apps teils schneller werden.

Den Kids ist das selbst aufgefallen, dass sie hier viel weniger Werbung und Kram auf Handy oder Tablet sehen und die Akkus länger halten als wenn sie woanders im WLAN waren. Jedes bisschen kann da helfen

155

German - Deutsch / Re: IPSEC VPN

« on: October 26, 2022, 03:07:21 pm »

> Die VPNs aufzubauen ist kein Problem. Aber wie kann ich es machen, dass die 2te VPN nur dann genutzt wird wenn die Haupt-VPN nicht geht?

AFAIR - keine Garantie - ist es bei zwei Tunneln mit gleichen Phasen2 so, dass der erste der Liste automatisch die Pakete abgreift und der zweite dann nicht dran kommt. Wenn also der zweite auf der langsameren Line liegt, müsste das klappen.

IPsec kann aber nicht schön/sinnvoll ohne Hacks mit MultiWAN bzw. MultiDestinations umgehen. Da gäbe es nur zwei/drei Möglichkeiten die sinnvoller wären:

a) IPsec mit VTI nutzen und zwei Tunnel bauen - einen zu WAN-A1 und einen zu WAN-A2. Dann darauf ne statische Route setzen und notfalls auf das andere GW umstellen wenn nötig. Ansonsten geht eine Failover GW Gruppe IMHO als Ziel nicht(?), daher würde es automatisch dann nur mit FRR+OSPF gehen. OSPF drüber ist dann aber wirklich automatisch, da bekommt man im Normalfall kaum mehr was mit wenn geschwenkt wird.

b) OpenVPN nutzen und die Verbindung vom Standort mit einer Verbindung zu dem Aufbauen, der zwei hat. Dort einen Server konfigurieren, den via Port Forwarding auf beide WANs hören lassen und auf der anderen Seite in der Client Config des Standorts mit nur einer Leitung dann als Ziel beide WANs des anderen Standorts angeben. Dann macht OpenVPN den Failover selbst wenn die Leitung down geht durch Einwahl über die 2. Leitung. Gibts nen kurzen MiniAusfall aber das wars. Nachteil: schwenkt nicht automatisch auf die andere Leitung zurück - das muss man mit kurzem Neustart des Clients dann selbst machen. Dafür gehts im Fehlerfall recht flott und halbwegs automatisch.

c) Wireguard benutzen und die Richtung ggü von OpenVPN umkehren. Heißt der Standort mit einer Leitung ist quasi der Pseudo"Server" (und bekommt als Gegenstelle nix eingetragen, damit er die Verbindung nicht selbst aufbaut). Die Wireguard Instanz auf der Seite mit 2xWAN wird dann einfach ganz normal mit der Gegenseite verbunden. Gibts Ausfall von WAN1 sollte Wireguard über WAN2 automatisch weiter rausgehen. Da WG die Verbindung durch Keys + PSK absichert und nicht auf feste Interfaces hört kann es einfach auf das andere Interface umschwenken und darüber weitersenden. Das klappt oft auch mit Zurückschwenken ganz OKish.

Am Besten bzw. stablisten und automatischsten ist natürlich die "eine Tunnel pro Verbindung" plus OSPF Geschichte, denn dafür ist das Routingprotokoll eben da und gemacht. Ist aber auch weiter entfernt von "einfach"

Cheers

156

German - Deutsch / Re: Netzwerkstruktur mit Firewall und wohin mit den Zugangsdaten?

« on: October 25, 2022, 05:48:19 pm »

Ohne dass irgendwo was steht, welche Ports die FritzApp nutzt, wirst du nicht weit kommen. Wenn es da nur um Zugriff auf die Box geht per HTTPS, dann sollte das leicht sein. Wenn du die Telefonie App meinst - meh. Das könnte häßlich sein ohne VPN.

157

German - Deutsch / Re: Bildschirmausgabe der Console wo in Log oder Remote

« on: October 25, 2022, 05:42:47 pm »

Sollte eigentlich im Syslog selbst auftauchen, ansonsten schreibt auch dmesg Logs. Ein "grep" in /var/log sollte da eigentlich was aufzeigen.

158

German - Deutsch / Re: Frage zu DHCP

« on: October 25, 2022, 05:41:51 pm »

Oder ggf. mal noch bei Access Points oder Switchen prüfen, obs da ein Feature gibt das "Fremde/Rogue DHCP" erkennen kann. Manchmal läuft auch sowas amok aber dann kommt meistens keine DHCP Verbindung zustande. Aber wenn da was gefiltert wird, könnte das auch reinschlagen.

159

German - Deutsch / Re: pf scheint nichts mehr zu tun

« on: October 25, 2022, 05:40:21 pm »

> Auf einer parallel installierten neuen OpnSense funktioniert es so, wie es soll.

Dann bleibt nur alle Regeln durchsehen denn dann liegt es an der Konfiguration. Da kann man jetzt von außen schwer hellseherisch tätig werden
Ohne das Regelwerk durchzukämmen wird man nicht finden, warum der Traffic erlaubt ist. Bei sowas sind es zu >90% Floating- oder Gruppenregeln, die auf mehr greifen als eigentlich "gedacht" war. Oder es wurden mal wild in/out gemixte Regeln gebaut oder eine der gern mal empfohlenen "!<alias>" Ziele genutzt, die dann beim Hinzufügen von neuen Interfaces gern mal explodieren, weil man nicht mit neuen Netzen gerechnet hat und das NOT dann nicht so funktioniert wie gedacht.

Das wären zumindest die üblichen Verdächtigen, die ich abklappern würde

160

German - Deutsch / Re: IPsec bricht ab

« on: October 21, 2022, 05:33:39 pm »

Das ist nur ein einziges Log. Kannst du das mal etwas länger posten?

Außerdem ist die Bintec Config richtig murks. Lifetime von Phase 1 ist 9999? Warum? Geht da nicht mehr in das Feld rein? P1 sind normalerweise mind. 28800 lang, viele große Kisten setzen sogar (meh) auf 86400 (1d). Wenn da nur 9999 möglich ist klingt das ziemlich buggy, denn IPsec mit 4h oder 24h in P1 gibts jetzt nicht erst seit gestern.

Zudem DH Group bzw. PFS Group in Phase 2 nur mit DH5? Geht da mehr? Das ist auch schon länger durch und unter DH14 wird eigentlich heute nix neues mehr in Betrieb genommen. Das sieht mir sehr nach (uralt) Firmware auf der Bintec aus?

Ich würde versuchen da mal hinzubekommen, dass die bitte geupdated wird und mal ordentliche Konfigs kann.

Bei der OPNsense auch alles abwählen, was NICHT in der Bintec konfiguriert ist, gerade bei der Crypto. Die Bintecs sind dumm und je nach Richtung wer zuerst aufbaut bekommen die sonst ggf. die Crypto nicht hin. Besser man liefert keine 3,4,5 verschiedenen Settings, sondern eine die passt auf beiden Seiten.

Ansonsten ggf. mal auf IKEv1 downgraden, wir hatten auch schon Mistkisten, die bei Umstellung auf v2 einfach komplett nutzlos waren und es nicht gebacken bekommen haben den Tunnel stabil aufzubauen. Generell schon so viel lustigen Spaß mit Bintecs auf der anderen Seite gehabt dass ich finde man sollte die einfach Brandroden und durch was ersetzen, was auch halbwegs modern ist.

Cheers

161

German - Deutsch / Re: HA Update erst auf Backup-FW dann auf Master-FW möglich?

« on: October 21, 2022, 05:24:02 pm »

> und bei NAT Outbound als NAT Address "WAN address" statt "VIP WAN" ausgewählt.

Nein, bei NAT Outbound wird NUR bei localhost nach extern die WAN address genutzt, für die internen Netze nach außen MUSS "VIP WAN" genutzt werden, ansonsten gibt es kein fehlerloses Failover. Wenn die VIP nicht genutzt wird, kann es kein sauberes Umschalten geben, da die States dann auf einer IP hängen, die die 2. Firewall NICHT bedienen kann, damit reißen alle Verbindungen ab. Die beiden Firewalls selbst müssen aber ihren eigenen Kram nach draußen sauber NATten können, daher muss localhost -> extern über WAN Address (was ja standard im Auto Modus ist) und NUR der Traffic von dem/den (V)LAN Interface(s) nach extern über die VIP Adresse gehen. Wenn unklar, einfach nochmal in die CARP/HA Doku dazu reinsehen, ansonsten baut man sich den Bug-by-design ein und fragt sich hinterher warum beim Schwenk der Firewalls ständig die Verbindungen abreißen und alles abgeschnitten wird

Cheers

162

German - Deutsch / Re: pf scheint nichts mehr zu tun

« on: October 21, 2022, 05:18:58 pm »

> Der Ping geht durch, obwohl ich in der Firewall für das VLAN noch gar nichts frei geschaltet habe. Selbst eine Regel, in der in diesem VLAN alles von überall her geblockt werden soll hilft nicht weiter.

Weil du von der Firewall selbst testest. Hast du als Source denn das neue VLAN eingestellt? Ansonsten ist der Test wertlos, denn bei automatischer Source wird immer die dem Ziel nächste IP genutzt. Wenn du also bspw.

neuesVLAN10
VLAN5
VLAN2

hast und einfach nur in eine IP auf VLAN2 pingst, wird die Sense den Ping von ihrer eigenen Source IP im VLAN2 absenden und nicht aus dem VLAN10.

Dazu kommt, dass im Normalfall die Sense Regeln in place hat, dass ausgehender Traffic von localhost für Diagnose erstmal natürlich erlaubt wird, denn die Firewall soll ja selbst in die Netze kommen. Der Test müsste also wie gesagt mit Source IP neuesVLAN10_Address nach irgendeiner IP in VLAN2 sein und dann wird er im Normalfall auch nicht funktionieren.

Wenn "pf nicht mehr funktionieren" würde, ginge auch kein NAT etc. mehr - das würde man merken. Einfach mal die automatisch erstellten Regeln genauer anschauen (auch die von localhost und Co) dann wird das ggf. klarer.

Cheers

163

German - Deutsch / Re: aus dem Heimnetzwerk kein Ping an die LAN-IP der OPNsense möglich

« on: October 21, 2022, 05:15:10 pm »

> Firehol Level 1 auf LAN?!?!
> Das kann nicht gutgehen! Level 1 nur auf WAN anwenden, und auch nur wenn kein weiterer Router am WAN der Sense hängt. Selbst bei CGNAT kannst Du Probleme kriegen. Die Regel dann in jedem Fall aber auch nur auf die Quelle anwenden, nicht als Ziel angeben. Oder Level 1 gleich weglassen

DOCH. Das klappt sogar sehr gut. Firehol_level1 ist wie level2 absolut geeignet für IN und OUT Traffic. Und sinnvoll dazu. Natürlich gibts da noch andere die dann zusätzlich Sinn machen, gerade ausgehend für die ganzen Malware IPs aber davon abgesehen ist das absolut gängig.

Was man aber natürlich lesen(!) sollte dazu ist die Doku. Und da steht - u.a. auch ganz groß bei der firehol_level1 - drin, dass man aufpassen muss, weil bei level1 auch Bogon, RFC1918, Multicast und anderer Kram wie der CGN Range 100.64.64.x geblockt wird. Was aber überhaupt kein Problem vom LAN aus ist, da man den eh nicht erreichen muss/will.

Aber: man muss auf dem/den internen Interfaces wo man das mit draufklebt natürlich schauen, ob man sich damit (gerade bei mehreren VLANs) Traffic abgräbt. Damit kann man jetzt entweder hergehen und das als INbound Regel auf dem WAN anlegen (mit firehol als Source Alias) und als OUTbound ebenfalls (aber mit Destination firehol!).

Oder man arbeitet transparent ohne Floating und in/out mischmasch und legt sich dann für ausgehenden Traffic ein zweites Alias an, in welchem man die nötigen Netze die man braucht excluded. Das wiederum ist alles in der Doku erklärt. Dazu einfach Host- und/oder Netz-Aliase anlegen die dann negierte IPs/Netze haben und die zusammen mit der Firehol1 zu einem Alias zusammenmixen. Damit holt man dann die negierten Aliase aus dem Level1 Netset raus und hat dann eines, das man intern eingehend als Regel ganz normal sauber verwenden kann. Oder man passt eben die Regelreihenfolge an und erlaubt erstmal internen Traffic wohin man möchte etc. und blockt dann diverse Blocklisten und hat danach noch eine Allow Any wenn man das möchte.

Ansätze gibt es da also mehrere, man muss sich aber vorher klar sein, was man denn genau möchte. Die Lösung hängt immer davon ab, wie die Regeln aktuell aussehen

Cheers

164

German - Deutsch / Re: Frage zu DHCP

« on: October 21, 2022, 05:03:47 pm »

STP, RSTP, alles was auf Switch Seite dafür sorgt, dass nicht sofort ein physikalischer Link sauber anliegt und erst noch verhandelt werden muss. Radius based MAC etc. etc.

Ansonsten Stecker am PC raus, Stecker rein und auf nem anderen Recher/laptop gleichzeitig mal das DHCP Log auf der Sense pullen und schauen WANN überhaupt die DHCP Frage rein und die Antwort rausgeht. Ansonsten kann man nur spekulieren.

165

German - Deutsch / Re: Domain-Weiterleitung mit Port

« on: October 21, 2022, 05:01:37 pm »

Ich wäre auch versucht gewesen das erstmal per Forward zu machen und ansonsten dann eben als Fingerübung über Reverse Proxy mit HAproxy oder Nginx zu lösen, könnte ja sein, dass man das doch per HTTPS machen mag weil HTTP unverschlüsselter Schmutz ist und man dann gleich lernt wie man das sauber mit Zertifikat macht Aber viele Wege führen nach Rom