Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - fenjaw

#1
Die Seite braucht vermutlich beim ersten Laden sehr lange, ist dann aber schlagartig da?
Das wäre ein Indiz für ein DNS-Problem. Vielleicht antwortet dein DNS nicht - und der Client springt dann auf sekundären DNS um.

Verteilst du mehrere DNS-Server?
Teste auf dem Client mal mit nslookup.
#2
Hi,

der Haken ist nicht aktiviert.
Du hast recht, wenn ich den Haken setze dann kann ich aus dem 192.168.100.0/24-Netz auf das Mail Gateway zugreifen.
telnet 192.168.100.32 25 geht dann durch.

Das Grundproblem war an der Stelle, dass mein Portforwarding aus dem Internet nicht funktioniert hat, darum der Test mit einer Maschine im 100er Netz.
Auf dem Lancom habe ich halt ein Port-Forwarding auf die 192.168.100.32 eingerichtet. Leider kann man bei dem Lancom nicht, wie bei Fritzbox, mit nem Exposed Host arbeiten, entsprechend habe ich dort die Regeln identisch eingerichtet, was vorher (vor der Umstellung auf die Opensense) auch problemlos funktioniert hat.
Muss ich in diesem Fall (2 Portforwarding "hintereinander") irgendwelche besonderen Einstellungen tätigen?
Oder würde es gar Sinn machen dem Lancom dort die 192.168.0.0/24 und die 192.168.2.0/24 als Routing mitzugeben und direkt auf diese zu forwarden (und dann "nur" mit Firewallregeln zu arbeiten, die diesen Zugriff erlauben?)
#3
Hi Patrick,

danke für deine Antwort!

"Blockiere private Netze" sowie "Blockiere Bogon-Netze" sind nicht aktiviert.
"Antwort-An" unter Firewall->Erweitert ist ebenfalls nicht aktiviert.
#4
Hallo,

ich habe hier ein Problem, mit dem ich nicht weiter komme - und das mich etwas irritiert.
Ich habe eine OpnSense mit mehreren WAN - Auf WAN 1 habe ich mehrere Portforwardings eingerichtet, die Problemlos funktionieren.
Zusätzlich zu der Glasfaser habe ich noch eine DSL Fallback, dort wollte ich nun ebenfalls die Portforwardings einrichten.
DSL läuft dort über einen zusätzlichen Router, d.h. ich habe dort das Netzwerk 192.168.100.0/24, die Opnsense bekommt dort per DHCP die IP 192.168.100.32.

Dazu habe ich die vorhandenen Regeln gespiegelt:
You cannot view this attachment.

Die dazugehörigen Regeln hat OpnSense automatisch erstellt.
You cannot view this attachment.

Ich hatte nun einen Rechner ins 192.168.100 Netz gebracht und von dort aus versucht, die Portforwardings zu testen, bekomme aber dort mit "telnet 192.168.100.32 25" einen Timeout.
Auch Ping funktioniert, trotz aktiviertem erlaubtem ICMP in den FW-Regeln, nicht.

Kann mich dort jemand unterstützen?
#5
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.
#6
German - Deutsch / Probleme mit Portforwarding
May 19, 2025, 08:30:32 PM
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.