ich verwende OPNSense um den "privaten" teil des netzes vom "etwas öffentlicheren" teil zu trennen.
das heisst während die meisten rechner LAN seitig an OPNSense hängen hat's auch rechner auf der WAN seite.
ich möchte nun von einem der rechner auf der WAN seite mittels VNC auf einen rechner im LAN zugreifen.
bei meiner alten firewall lösung geschah dies mittels destination NAT, d.h. ein bestimmter port (z.b. 5911) der firewall wurde auf den VNC port des internen rechners (<IP vnc server>:5900) umgeleitet, wobei von aussen nur die firewall zu sehen war. es wurde von aussen also eine verbindung auf <firewall>:5911 aufgebaut und <IP vnc server> blieb verborgen.
nun versuche ich etwas änliches mit OPNSense zu konfigurieren. ich bin davon ausgegangen dass ich dies mit port forward machen muss. dies habe ich entsprechend konfiguriert, sehe nun aber dass dadurch vom rechner im WAN nicht eine verbindung auf die firewall, sondern durch die firewall hindurch auf <IP vnc server> geschaltet wird. jedenfalls wird dies so im log der firewall dargestellt.
die so geschaltete verbindung wird nun aber von der firewall geblockt aufgrund der automatischen regel "Block private networks from WAN_UpLink". das port forward hat zwar automatisch eine regel erstellt für den verkehr vom rechner im WAN zu <IP vnc server>:5900, diese kommt aber stets nach der automatischen blockierregel und kommt somit gar nie zum zug.
ein workaround wäre allenfalls, die automatische regel "Block private networks from WAN_UpLink" auszuschalten und eine entsprechende manuelle regel zu definieren welche tiefere prio hat als diejenige für den zugriff auf <IP vnc server>:5900. ich frage mich allerdings ob das eine saubere lösung ist.
lieber würde ich eigentlich den <IP vnc server> im netz verstecken und von aussen bloss die IP von OPNSense sichtbar machen.
wie gehe ich da am besten vor und macht das so überhaupt sinn?
vielen dank!
Naja, eigentlich sprichst du hier ja nicht von einem externen WAN/Internet sondern möchtest dein lokales Netz segmentieren.
Wenn dein "WAN" privat adressiert ist (RFC1918), dann musst du die "Blocking private Networks" entfernen oder wie von dir bereits erwähnt: Eine Rule manuell erstellen und oben die spezifische (Source Host) hinzufügen.
Quotelieber würde ich eigentlich den <IP vnc server> im netz verstecken und von aussen bloss die IP von OPNSense sichtbar machen.
Ja, das ist durch NAT ja gegeben. Die Frage ob das Sicherheitstechnisch etwas bringt, lassen wir mal aussen vor.
vielen dank für die rasche antwort!
leider krieg ich die verbindung nach wie vor nicht hin.
hab die regeln für's blockieren der lokalen netze vom WAN aus nun manuell erstellt und die automatische regel entfernt.
diejenige welche port forward generiert ist nun zuoberst.
mit capture sehe ich nun pakete zwischen dem rechner im WAN und der firewall auf port 5911, sowie pakete zwischen dem rechner im WAN und demjanigen im LAN auf port 5900. die pakete sind in beiden richtungen unterwegs.
eine verbindung krieg ich allerdings trotzdem nicht hin.
woran könnte das noch liegen?
Kannst du mal bitte mehr Informationen geben
- einen grafischen netzwerkplan
- Screenshots
- Firewall
- wan
- lan
- deine angelegte Regel für das vnc
- läuft diesense auf Blech oder als vom
Bitte alle Infos die zur schnellen Lösung helfen können
Gesendet von iPad mit Tapatalk Pro
Quote from: bongo on November 10, 2020, 09:40:11 PM
vielen dank für die rasche antwort!
leider krieg ich die verbindung nach wie vor nicht hin.
hab die regeln für's blockieren der lokalen netze vom WAN aus nun manuell erstellt und die automatische regel entfernt.
diejenige welche port forward generiert ist nun zuoberst.
mit capture sehe ich nun pakete zwischen dem rechner im WAN und der firewall auf port 5911, sowie pakete zwischen dem rechner im WAN und demjanigen im LAN auf port 5900. die pakete sind in beiden richtungen unterwegs.
eine verbindung krieg ich allerdings trotzdem nicht hin.
woran könnte das noch liegen?
Windows Firewall auf dem Zielhost aktiv? Windows lässt standardmäßig nur das eigene Subnetz als Quelle zu.
hm.
also die windows firewall hatte ich auch schon im verdacht.
was ich zwischenzeitlich noch versucht hab ist die windows defender firewall auf dem zielhost disablen und auf opnsense alle verbindungen vom host im wan zum zielhost erlauben.
geholfen hat's aber nicht.
gibt's denn allenfalls ne möglichkeit dass ich diesen zugriff natten kann, so dass der zielhost diesen als zugriff von der firewall (also vom LAN port der firewall) statt vom ursprünglichen host sieht?
soweit ich das damals verstanden hab hat das mit meiner alten firewall so funktioniert...
hier noch wie das ganze aussieht...
was hat das für ein ziel, warum benötigst du so ein konstrukt?
gib doch einfach den clients einen vpn zugang.
Kannst du mal bitte noch einen Screenshot von deiner Port Forwading Config posten?
Kannst du ein ipconfig /all von deinem Client posten?
Subnetzmasken auf den Interfaces der opnsense richtig gesetzt?
hoffe das ist lesbar...
Ist das gewollt, dass du bei der Translation den Port änderst? WAN Seitig hört die opnsense auf port 5901 und du "schickst" die pakete weiter auf port 5900?
Versuche mal "Destination Port Range" und "Redirect Target Port" beide auf 5900 zu setzen.
Kannst du dann auf dem source host (WAN seitig) mal schauen ob du ein connection test mit telnet machen kannst (telnet 172.16.0.10 5900)?
ja, das ist gewollt da ich je nach port auf einen anderen rechner in LAN zugreifen möchte (hat mit der alten firewall so funktioniert).
hab nun mal beides auf 5900 gesetzt, allerdings ohne erfolg. vnc geht noch immer nicht und mit telnet krieg ich auch keine antwort.
hab mir aber noch folgende überlegung gemacht (wobei ich nicht weiss ob da was dran sein könnte):
- so wie ich's verstehe macht opnsense bei port forward kein destination nat, d.h. der host im LAN sieht die ip des host im WAN und der host im WAN sieht in der antwort die ip des host im LAN. korrekt?
wenn nun der host im WAN das nächste paket schickt so schickt er's nicht mehr an die WAN ip der firewall sondern an die ip des host im LAN, also in's 192.168er subnetz von welchem er aber nicht weiss wo es liegt. somit geht das paket auf seinen default gateway welcher nach draussen ins internet ist, d.h. er schickt's zum router1 und nicht zu opnsense.
könnte da was dran sein?
hab noch versucht die route auf dem source host entsprechend zu setzen aber ohne erfolg ;-(
Also eigentlich verhält sich opnsense da nicht anders wie andere Router... Und doch: Port Forwarding ist eigentlich ein Destination NAT bei dem auch noch die Ports "übersetzt" werden können.
Die Windows Firewall hast du mal komplett deaktiviert auf dem Target Host (im 192.168er Netz), oder? Was sagt das Firewall Log auf der opnsense? Wird irgendwas mit diesem Port geblockt?
also wenn opnsense diese verbindung nat/pattet so sehe ich nicht was schief gehen könnte.
das wär dann genau das was die alte firewall auch macht und damit funktioniert's.
die windows firewall auf dem target hatte ich ausgeschaltet, hat aber nix geholfen.
opnsense meldet nix was geblockt würde.
@bongo leider hast du meine fragen nicht beantwortet, warum setzt du dieses konstrukt ein?
welche gründe hast du oder was genau ist das ziel, so wie ich das verstanden habe
ein windows rechner ist vor dem wan interface der sense und soll irgend was mit vnc aufrufen im lan der sense?
warum? warum muss der windows rechner vor der wan der sense sein?
der wan seitige rechner ist für gewisse dienste im internet sichtbar, wogegen die rechner im lan durch opnsense abgeschottet sind.
um notfalls für wartung doch von remote zugreifen zu können will ich mir die option offen halten um vom rechner im wan über vnc drauf zu schauen.
@micneu Ungeachtet der Frage, welchen Sinn das Setup macht, sollte es funktionieren, oder sieht du grad einen offensichtlichen Fehler?
ich hab noch einen weiteren versuch gemacht:
mit opnsense bediene ich noch ein zweites lan, nennen wir's lan2.
wenn ich auf dem interface von lan2 eine regel definiere die port 5900 öffnet zum zielhost, so funktioniert vnc von rechnern im lan2 zum zielhost im lan1 knitterfrei.
selbige regel vom wan zum lan1 funktioniert jedoch nicht.
gibt das allenfalls einen hinweis?
nehme an dass dadurch die windows firewall schon mal als problem ausscheidet da die situation im lan1 beim zugriff auf den zielhost wohl identisch ist, egal ob der source host im lan2 oder im wan hängt, oder?
untenstehend noch die port 5900 captures, einmal für den erfolglosen verbindungsversuch WAN->LAN1 und danach für den erfolgreichen LAN2->LAN1. was auffällt ist die zahl hinter tcp, von welcher ich noch nicht rausgefunden hab was sie bedeutet.
NONWORKING FROM WAN (WAN_UpLink) TO LAN1 (LocalLAN):
WAN_UpLink
re0 13:47:30.711020 IP 172.16.0.9.49181 > 192.168.1.20.5900: tcp 0
WAN_UpLink
re0 13:47:30.711627 IP 192.168.1.20.5900 > 172.16.0.9.49181: tcp 0
WAN_UpLink
re0 13:47:30.711683 IP 192.168.1.20.5900 > 172.16.0.9.49181: tcp 0
WAN_UpLink
re0 13:47:31.716944 IP 172.16.0.9.49181 > 192.168.1.20.5900: tcp 0
WAN_UpLink
re0 13:47:31.723908 IP 192.168.1.20.5900 > 172.16.0.9.49181: tcp 0
WAN_UpLink
re0 13:47:31.724008 IP 192.168.1.20.5900 > 172.16.0.9.49181: tcp 0
WAN_UpLink
re0 13:47:33.732412 IP 172.16.0.9.49181 > 192.168.1.20.5900: tcp 0
WAN_UpLink
re0 13:47:33.733548 IP 192.168.1.20.5900 > 172.16.0.9.49181: tcp 0
WAN_UpLink
re0 13:47:33.733601 IP 192.168.1.20.5900 > 172.16.0.9.49181: tcp 0
LocalLAN
re1 13:47:30.711075 IP 172.16.0.9.49181 > 192.168.1.20.5900: tcp 0
LocalLAN
re1 13:47:30.711598 IP 192.168.1.20.5900 > 172.16.0.9.49181: tcp 0
LocalLAN
re1 13:47:31.716974 IP 172.16.0.9.49181 > 192.168.1.20.5900: tcp 0
LocalLAN
re1 13:47:31.723867 IP 192.168.1.20.5900 > 172.16.0.9.49181: tcp 0
LocalLAN
re1 13:47:33.732468 IP 172.16.0.9.49181 > 192.168.1.20.5900: tcp 0
LocalLAN
re1 13:47:33.733512 IP 192.168.1.20.5900 > 172.16.0.9.49181: tcp 0
WORKING FROM LAN2 (LocalWIFI) to LAN1 (LocalLAN):
LocalLAN
re1 13:50:31.054197 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 0
LocalLAN
re1 13:50:31.054677 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 0
LocalLAN
re1 13:50:31.055041 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 0
LocalLAN
re1 13:50:31.056449 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 12
LocalLAN
re1 13:50:31.056809 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 12
LocalLAN
re1 13:50:31.057791 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 1
LocalLAN
re1 13:50:31.057804 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 1
LocalLAN
re1 13:50:31.057811 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 1
LocalLAN
re1 13:50:31.058084 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 0
LocalLAN
re1 13:50:31.058092 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 1
LocalLAN
re1 13:50:31.059066 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 4
LocalLAN
re1 13:50:31.059078 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 4
LocalLAN
re1 13:50:31.059085 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 4
LocalLAN
re1 13:50:31.059092 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 4
LocalLAN
re1 13:50:31.059098 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 8
LocalLAN
re1 13:50:31.059416 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 0
LocalLAN
re1 13:50:31.059423 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 4
LocalLAN
re1 13:50:31.060068 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 16
LocalLAN
re1 13:50:31.108838 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 0
LocalWIFI
re2 13:50:31.054084 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 0
LocalWIFI
re2 13:50:31.054697 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 0
LocalWIFI
re2 13:50:31.055031 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 0
LocalWIFI
re2 13:50:31.056459 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 12
LocalWIFI
re2 13:50:31.056799 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 12
LocalWIFI
re2 13:50:31.057801 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 1
LocalWIFI
re2 13:50:31.057809 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 1
LocalWIFI
re2 13:50:31.057816 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 1
LocalWIFI
re2 13:50:31.058076 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 0
LocalWIFI
re2 13:50:31.058087 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 1
LocalWIFI
re2 13:50:31.059076 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 4
LocalWIFI
re2 13:50:31.059083 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 4
LocalWIFI
re2 13:50:31.059090 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 4
LocalWIFI
re2 13:50:31.059096 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 4
LocalWIFI
re2 13:50:31.059103 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 8
LocalWIFI
re2 13:50:31.059407 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 0
LocalWIFI
re2 13:50:31.059419 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 4
LocalWIFI
re2 13:50:31.060077 IP 192.168.1.20.5900 > 10.1.1.42.49595: tcp 16
LocalWIFI
re2 13:50:31.108829 IP 10.1.1.42.49595 > 192.168.1.20.5900: tcp 0
Quotenehme an dass dadurch die windows firewall schon mal als problem ausscheidet da die situation im lan1 beim zugriff auf den zielhost wohl identisch ist, egal ob der source host im lan2 oder im wan hängt, oder?
Wenn du die Windows Firewall (zum Testen) komplett deaktiviert hast (auf allen Profilen Domain, Private, Public), dann spielt das keine Rolle.
Ansonsten kann es schon mal passieren, dass eine Rule nur für ein Lokales Netz offen ist (src) und nicht das korrekte private Netz definiert ist. Die Windows Firewall ist relativ kompliziert und nicht ganz einfach zu managen.
1. du willst im notfall auf deine sense kommen, setze ein vpn ein
2. ich muss mir später deine konfig mal anschauen, in deiner grafik ist nicht von einem lan2 zu sehen
ich sehe nur das sogenante wan netz 172.xxxx und dein 192.xxx
Quotemit opnsense bediene ich noch ein zweites lan, nennen wir's lan2.
Ah, diese Info hast du bis jetzt unterschlagen :-). Welche IP Range bedienst du im LAN2? Etwa auch 192.168.x?/24
nein, LAN2 ist 10.1.1.x, wie in obigem capture zu sehen.
tut aber meiner meinung nach hier eigentlich nix zur sache.
Quote from: micneu on November 11, 2020, 02:07:44 PM
1. du willst im notfall auf deine sense kommen, setze ein vpn ein
2. ich muss mir später deine konfig mal anschauen, in deiner grafik ist nicht von einem lan2 zu sehen
ich sehe nur das sogenante wan netz 172.xxxx und dein 192.xxx
nein, ich will nicht auf die sense kommen sondern auf rechner dahinter.
das zweite lan (10.1.1.x) hängt an einer separaten netzwerkkarte.
Mach doch mal bitte einen neuen grafischen Netzwerkplan wo alle netze aufgeführt sind.
So wie ich dich verstanden haben sind an der sense lan1 und lan2 richtig, Bilder zum text sind immer besser zum verständnis.
Kann es sein das ich in deiner log Datei mindestens 3 netze sehe?
Gesendet von iPad mit Tapatalk Pro
Also bei mir habe ich es getestet mit der Regel
(https://uploads.tapatalk-cdn.com/20201111/a1938581859433e585ed872c355adf65.jpg)
Und zum besseren Verständnis hier noch mein netzwerkplan
Die vnc gegensteuern ist bei mir auch im .3. netz wie alle ausser meine Gäste.
(https://uploads.tapatalk-cdn.com/20201111/fc3289a83576874e7d38b0f1edb8cf77.jpg)
Gesendet von iPad mit Tapatalk Pro
also du kommst damit vom wan ins lan über vnc?
angefügt noch das ergänzte bild.
vom lan2 ins lan1 funktioniert's, vom wan ins lan1 nicht.
ich verwende tight vnc.
Nochmal, du hattest geschrieben das du den zugriff für Notfälle benötigst, deshalb war meine Anregung dafür ein VPN zu nutzen.
Wie kommen die Leute denn auf den Rechner der vor deinem wan der sense ist. Bitte mehr Informationen
Gesendet von iPad mit Tapatalk Pro
Quotevom lan2 ins lan1 funktioniert's, vom wan ins lan1 nicht.
OK, habe ich soweit verstanden. Kannst du bitte mal das trace-File vom WAN interface hier hochladen? Im GUI sieht man da nicht viel. Len=0 sind wahrscheinlich TCP-ACKs/SYNs (also haben eigentlich keinen Payload/Inhalt).
Und die Windows-Firewall hast du auf dem ziel-host komplett deaktiviert, korrekt?
meinst du das capture file? ist im anhang.
hab vermutet dass das die payloadgrösse sein könnte.
schon komisch dass da was durchgeht aber irgendwie gefiltert wird...
windows firewall ist ausgeschaltet, port forward ist auch nicht mehr konfiguriert dafür eine regel für die verbindung vom wan host zum lan1 host, genau gleich wie diejenige vom lan2 host zum lan1 host.
Quote from: micneu on November 11, 2020, 04:42:01 PM
Nochmal, du hattest geschrieben das du den zugriff für Notfälle benötigst, deshalb war meine Anregung dafür ein VPN zu nutzen.
Wie kommen die Leute denn auf den Rechner der vor deinem wan der sense ist. Bitte mehr Informationen
auf den rechner im wan komme ausschliesslich ich, auf unterschiedlichen wegen...
aber von dort möchte ich dann gesichert weiterkommen, wenn ich z.b. einen rechner im lan neu booten muss oder auf irgend eine steuerung zugreifen muss.
Ja, genau dafür ist doch VPN. ???????
Ich habe keine Ahnung was du in deiner Firma machst, solltest du der it-Experte in deinem unternehmen sein, Na dann viel Glück.
Meine Empfehlung:
- keine Ahnung was du für eine Internet Anbindung hast, einfach ein doofes Modem hin sollte es dsl sein, den Rechner weg, die sense direkt an dein Modem.
- OpenVPN auf deiner sense einrichten, und auf deinem Admin Rechner/Notebook das VPN einrichten und du hast vollen zugriff ohne irgendwelche Krücken auf dein Netzwerk.
- vnc ist bedingt sicher... meine Wahl VPN und auf die Kisten wo ich rauf musst entweder ssh oder rdp oder per webbrowser.
Gesendet von iPad mit Tapatalk Pro
Ok, wie vermutet nur SYN/ACK Pakete, gefolgt von ein paar Re-Transmits. Da wird keine Session aufgebaut.
Den Haken bei "Block private networks" auf dem WAN Interface, hast du aber schon rausgenommen oder?
ja der haken bei "Block private networks" ist schon längere zeit weg.
allerdings hab ich eine neue spur:
auf dem wan interface hab ich als gateway den noch einzigen gateway, den 172.16.0.2 ausgewählt.
wenn ich dort stattdessen auf auto stelle so funktioniert's plötzlich. die vnc verbindung vom wan ins lan1 wird aufgebaut.
allerdings, sobald ich den gateway auf auto stelle komm ich vom lan2 nicht mehr ins internet, also der findet dann offenbar den gateway nicht mehr.
obschon lan1 und lan2 eigentlich identisch konfiguriert sind funktioniert der internetzugang aus lan1 noch aber lan2 nicht mehr.
jetzt bin ich erst recht ratlos...
Könnte sein das noch Firewall regeln fehlen
Gesendet von iPad mit Tapatalk Pro
hm. was könnte da denn fehlen?
die beiden lans sind für's übliche identisch konfiguriert.
sobald ich beim wan den default gateway auf automatisch stelle (ist nur noch 1 gateway unter gateways konfiguriert) funktioniert lan1 nach wie vor problemlos und bei lan2 krieg ich zu beginn bloss noch gewisse... und dann plötzlich gar keine verbindungen mehr hin.
Komisch, irgendwie hast du da ein (asynchrones) Routing problem. Den (entfernten) Gateway gibst du nur auf dem WAN interface an, bei den LAN kannst du auf "auto" lassen. Kannst du mir noch Screenshots schicken von:
- System > Gateways > Single
- Firewall > NAT > Outbound
Was du noch versuchen kannst ist, bei deiner Port Forward Rule "NAT Reflection" zu aktivieren. Sollte aber eigentlich für Port Fwds bereits aktiv sein (die Einstellung ist unter Firewall > Settings > Advanced "Reflection for Port forwards".
Und immer schön in die Firewall Logs schauen, ob da was geblockt wird...
Das hört sich alles ganz schön komisch an.
Das ist ein absolut simpler Vorgang, den Du dort machen möchtest. Offenbar ist da an irgendeiner Stelle was ziemlich merkwürdig eingestellt. 2 Gateways?
So wie ich das sehe ist das doch so:
- Dein WAN Interface ist im LAN von Deinem Router, soweit nicht ungewöhnlich, scheinbar nutzt Du aber doppeltes NAT für Geräte hinter der OPNsense, kann man machen, ich finde doppeltes NAT immer schwierig
- Du möchtest aus dem Router-LAN per Port-Forward auf einen PC hinter der OPNsense
- das sollte per Port-Forward ohne große Probleme direkt funktionieren
Firewall-Regeln dafür sind ja auch mega simpel, vor allem wenn man beim Port-Forward ganz unten "Filter rule association" auf Standard lässt.
im anhang die screenshots.
bis vor einigen tagen hatte ich noch 2 gateways konfiguriert da der router (im bild router 1) ersetzt wurde und eine zeit lang 2 geräte parallel im einsatz waren. diese waren aber als single gateways definiert und im wan interface hab ich vom alten auf den neuen umgeschaltet. den alten router hab ich mittlerweile aus dem netz genommen und den entsprechenden gateway in opnsense gelöscht. bereits zuvor hatte ich im wan interface von gw1 auf gw2 umgeschaltet.
nachdem ich festgestellt hatte dass mein port forward vom wan ins lan1 nur funktioniert wenn ich im wan interface den gateway auf automatisch stelle hab ich mal alles was ich für's fehlersuchen beim port forwarding konfiguriert hatte (im port forward und ein paar routingregeln) wieder gelöscht um das nun sauber neu zu machen.
danach hab ich dann festgestellt dass ich vom lan2 nicht mehr ins internet komme, wogegen lan1 noch funktioniert hat.
nach einer stunde hat nun allerdings auch lan1 nicht mehr funktioniert.
sobald ich im wan den gateway wieder auswähle (nicht mehr auf auto) funktionieren beide lans wieder knitterfrei, dafür komm ich so natürlich vom wan wieder nicht mehr ins lan.
was wäre denn die korrekte einstellung im wan? den gateway auswählen oder automatisch?
könnte es allenfalls sein dass das ganze ein dns problem ist?
Ehrlich gesagt wird es so schwierig nachzuvollzihen, was an dieser Config schon alles angepasst worden ist. Die Config die du machen möchtest wie auch schon von Gauss33 angemerkt eigentlich ziemlich straight-forward.
Ich würde die opnsense nochmals komplett resetten und von vorne anfangen. Die Config hast du in 10-15min beisammen. Einfach den Wizard durchdrücken und den Port Forward plus Firewall Rul(s) einrichten.
na ja, so schnell ist ne neue config auch nicht erstellt da ich mit fixer ip/mac zuordnung arbeite und abende lang diese listen sowie alias für port gruppen und die einzelnen geräte im netz erstellt hab.
Quote from: bongo on November 11, 2020, 09:31:40 PM
was wäre denn die korrekte einstellung im wan? den gateway auswählen oder automatisch?
welche einstellung ist denn nun korrekt? muss ich in den einstellungen zum wan interface den gateway auswählen oder auf automatisch setzen?
port forwarding scheint nur zu funktionieren wenn ich auf automatisch bin und internetzugang bloss wenn ich den gateway auswähle.
möglicherweise hatte ich bloss eine fehlkonfiguration im port forward:
kann mir jemand erklären was die einstellung "Filter rule association" genau bedeutet?
wenn ich eine port forward regel erstelle so steht "Filter rule association" per default auf "add associated filter rule" was für mich irgendwie sinnvoll tönt. dabei wird dann automatisch für's wan interface eine regel erstellt.
mit dieser einstellung hatte ich nun tagelang erfolglos versucht, ein port forwarding hinzukriegen (was letztlich in der verzweiflung zu diesem thread geführt hat).
versuchsweise hab ich die einstellung für "Filter rule association" nun mal auf "pass" gestellt und schon gehen die pakete durch. ausserdem ist die automatisch erstellte filterregel im wan verschwunden.
ehrlich gesagt verstehe ich nicht, warum's so funktioniert und was genau der hintergrund dieser einstellung ist. in der dok habe ich nix dazu gefunden und im englischen forum fand ich bloss einträge dass bereits andere diese feststellung gemacht haben und offenbar auch nicht begriffen haben was diese einstellung bewirkt, jedoch blieben die fragen dort ubeantwortet.
daher nochmals konkret meine frage:
was bewirken die möglichen einstellungen für "Filter rule association" und ist es ok hier "pass" zu verwenden?
Also hast du es nun zum Laufen gekriegt? Wenn's mit "Pass" geht, dann stimmt vermutlich etwas an deinem Firewall Ruleset nicht, bin grad aber etwas unsicher...
Bei "Pass" macht opnsense intern eine art "Rule", die siehst du aber nirgends (mein Wissensstand). Würde ich jetzt nicht unbedingt empfehlen, funktioniert aber. Wenn du einmal eine Port-Fwd Rule mit "Pass" angelegt hast, kannst du das nachher nicht mehr ändern. Dann musst du die Rule neu anlegen oder duplizieren.
Die andere Option legt dir beim Erstellen der Port Forwarding Rule auch eine passende Firewall Rule an. Diese Rule wird dan assoziiert (verknüpft) mit deiner Forwarding Rule. Wenn die Forwarding Rule gelöscht wird, wird die FW-Rule auch gelöscht.
Bei "Add unassociated filter rule" wird auch eine Rule angelegt aber nicht verknüpft mit der Port-FWD Rule.
Ich kann dir sonst nur noch anbieten, mir das gesamte Backup-File deiner opnsense zu schicken, dann kann ich bei mir auf einer Testinstanz ein restore machen.
Übrigens: Betreffend neu aufsetzen: Wenn du ein Backup deiner opnsense machst und diese anschliessend zurückgesetzt, kannst du auch recht granular nur teile der Konfiguration wiederherstellen (siehe unter System > Configuration > Backups "Restore Area".
ist doch eigentlich komisch dass eine pass rule nirgends angezeigt wird, jedoch funktioniert, während eine associated rule nicht funktioniert.
wenn ich manuell rules anlege (mit oberster prio) welche von wan ins lan ebenso wie von lan ins wan zwischen diesen 2 geräten alles erlauben, so funktioniert's nach wie vor nicht. da diese regeln dann höchste prio haben sollte doch ein allfälliger fehler in weiteren regeln nicht zum tragen kommen, oder?
was mich bei den regeln irritiert ist, das dort eigentlich immer ein gateway mit der regel verknüpft ist.
mein verständnis ist, dass ich von 172.16.0.9 ein paket zur firewall sende (an interface 172.16.0.10) und dieses wird weitergereicht an den zielhost 192.168.1.20. dieser antwortet und schickt das paket zurück zur firewall welche dieses eigentlich an 172.16.0.9 senden sollte. da das paket nicht zu einem lan gehört wirds automatisch zum gateway 172.16.0.2 geschickt und nicht zum 172.16.0.9.
somit kann die verbindung nicht aufgebaut werden.
könnte da was dran sein?
Hat Router 1 in dem Bild überhaupt Routen für 10.1.1.x oder 192.168.1.x? Wenn nicht, ist das ganze Setup "borked" da asymmetrisch.
Quote from: JeGr on November 12, 2020, 05:01:55 PM
Hat Router 1 in dem Bild überhaupt Routen für 10.1.1.x oder 192.168.1.x? Wenn nicht, ist das ganze Setup "borked" da asymmetrisch.
Da er auf dem WAN Interface der OPNsense vermutlich NAT am Laufen hat, sollte der Router die Netze nicht kennen müssen. Wenn die sense kein NAT macht, müsste der Router sie natürlich kennen. Vielleicht ist das ein Ansatz. Ist NAT an der sense an oder aus für WAN?
hm.
also da opnsense nat macht sieht router1 doch die 192.168.1.x und 10.1.1.x garnicht sondern bloss das 172.16.0.x netz?
somit hat doch router1 gar nie mit 192.168.1.x und 10.1.1.x zu tun, oder?
wenn router1 auf seinem lan interface, also aus dem 172.16.0.x netz, pakete für 192.168.1.x oder 10.1.1.x kriegt, müsste er diese ja über's gleiche interface wieder zurückschicken. ist das zulässig? und wenn ja, wie sag ich's meinem router1?
Quote from: Gauss23 on November 12, 2020, 05:14:18 PM
Ist NAT an der sense an oder aus für WAN?
also ich bin immer davon ausgegangen dass da NAT eingeschaltet ist...
wo kann ich das denn ein/ausschalten?
Quote from: bongo on November 12, 2020, 05:16:44 PM
hm.
also da opnsense nat macht sieht router1 doch die 192.168.1.x und 10.1.1.x garnicht sondern bloss das 172.16.0.x netz?
somit hat doch router1 gar nie mit 192.168.1.x und 10.1.1.x zu tun, oder?
wenn router1 auf seinem lan interface, also aus dem 172.16.0.x netz, pakete für 192.168.1.x oder 10.1.1.x kriegt, müsste er diese ja über's gleiche interface wieder zurückschicken. ist das zulässig? und wenn ja, wie sag ich's meinem router1?
Auf Router 1 müsste dann eine statische Route eingetragen werden mit GW WAN-IP der Sense. Alternativ kannst Du die statische Route auch direkt auf dem Client im WAN anlegen.
Poste doch mal Deine Outbound-NAT Regeln.
im anhang wie gewünscht ein screenshot der nat outbound rules der opnsense (ist immer noch auf automatisch, wie ich's gestern gepostet hab).
und ausserdem die static route maske von router1. mir ist nicht ganz klar wie ich dieses feld nun ausfüllen muss...und ob das wirklich notwendig ist falls die opnsense nat macht (weiss nach wie vor nicht wie ich sehe ob bei opnsense nat wirklich eingeschaltet ist).