OPNsense Forum
International Forums => German - Deutsch => Topic started by: Horst on January 13, 2021, 09:52:26 am
-
Hallo - lese schon lange mit - hat auch viel geholfen , aber leider finde ich diesmal keine Lösung daher mein post.
Ausgangsituation:
1 Stock:
WAN 1 - Router IP 192.168.1.1 - GFI Hardware FW mit Gateway 1.1 dahinter lokales LAN 192.168.0.xxx bis 100.
2 Stock:
WAN 2 - Router IP 192.168.1.101 - OPNsense FW mit Gateway 1.101 dahinter loakales LAN 192.168.0.102 bis 200.
Alles statisch - kein DHCP- beide Netze sind in unterschiedlichen Stockwerken mit jeweils 8 - 9 User, halt ganz einfach gehalten ohne VLAN etc.
Im 1 Stock gibt es einen Ipsec VPN server in der FW integriert alle Clients erhalten die IP 192.168.3.x und haben Zugriff in Lan ( geht problemlos ) und ich verwende auch über VPN RDP Microsoft habe damit Zugriff auf alle PC im 1 Stock.
Bis jetzt waren die beide Netze nicht verbunden und ich habe zum testen mal 2 Switches mit einander verbunden , ( ja ja ) somit habe ich auf alle Clients einen Zugriff vom LAN aus, Wenn ich per 'Ipsec und VPN auf die Clients hinter der Opnsense verbinden will geht es nicht ( da die Opnsense die IP vom Ipsec 192.168.3.x anscheinend im Lan blockt.
Anbei Screenshot -
Leider komme ich mit den LAnregeln noch nicht ganz klar - hab schon verschiedene Rules versucht - leider keine Chance, wie gesagt noobie.
Danke
-
Hallo - lese schon lange mit - hat auch viel geholfen , aber leider finde ich diesmal keine Lösung daher mein post.
Ausgangsituation:
1 Stock:
WAN 1 - Router IP 192.168.1.1 - GFI Hardware FW mit Gateway 1.1 dahinter lokales LAN 192.168.0.xxx bis 100.
2 Stock:
WAN 2 - Router IP 192.168.1.101 - OPNsense FW mit Gateway 1.101 dahinter loakales LAN 192.168.0.102 bis 200.
Sehe ich das richtig das beide Stockwerke das gleiche Netz verwenden (.1.0/24)
Warum?
Zu deinem Problem, ich verstehe es so das deine Sense das .3.0 netz nicht kennt
Kannst du bitte für mich noch einen grafischen netzwerkplan erstellen, das hilft mir dein Netz besser zu verstehen
Gesendet von iPhone mit Tapatalk Pro
-
Ja, bin halt einfach gestrickt , beide LANS verwenden das selbe LAN 192.168.0.X/24 , was ja problemlos klappt da alles statisch.
Da wir versuchen , langsam weg von GFI zu gehen und einfach auf opnsense umstellen wollen, mit meinem Versuch geht das so recht einfach mit Gateway ändern und passt.
Ja es ist mir klar das das ein ganz simples Problem mit den LAN Regeln ist , aber ich schaff es einfach nicht über IPSEC mit RDP ins ganze LAN zukommen. IM LAn vorort gehts eh problemlos.
( Opnsense Rules sind echt ungewohnt nach 15 Jahren Wingate ,Winroute,GFI
Danke
Achtung: Hab vergessen zu erwähnen das ich bei meinen eigenen PC im 1 Stock mit der IP 192.168.0.68 den Gatway geändert habe auf die opnsense um es einfacher zu testen !!
-
Hmm, ich raffs einfach nicht mit den rules
Eigentlich will ich da ich ja übers LAN 192.168.0.X komme und im meinem Fall durchs VPN eine 192.168.3.X IP habe , wäre es für mich logisch einfach eine Regel im Lan auf der Opnsense zu erstellen mit ( IN Source 192.168.3.1 und Ziel zB. 192.168.0.68 any any ).
Aber warum geht das nicht ? Komme immer zum selben Ergebnis - blocked by default
-
Hallo
Jemand einen TIP ? lese mich eh selber ein - komme aber überhaupt nicht weiter ..
DANKE DANKE
-
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-.
-
Hi Zoki
Danke für deine Hilfe , hatte die Regel mit 192.168.3.11 nach 192.68.0.68 drinnen , trotzdem...
Welches Bild meinst du ?
-
immer das selbe , egal was ich in den Lan rules freigebe , auch mit any any etc immer das selbe
Anbei screenshot
-
Das interessante ist, dass der Antwort-Traffic geblockt wird. Als würde aus irgendeinem Grund keine „State“ gespeichert werden.
Was hast du in der Regel unter Advanced/State type in der ersten Regel, die den RDP Traffic zulässt?
-
moment
Da habe ich gar nichts drinnen, habs mir gerade angesehen - keine Ahnung was ich da eintragen müsste
-
„State type“ sollte auf „keep state“ stehen.
-
hmm , war eingestellt - selbes Ergebnis - geht nicht ..
-
Ich tippe auf die Windows Firewall auf dem RDP Host, die den Traffic nicht zulässt. Ist diese deaktiviert?
-
Nein , komplett aus
-
Jetzt verstehe ich warum es nicht geht: das Paket nimmt folgenden Weg:
FW-IPsec-Server->RDP-Host
Das Antwortpaket geht aber:
RDP-Host -> OPNsense (die verwirft das Paket, da es kein korrespondierendes Anfragepaket gab)
Das Antwortpaket muss aber den selben Weg nehmen, den es hergekommen ist. Tut es in dem Falle aber nicht mehr.
Es liegt an Deiner - mit Verlaub - etwas unglücklichen Doppel-GW Lösung bzw dieses merkwürdig geteilte /24er Netz. Bau es um, dann läuft es.
-
Hi Gauss23
dake für deine Info , Problem ist alles umzuändern auf ein andere Lan wird eine Menge Arbeit. Was ich nicht verstehe das es wenn ich das ganze lokal mache - problemlos funktioniert.
Shit , trotzdem danke - sollte dir noch ein wenig einfacherer Weg einfallen wäre das super.
( Bin mit GFI Firewall sattelfest aber mit opnsense - voller noob )
-
Hi Gauss23
dake für deine Info , Problem ist alles umzuändern auf ein andere Lan wird eine Menge Arbeit. Was ich nicht verstehe das es wenn ich das ganze lokal mache - problemlos funktioniert.
Shit , trotzdem danke - sollte dir noch ein wenig einfacherer Weg einfallen wäre das super.
( Bin mit GFI Firewall sattelfest aber mit opnsense - voller noob )
Es würde ja schon reichen auf der OPNsense einen eigenen IPsec-Road-Warrior-Zugang einzurichten und dann darüber von außen zu testen. Dann sollte RDP problemlos laufen. Du kannst natürlich auch OpenVPN oder WireGuard nehmen. Um die alte Firewall abzulösen, müsstest Du ja ohnehin einen VPN Zugang auf der Box einrichten.
-
Es liegt an Deiner - mit Verlaub - etwas unglücklichen Doppel-GW Lösung bzw dieses merkwürdig geteilte /24er Netz. Bau es um, dann läuft es.
Asymmetrisches Routing ist immer ein Problemkind. Man könnte es nur lösen wenn man beim Schritt:
FW-IPsec-Server->RDP-Host
dem FW-IPsec-Server irgendwie outbound verklickert, dass er NATten soll, damit die RDP Session beim RDP Host nicht mit der echten IP ankommt (die er dann problematisch an die Sense schickt), sondern mit der IP des IPsec Servers, damit er die Antworten da wieder hin zurück schickt. Ist aber krude und eher nicht so schick. Netz sauber aufziehen ohne Asymmetrie im Routing macht es wesentlich besser. :)
-
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.
-
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.
Ich glaube Du bist im falschen Beitrag gelandet :)