Messages

Hier kann ich noch was beitragen:

- Man kann problemlos Floating IPs auf den Firewall legen und dann Ports per NAT auf interne Rechner weiterouten. Insofern geht das nicht nur theoretisch, sondern auch ganz praktisch.
- Wenn man seinen Firewall nicht über das WAN administrieren möchte, kann man auch mit einem ssh-Tunnel die Web-Oberfläche über einen 2. Rechner, dem am Internet hängt und am "LAN" hängt umleiten:
ssh -A -L 4430:<interne IP der OPNsense>:443 -N user@jumphost

jumphost ist während der Installation eine VM, die sowohl eine öffentliche und eine interne IP hat.
Später wird der jumphost vom WAN getrennt und ist nur über den Firewall erreichbar (NAT Regel für Port 22)

Irgendwo liegt hier noch eine bebilderte Anleitung rum, ich muss nur mal zum redigieren kommen, dann stelle ich einen Link ein.

Nachteile:
- Man verbraucht halt Floating IPs, weil die IPs für die Rechner nur  im internen Netz hängen sollen nict wiederverwendet werden können
- der gesamte ausgehende Traffic läuft über den Firewall und verbraucht die 20TB, das Kontingent der internen Rechner kann nicht genutzt werden.

Laut Screenshot wird 192.168.3.11 geblockt, die Regel "IN Source 192.168.3.1 und Ziel zB. 192.168.0.68 any any"
erlaubt aber nur für 192.168.3.1

Für die OPNsense sieht es einfach so auf, als auf WAN1 zwei Netze hängen .3.x und 192.168.0.xxx bis 100.

Ein Bild würde aber wirklich helfen-.

Das kann man so recht einfach machen, aber es bleibt das Problem der Certificate revocation, wenn ein Mitarbeiter ausscheidet.

Hier ist eine Idee, wie man das auch automatisieren kann: https://forum.opnsense.org/index.php?topic=12966.0

Eine Alternative wäre eine sehr kurze Laufzeit des Zertifikats und mit dem Risiko leben. Solange die Verteilung der Zertifikate gut genug automatisiert ist, merkt der Benutzer nichts davon.

Ja, das ist korrekt. Ich hatte die Option auch bei den Netzen nur hinter der OPNsense drin. Nachdem ich das auf den Standard zurückgesetzt habe geht es trotzdem noch.

Mein Tipp war also nicht richtig.

Ich bin nicht ganz sicher, aber probier mal unter den advanced Settings den haken bei

[ ] disable reply-to

zu setzen. Es knnte sein, dass das Paket von LAN 1 nach LAN 2 kommt, vom Server beantwortet wird und dann an den eigentlichen Gateway geht und nicht an den OPNsense.
Über das bin ich auch erst gestolpert.

Das kann ich aus der Ferne schwer sagen.

Hast Du die Möglichkeit, so was https://code.mendhak.com/docker-http-https-echo/ als docker Container hinter den HA-proxy zu hängen (Container von hier: https://hub.docker.com/r/mendhak/http-https-echo)

Dann einmal aufrufen und das Ergebnis hier posten. Irgendwo sollten dann die Header stehen, die auch der Nextcloud Server bekommt.

Im Prinzip macht ein Access Point ja nichts anderes, als drahtlosen Netzwerkvekehr in solchen über das Kabel umzuwandeln. Vorher prüft er noch die Authentifizierung und gut ist.

Jetzt kommt es darauf an, welchen Komfort du haben möchtest. Wenn Du SSID und Zugangsdaten pro Access Point konfigurieren möchtest, brauchst Du keinen zentralen Controller, sondern es reicht ein einfaches Gerät. Wenn Du mehrere Access Points zentral verwalten möchtest, brauchst Du die entsprechende Verwaltungssoftware + Hardware. Kommt halt darauf an, wie groß das Netz ist und wie viele Access Points man braucht.

End ja, es gibt Access Points, di können mehrere SSIDs verwalten du musst hat nur dafür sorgen, dass die dann auch auf unterschiedlichen Netzwerken im LAN landen, sonst hast Du ja nichts von der Trennung.

Zu den Unify Geräten kann ich Dir aber nichts sagen. Ich habe das mit eine OPNsense Firewall und mehreren OpenWrt Geräten als Access Points laufen. Im Prinzip nichts besonderes bei der Konfiguration, nur eine zentrale Verwaltung haben ich nicht.

Das kommt darauf an, was du mit weiterreichen meinst. Die Haken sind dafür da, dass der HA-Proxy zusätzliche Felder im Header des HTTP-Requests einfügt. Ob das jetzt funktioniert, kann ich nur raten, da ich den nicht nutze. Von daher mein Vorschlag, das zu testen.

Du musst hier unterscheiden:

• Firewall-Regeln leiten den Netzwerkverkehr auf IP-Ebene weiter und behalten dabei die IP-Adressen.
• Der HA-Proxy ist aber der Endpunkt der eingehenden IP-Verbindung und nimmt die HTTP-Anfrage entgegen. Statt sie aber selbst zu beantworten, baut der HA-Proxy seinerseits eine neue Netzwerkverbindung zum Web-Server auf und liefert das Ergebnis seiner Anfrage zurück. Deshalb sieht man am Web-Server die IP des Firewalls, auf dem der HA-Proxy läuft.

