Web-GUI schickt Pakete auf falschem Interface raus

[knebb]

Moin,

hier ist ein Multi-WAN setup. Einmal Glasfaser (feste IPv4) , einmal T-DSL (dynamische IPv4).

Ich möchte meine Web-GUI der OPNSense vom Internet erreichbar machen. Via https:// auf Port 8443. Einstellungen unter "System -> Einstellungen -> Verwaltung" im Screenshot (siehe Anlage1). Alle Schnittstellen sind aktiviert.

Auf der DSL-Adresse ($DSLIP) funktioniert das auch einwandfrei, aber auf der Glasfaser-IP ($GFIP) funktioniert es nicht. Ich bekomme dort keine Antwort.

Die Regeln auf beiden Interfaces sind identisch gesetzt (sieheScreenshots 2+3)

Gehe ich auf die Konsole der OPNSense sehe ich auch, dass auf allen Interfaces tatsächlich ein Prozess "lauscht":

Code: [Select]

root@opnsense:~ # sockstat -4 -l | grep 8443
root     lighttpd   52359 7  tcp4   *:8443                *:*

Dennoch ist der Port nicht offen:

Code: [Select]

root@inetpc:~# nmap $GFIP -p8443
Starting Nmap 7.93 ( https://nmap.org ) at 2023-12-04 10:46 CET
Nmap scan report for $GFIP
Host is up (0.026s latency).

PORT     STATE    SERVICE
8443/tcp filtered https-alt

Nmap done: 1 IP address (1 host up) scanned in 0.92 seconds

Auf $DSLIP sieht das dagegen gut aus:

Code: [Select]

root@inetpc:~# nmap $DSLIP -p 8443
Starting Nmap 7.93 ( https://nmap.org ) at 2023-12-04 10:47 CET
Nmap scan report for host.dip0.t-ipconnect.de ($DSLIP)
Host is up (0.020s latency).

PORT     STATE SERVICE
8443/tcp open  https-alt

Nmap done: 1 IP address (1 host up) scanned in 0.26 seconds

Mache ich ein Packettrace auf der $GFIP sehe ich die eingehenden Pakete, aber die ausgehenden Antwortpakete gehen über die $DSLIP mit der Absender-IP von $GFIP raus.:

Code: [Select]

  View capture
Schnittstelle Zeitstempel SRC DST output
ROTDSLDIREKT pppoe0 2023-12-04 10:50:35.769841 length 48: $GFIP.8443 > $INETPC.37505: tcp 0
ROTDSLDIREKT pppoe0 2023-12-04 10:50:35.942055 length 48: $GFIP.8443 > $INETPC.37507: tcp 0
ROTDSLDIREKT pppoe0 2023-12-04 10:50:37.984069 length 48: $GFIP.8443 > $INETPC.37505: tcp 0
ROT igc1 2023-12-04 10:50:34.751383 84:b8:02:e2:1d:40 dc:58:bc:e0:5c:60 IPv4, length 60: $INETPC.37505 > $GFIP.8443: tcp 0
ROT igc1 2023-12-04 10:50:34.879659 84:b8:02:e2:1d:40 dc:58:bc:e0:5c:60 IPv4, length 60: $INETPC.37507 > $GFIP.8443: tcp 0

Er schickt also ein Paket mit einer anderen Absender-IP über das $DSLIP Interface raus. Das wird dann vermutlich bei der Telekom irgendwie geblockt. Richtigerweise.

Ergänzung: Deaktiviere ich das Interface mit der$DSLIP, funktioniert es einwandfrei über $GFIP.

Ideen, woran das liegt?

/KNEBB

[chrs]

Das könnte an der Firewall Regel liegen, die den Zugang WAN in erlaubt, da gibt es unten bei advanced eine option reply-to oder so ähnlich, da könnte es bei Multi WAN Probleme geben, daß da das richtige Gateway steht, falls nicht default ausgehend verwendet werden soll.

Grüße, chris

[knebb]

Moin,

danke für den Hinweis, aber das steht auf dem normalen Wert, sollte auch funktionieren.

Komischerweise habe ich nochmal versucht das nachzustellen und es hat diesmal funktioniert! Ich hatte die Tage wenig Zeit, habe also sicher nichts geändert. Aber jetzt geht es.,

Frag' mich nicht, was das war

/KNEBB