Grüß euch,
ich verzweifele gerade etwas mit einem Portforwarding, vielleicht kann mir dort jemand unter die Arme greifen?
Wir haben ein etwas komplizierteres Konstrukt:
Ich hab aktuell 4 WAN Netzwerke, wovon 2 "richtige" WAN-Verbindungen sind und 2 sind VPN-Verbindungen, die uns zur Verfügung gestellt werden (die müssen wir nutzen).
LAN1 = 192.168.0.0/23 (interface vtnet1)
LAN2 = 192.168.2.0/24 (interface vtnet2)
WAN1 = 156.67.X.X (Statische IP) (interface vtnet3)
WAN2 = 192.168.100.199 (statische IP im 192.168.100.0/24 Netz) (interface vtnet4)
WAN3VPN1 = 10.204.103.97 (DHCP) (interface vtnet5)
WAN4VPN2 = 217.237.214.129 (Statisch) interface vtnet6)
Die beiden VPN-Geschichten sind "Blackboxen" die wir so gestellt kriegen - d.h. dort haben wir keine Administrationsgewalt.
Da viele Clients aus dem LAN1-Bereich auf beide Inhalte zugreifen müssen und wir das Routing gerne zentral lösen hatten wir das vor einigen Jahren genau so wie es jetzt ist schon mit nem LANCOM-Router aufgebaut, der jetzt aber aus dem Support gelaufen ist - darum nun die Umrüstung auf OpnSense.
LAN2 geht an den WAN-Eingang einer Fortigate-Firewall, deren LAN-Anschluss geht dann an WAN3 unserer Opnsense.
Das Routing dort klappt auch alles, ich hab soweit Zugriff auf alles was ich brauche.
Allerdings kommen die benötigten Rückmeldungen nicht rein.
In dem Portal für die Rückmeldungen kann ich die IP-Adresse meines Routers angeben, in diesem Fall also die 10.204.103.97.
Dann soll ich ein Portforwarding in der Firewall erstellen:
WAN3 => Port 6700, 8080 => 192.168.0.20 (in LAN1)
Testweise, weil es nicht funktioniert hat, habe ich in das 10.204.103.97 Netz eine VM reingesetzt mit der ich verschiedene Portscans auf 10.204.103.97 durchgeführt habe - Port 6700 und 8080 bleiben geschlossen.
Ich habe die Regeln angelegt und es wurden auch automatisch die passenden Firewall Regeln gesetzt.
Nmap von 10.204.103.117 auf 10.204.103.97 zeigen aber an, dass sowohl der Port 6700 als auch der Port 22 (den ich Testweise geöffnet habe um dort einen Fehler auszuschließen) nicht geöffnet werden.
SSH und Telnet auf die Ports 6700 / 22 bleiben im Timeout.
Alle anderen Portforwardings auf den normalen WAN-Ports funktionieren tadellos.
Quote from: fenjaw on May 19, 2025, 08:30:32 PMIn dem Portal für die Rückmeldungen kann ich die IP-Adresse meines Routers angeben, in diesem Fall also die 10.204.103.97.
Für was steht da "Rückmeldungen"? Kann mir darunter nichts vorstellen.
QuoteDann soll ich ein Portforwarding in der Firewall erstellen:
WAN3 => Port 6700, 8080 => 192.168.0.20 (in LAN1)
Den Port 8080 hast du aber nicht realisiert.
QuoteNmap von 10.204.103.117 auf 10.204.103.97 zeigen aber an, dass sowohl der Port 6700 als auch der Port 22 (den ich Testweise geöffnet habe um dort einen Fehler auszuschließen) nicht geöffnet werden.
Für den "Offen" Status ist auch der Zielhost entscheidend. Der Router leitet die Anfragen nur weiter, wenn der Zielhost nicht antwortet, wird der Port als geschlossen erkannt, trotz Firewall Pass-Regel.
Wenn das mit einem früheren Router so funktioniert hat, könnte der Masquerading gemacht haben (S-NAT auf die LAN Adresse). Das ginge mit Outbound NAT.
Welche Quellen-Adressen soll von der Fortigate reinkommen? Öffentliche oder ein bestimmtes privates Subnetz?
Moin!
Danke dir für die Antwort :)
QuoteFür was steht da "Rückmeldungen"? Kann mir darunter nichts vorstellen.
Da geht's u.a. um Automatisches Meldewesen. Wir senden dort automatisch Tagesberichte und bekommen dann eben in unser Programm Rückmeldungen übermittelt, die wir als Nachweis benötigen das wir unsere Pflicht das zu übermitteln getan haben.
QuoteDen Port 8080 hast du aber nicht realisiert.
Stimmt - das hatte ich, nachdem es nicht funktioniert hatte, erst wieder gelöscht.
Ich hatte nen Alias auf 6700 und 8080 erstellt, das aber dann zu Testzwecken wieder rausgenommen.
QuoteFür den "Offen" Status ist auch der Zielhost entscheidend.
Der Antwortet.
Mache ich im LAN1 telnet 192.168.0.20 6700 bekomme ich eine Verbindung.
Mache ich dies aus meiner Test-VM telnet 10.204.103.97 6700 bekomme ich Timeout.
QuoteWelche Quellen-Adressen soll von der Fortigate reinkommen? Öffentliche oder ein bestimmtes privates Subnetz?
Alles aus 10.0.0.0/8
QuoteWenn das mit einem früheren Router so funktioniert hat, könnte der Masquerading gemacht haben (S-NAT auf die LAN Adresse). Das ginge mit Outbound NAT.
Das sagt mir leider nichts - könnte das als N:N-Adress-Mapping bezeichnet worden sein?
Die Tabelle ist leer.
Quote from: fenjaw on May 19, 2025, 10:27:47 PMMache ich im LAN1 telnet 192.168.0.20 6700 bekomme ich eine Verbindung.
Das sagt nicht allzu viel. Versuche es aus dem LAN2.
Klappt es da nicht, erhärtet sich der Verdacht, dass der frühere Router den Traffic genattet hat. Das sollte aber gar nicht nötig sein, wenn du den Zielhost so konfigurierst, dass er Verbindungen von außerhalb seines eigenen Subnetzes akzeptiert.
Kannst du den Traffic von der VPN selbst triggern?
Das wäre hilfreich beim Troubleshooting. So könntest du mit Packet Capture schauen, ob der Traffic am richtigen internen Interface raus geht und ob Antworten zurück kommen. Zumindest eines davon tut vermutlich nicht.