pfSense NAT zum Server in einem zweiten LAN-Subnetz hinter einem internen zweiten Router (funktioniert nicht)

pfSense NAT zum Server in einem zweiten LAN-Subnetz hinter einem internen zweiten Router (funktioniert nicht)

Ich habe eine/n pfSense-Firewall/Router, der/die einige Dienste meiner öffentlichen IP zugänglich macht.

Dies funktioniert einwandfrei, solange sich der Dienst im primären LAN-Subnetz ( 192.168.1.0/24) befindet. Nennen wir ihnLAN-A.

Beispielsweise funktioniert das hier:

public_ip:443 -> pfSense (NAT) -> 192.168.1.20:5443 (reverse proxy)

Ich habe zusätzlich ein zweites LAN 192.168.88.0/24, nennen wir esLAN-B, das ist hinter einemMikrotikRouter an 192.168.1.111. In pfSense habe ich eine statische Route für das Netzwerk, die ich als Gateway dafür 192.168.88.0/24angebe .192.168.1.111

AusLAN-AIch kann mich jetzt mit Hosts in verbindenLAN-B, zB 192.168.88.10transparent, das gleiche wie für Hosts inLAN-A(abgesehen von einem seltsamen Problem mitssh hier erwähnt, immer noch ungelöst). (Gastgeber aufLAN-Bkann auch normal eine Verbindung zum Internet herstellen, da dieMikrotikDer Router gibt die pfSenseBox 192.168.1.1als Gateway für seine Clients an).

So weit, so gut. Aber jetzt möchte ich einen Dienst vorstellen aufLAN-B, sagen wir 192.168.88.10:10000über NAT auf meiner externen IP. Also mache ich dasselbe wie immer:

public_ip:10000 -> pfSense (NAT+Rule) -> 192.168.88.10:10000

Dies funktioniert jedoch nicht (und nmapvon außen wird der Port als angezeigt filtered, wo im LAN er sich befindet open). Scheint es also so, als ob die NAT-Logik meine statische Route nicht kennt?

Das erscheint irgendwie logisch, da die statische Route im Bereich meiner lokalen Schnittstelle ( LANBRIDGE) von pfSense „lebt“ und die Firewall (NAT) zwischen WANund liegt LANBRIDGE, also weiß sie wahrscheinlich nicht, dass die Verbindung zu 192.168.88.0/24durchgeht 192.168.1.111. Aber wie lässt sich das zum Laufen bringen?

Antwort1

Habe das Problem gefunden (für spätere Bezugnahme und hilft möglicherweise anderen):

Der beschriebene Aufbau (OP) ist nebenbei ok pfSense.

Das Problem war, dass dieMikrotikDer Router sollte die tatsächlichen Quelladressen (also diejenigen, die mit der externen IP verbunden sind) weiterleiten (Weiterleitungskette), also 0.0.0.0/0nicht nur Adressen 192.168.1.0/24. Aus Sicherheitsgründen kann die Weiterleitungsregel bei Bedarf auf bestimmte Ports beschränkt werden.

verwandte Informationen