zugriff von LAN B auf LAN A erlauben

[bongo]

ich habe 2 LANs welche über's WAN ins internet gehen.
im LAN A laufen mehrere webserver welche intern von rechnern im LAN A verwendet werden.
einzelne rechner im LAN B sollen nun auch zugriff auf diese webserver erhalten. dabei ist es für mich egal, welche IP oder welchen port ich dabei verwenden muss, wichtig ist einfach dass ich letztlich vom LAN B aus auf port 80 dieser server zugreife.
wie muss ich das konfigurieren?

LAN A: 192.168.1.0
LAN B: 10.1.1.0

interfaces von OPNSense:
LAN A: 192.168.1.100
LAN B: 10.1.1.100
WAN: 172.16.0.10

einer der webserver: 192.168.1.211

vielen dank!

[chemlud]

- KEINE allow any-any rule auf LAN B

- Regel auf LAN B: Allow ipv4 TCP from 10.1.1.x to 192.168.1.211 target port 80

dann sollte der client 10.1.1.x auf den server surfen können...

[bongo]

hm. denke eigentlich dass ich das so gemacht hab.
wenn ich als oberste regel im LAN B drin hab dass der client im LAN B auf den webserver im LAN A port 80 zugreifen darf, so sehe ich dort mit inspect dass states, packets und bytes zählt. allerdings erhalte ich dann keine antwort vom webserver (timeout im browser).

denke entweder werden die pakete nicht zum webserver geschickt sondern anderswo hin (z.b. aufs wan) oder der rückpfad funktioniert nicht.
wie soll ich vorgehen?

vielen dank!

[chemlud]

- Regeln auf LAN b hier posten

- package capture auf LAN A und nachsehen ;-)

[bongo]

und schon wieder was gelernt, vielen dank!

hab den test nun laufen lassen mit client 10.1.1.132 und server 192.168.1.208.

beim capturen auf lan a sehe ich:
19:40:29.146226 IP 10.1.1.132.48139 > 192.168.1.208.80: tcp 0

ich würde nun eigentlich erwarten dass ich auch pakete der gegenrichtung sehen würde, doch da kommt nix.
würde für mich eigentlich drauf hindeuten dass 192.168.1.208 keine antwort gibt. wenn ich aber von einem host im 192.168.1.0 er netz  im browser 192.168.1.208 aufrufe so erhalte ich die webseite angezeigt.

[chemlud]

ggf. antwortet dein server nicht auf private ips, die nicht in seinem netzwerk liegen?

[bongo]

könnte durchaus sein. wenn ich mich nicht irre läuft da apache auf einem raspberry pi. offenbar haben andere änliche probleme mit apache, jedoch hab ich bislang nirgends eine brauchbare antwort gefunden, bloss meinen alle dass das nicht an apache liegen kann.

hab nun parallel eine regel erstellt für icmp und pinge den server an. da hab ich das gleiche bild. ich capture bloss pakete vom client zum server aber nix in der gegenrichtung. (wenn ich den server aus seinem eigenen subnetz anpinge so antwortet er)

das problem müsste somit wohl beim raspberry generell liegen und nicht beim webserver der drauf läuft, oder?

mit meinem bisherigen setup (eine alte lösung von kerio) wurde auf dem router mittels nat die source adresse so umgesetzt dass sie zum subnetz passte. wär dies auf opnsense auch möglich?

[bongo]

mein obiger versuch hinkt wohl. hab nun noch eine regel erstellt zum pingen eines windows rechners im 192er netz (vom 10er aus) und sehe da im 192er auch bloss icmp pakete ankommen aber keine die zurück gehen ins 10er netz.
sieht aus als würd ich mich immer mehr verstricken und entferne mich immer weiter von einer lösung. ;-(

gibt's als alternative (oder weiterer versuch) die möglichkeit die sache zu nat-en?

[Gauss23]

mein obiger versuch hinkt wohl. hab nun noch eine regel erstellt zum pingen eines windows rechners im 192er netz (vom 10er aus) und sehe da im 192er auch bloss icmp pakete ankommen aber keine die zurück gehen ins 10er netz.
sieht aus als würd ich mich immer mehr verstricken und entferne mich immer weiter von einer lösung. ;-(

gibt's als alternative (oder weiterer versuch) die möglichkeit die sache zu nat-en?

Windows Firewall aktiv? Im Normalfall antwortet Windows nicht auf Pings außerhalb des eigenen Subnetzes.

Hast Du evtl auf einem der LAN Interfaces die Option: "Block Private Networks" aktiviert?

[bongo]

das wär dann wohl die erklärung warum's mit windows nicht funktioniert. an der windows firewall hab ich nix rumgeschraubt und möchte das eigentlich auch unterlassen da dies bloss ein versuch war...

könnte nun natürlich sein dass das raspi auch sowas hat. somit ein grund mehr eine lösung zu suchen mit nat. hierbei bin ich allerdings auch gescheitert - ganz klar als folge meiner unkenntnis.

auf opnsense ist "block private networks" bloss auf dem wan aktiviert. nehme an dort ist's ok?

bei der alten kerio lösung hatte ich auf dem "firewall interface lan b" den port 8001 welcher umgesetzt wurde zu "firewall interface lan a" und dann an die ip des raspi mit port 80 gesendet wurde.
nach so einer lösung hab ich eigentlich gesucht, aber bislang nicht rausgefunden wie ich das machen muss.

[Gauss23]

Intern zu natten ist irgendwie ein absoluter Notbehelf und sollte vermieden werden.

Ist die OPNsense für beide LANs das default gateway?

[bongo]

BINGO!

offenbar hat das raspi den wechsel des default gateway vor ein paar wochen unbeschadet überstanden.

liefert capture denn nicht allen traffic auf dem jeweiligen netz sondern bloss denjenigen welcher über opnsense läuft?

sieht so aus als hätte das raspi seine antwort an eine falsche ip gesendet. nach einem reboot scheint's knitterfrei zu funktionieren.

VIELEN DANK FÜR DIE HILFE!!!!

[Gauss23]

liefert capture denn nicht allen traffic auf dem jeweiligen netz sondern bloss denjenigen welcher über opnsense läuft?

Ja, nur der Traffic, den OPNsense zu sehen bekommt. Man kann Netzwerkschnittstellen auch in den "promiscuous mode" versetzen, dann würde jeglicher Verkehr auf diesem Netzwerk auch von der OPNsense gesehen werden.