Die haken sind jetzt dazu da, dass der HA-Proxy seine eingehende Anfrage  nicht 1:1 weitergibt, sondern noch Zusatzinformationen ergänzt. Ob der Empfänger (dein Nextcloud) die verwendet und im Log ausgibt, musst Du dort einstellen.

Hier: https://docs.nextcloud.com/server/15/admin_manual/configuration_server/reverse_proxy_configuration.html
sollte sich die Antwort finden lassen.

Fail2ban und Reverse Proxy schließen sich aus, wenn man nicht selber basteln möchte.

Die Anfrage an den Web-Server kommt netzwerktechnisch ja immer vom Reverse Proxy und landet damit in den Logs. Was man machen kann ist:
- die original IP per X-Forwarded-For Header zusätzlich mitschicken,
- das Logging so anpassen, dass dieser Header statt der IP des Reverse Proxy in die Datei geschrieben wird (evtl. separate Log-Datei)
- Fail2ban so konfigurieren, dass er die neu geschrieben Log-Datei verwendet.

Am besten zuerst mal prüfen, ob die X-Forwarded-For Header ankommen. Entweder per Log-Konfiguration oder einen der netten Docker-Container statt des Nextcloud hinhängen, die alle Header in die Antwort des Web-Servers stecken.

Für mein WLAN habe ich ein paar TP-Link Archer C7 auf OpenWrt umgeflasht und nutze die als Access Point mit integriertem VLAN Switch.

Wenn Du mehrere SSIDs möchtest, möchtest Du die ja wohl auch in verschiedene getrennte Netze packen. Wenn Du jetzt nicht riesige Leerrohre liegen hast, bist Du dankbar, wenn Du nur ein Kabel ziehen musst, da bist Du schnell bei VLANs.

Aber warum willst Du die Fritzbox ablösen. Du kannst doch einfach einen exposed Host einrichten an die OPNsense und von da aus weitergehen. Spart erst mal den kauf eines Modems und du kannst das ganze schrittweise aufbauen.

Irgendwie scheint mir der Alias DirektWeb seltsam zu sein, ich lese da 2 Host IP-Adressen.

Wenn Du möchtest, dass Du aus Deinem LAN auf alles außer dem Netz 192.168.178.0/24 zugreifen kannst, dann würde ich als erste Regel eine block-Rule auf genau dieses Netz setzen und dann die entsprechenden allow Regeln danach.

block LANnet to 192.168.178/24
allow LANnet to any.

Falls Du aus dem LANnet aber doch noch auf das Web-Interface der fritzbox zugriefen möchtest, müssen die ersten Regeln ein
allow LANnet to 192.168.178.1 Port 443 und
allow LANnet to 192.168.178.1 Port 80
sein.

Wenn das geht, die noch 192.168.178.0/24 durch ein network Alias ersetzen.

So, das hat jetzt geholfen.

Das ist wirklich ein unerwartetes verhalten.

Vielen Dank
Stefan

Vielen Dank nochmal,

die reply-to Optionen habe ich jetzt sowohl auf der In Rule, als auch global ausgeschaltet, aber komme trotzdem noch nicht weiter.
Ich lese nochmal genauer durch, bis ich es verstanden habe.

Stefan

Vorab schonmal Danke,

aber jetzt würde ich gerne wissen, wie ich mein Problem lösen kann.

Ich bin ja hoffentlich nicht der einzige, der im Netz auf WAN Seite einen Rechner hängen hat, der mit einem Rechner hinter der OPNsense sprechen soll.

Eine Route in 192.168.7.0/24 mit Gateway OPNsense wird es ja nicht sein.

Hier verhält sich der OPNsense vollkommen anders als der parallel dazu hängende pfSense. Der verhält sich so wie erwartet. Ein ssh 192.168.109.5 auf dem pi funktioniert, wie es soll.

Schönen Abend
Stefan

Das verstehe ich jetzt nicht. Wenn ich vom Pi (192.168.7.24) eine ssh-Verbindung auf 192.168.1.10 aufbauen möchte, gehen die Pakte über den OPNsense an den Pi2, von dort an den OPNsense und von da an zur fritzbox, obwohl sowohl der WAN des OPNsense, als auch der Pi am Net 192.168.7.0/24 hängen.

Ein Ping vom OPNsense an den Pi (192.168.7.24) läuft wie erwartet, sowohl mit Source WAN als auch mit Source LAN.

Ein traceroute geht auch direkt:

# /usr/sbin/traceroute -w 2 -n  -m '18' -s '192.168.1.1'   '192.168.7.24'
traceroute to 192.168.7.24 (192.168.7.24) from 192.168.1.1, 18 hops max, 40 byte packets
1  192.168.7.24  1.003 ms  0.792 ms  0.809 ms