Hallo zusammen,
ich habe bereits im Forum gesucht, aber leider nichts gefunden, das mein Problem lösen könnte.
Mein setup ist wie folgt:
fritzbox: intern 192.168.9.254, exposed host auf 192.168.9.1
opnsense CARP WAN IP 192.168.9.1
opnsense CARP DMZ IP 10.66.6.1
ftp server 10.66.6.3
meine port forward regel auf der opnsense sieht wie folgt aus:
interface: WAN
destination: 192.168.9.1 (CARP WAN IP)
destination port range: FTP
redirected target: 10.66.6.3
redirected target port: FTP
leider kommt am FTP server kein Paket an.
wenn ich den ftp server testweise ins netz zwischen fritz und opnsense hänge (192.168.9.3) und auf der fritz den exposed host auf 192.168.9.3 stelle, funktioniert alles, also funktioniert das forwarding auf der fritz.
ich habe auch auf dem wan interface die beiden Haken für "Block private networks" und "Block bogon networks" rausgenommen, da wir ja auf beiden Seiten des opnsense clusters RFC1918 Adressen haben.
bis jetzt leider erfolglos.
Hat jemand einen Tipp?
salü
.h
Wie sieht denn die Firewall rule association bei der Port Forward Regel aus?
Steht auf Rule, die erzeugte Regel sieht so aus:
source: *
port: 21 (FTP)
destination: 10.66.6.3
gateway: *
ich hatte vorher ein palo cluster, wenn das das versuchsweise wieder anschließe, geht alles. daher gehe ich davon aus, dass ich irgendwelche regeln falsch habe.
Ping zwischen OPNsense und Fritzbox tut?
Ping zwischen OPNsense und FTP-Server tut?
tcpdump auf WAN, von außen (anderer Internet-Uplink) telnet auf port 21 der Fritzbox extern - was passiert da?
tcpdump auf DMZ, identischer Test
Mehr Ideen hab ich spontan auch nicht. Nachsehen, was genau passiert ...
> Ping zwischen OPNsense und Fritzbox tut?
root@OPNsense1:~ # ping 192.168.9.254
PING 192.168.9.254 (192.168.9.254): 56 data bytes
64 bytes from 192.168.9.254: icmp_seq=0 ttl=64 time=0.835 ms
64 bytes from 192.168.9.254: icmp_seq=1 ttl=64 time=0.454 ms
64 bytes from 192.168.9.254: icmp_seq=2 ttl=64 time=0.496 ms
^C
--- 192.168.9.254 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.454/0.595/0.835/0.170 ms
> Ping zwischen OPNsense und FTP-Server tut?
root@OPNsense1:~ # ping 10.66.6.3
PING 10.66.6.3 (10.66.6.3): 56 data bytes
64 bytes from 10.66.6.3: icmp_seq=0 ttl=64 time=0.212 ms
64 bytes from 10.66.6.3: icmp_seq=1 ttl=64 time=0.168 ms
64 bytes from 10.66.6.3: icmp_seq=2 ttl=64 time=0.131 ms
^C
--- 10.66.6.3 ping statistics ---
3 packets transmitted, 3 packets received, 0.0% packet loss
> tcpdump auf WAN, von außen (anderer Internet-Uplink) telnet auf port 21 der Fritzbox extern - was passiert da?
root@OPNsense1:~ # tcpdump -i igb0 -n src host 138.201.203.161 and port 21
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igb0, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:18:25.956683 IP 138.201.203.161.57130 > 192.168.9.1.21: Flags [S], seq 244047560, win 64240, options [mss 1452,sackOK,TS val 1555108628 ecr 0,nop,wscale 7], length 0
15:18:26.964121 IP 138.201.203.161.57130 > 192.168.9.1.21: Flags [S], seq 244047560, win 64240, options [mss 1452,sackOK,TS val 1555109636 ecr 0,nop,wscale 7], length 0
15:18:27.989240 IP 138.201.203.161.57130 > 192.168.9.1.21: Flags [S], seq 244047560, win 64240, options [mss 1452,sackOK,TS val 1555110661 ecr 0,nop,wscale 7], length 0
15:18:29.012121 IP 138.201.203.161.57130 > 192.168.9.1.21: Flags [S], seq 244047560, win 64240, options [mss 1452,sackOK,TS val 1555111684 ecr 0,nop,wscale 7], length 0
15:18:30.036261 IP 138.201.203.161.57130 > 192.168.9.1.21: Flags [S], seq 244047560, win 64240, options [mss 1452,sackOK,TS val 1555112708 ecr 0,nop,wscale 7], length 0
15:18:31.059908 IP 138.201.203.161.57130 > 192.168.9.1.21: Flags [S], seq 244047560, win 64240, options [mss 1452,sackOK,TS val 1555113732 ecr 0,nop,wscale 7], length 0
15:18:33.108272 IP 138.201.203.161.57130 > 192.168.9.1.21: Flags [S], seq 244047560, win 64240, options [mss 1452,sackOK,TS val 1555115780 ecr 0,nop,wscale 7], length 0
15:18:33.853538 IP 138.201.203.161.21 > 192.168.9.1.48521: Flags [S.], seq 1226605640, ack 1865754026, win 65160, options [mss 1460,sackOK,TS val 1679405380 ecr 4223778784,nop,wscale 7], length 0
15:18:33.956501 IP 138.201.203.161.21 > 192.168.9.1.48521: Flags [P.], seq 1:49, ack 1, win 510, options [nop,nop,TS val 1679405483 ecr 4223778810], length 48: FTP: 220 ProFTPD Server (ProFTPD) [138.201.203.161]
15:18:34.013135 IP 138.201.203.161.21 > 192.168.9.1.48521: Flags [.], ack 7, win 510, options [nop,nop,TS val 1679405540 ecr 4223778913], length 0
15:18:34.013152 IP 138.201.203.161.21 > 192.168.9.1.48521: Flags [P.], seq 49:63, ack 7, win 510, options [nop,nop,TS val 1679405540 ecr 4223778913], length 14: FTP: 221 Goodbye.
15:18:34.014686 IP 138.201.203.161.21 > 192.168.9.1.48521: Flags [F.], seq 63, ack 7, win 510, options [nop,nop,TS val 1679405541 ecr 4223778913], length 0
15:18:34.019385 IP 138.201.203.161.21 > 192.168.9.1.48521: Flags [.], ack 8, win 510, options [nop,nop,TS val 1679405547 ecr 4223778913], length 0
15:18:34.036363 IP 138.201.203.161.21 > 192.168.9.1.48521: Flags [.], ack 8, win 510, options [nop,nop,TS val 1679405564 ecr 4223778968,nop,nop,sack 1 {7:8}], length 0
15:18:37.140069 IP 138.201.203.161.57130 > 192.168.9.1.21: Flags [S], seq 244047560, win 64240, options [mss 1452,sackOK,TS val 1555119812 ecr 0,nop,wscale 7], length 0
15:18:45.332602 IP 138.201.203.161.57130 > 192.168.9.1.21: Flags [S], seq 244047560, win 64240, options [mss 1452,sackOK,TS val 1555128004 ecr 0,nop,wscale 7], length 0
15:18:54.678355 IP 138.201.203.161.21 > 192.168.9.1.7172: Flags [S.], seq 3076054274, ack 801963521, win 65160, options [mss 1460,sackOK,TS val 1679426205 ecr 4223799610,nop,wscale 7], length 0
15:18:54.755219 IP 138.201.203.161.21 > 192.168.9.1.7172: Flags [P.], seq 1:49, ack 1, win 510, options [nop,nop,TS val 1679426282 ecr 4223799634], length 48: FTP: 220 ProFTPD Server (ProFTPD) [138.201.203.161]
15:18:54.798347 IP 138.201.203.161.21 > 192.168.9.1.7172: Flags [.], ack 7, win 510, options [nop,nop,TS val 1679426325 ecr 4223799711], length 0
15:18:54.798448 IP 138.201.203.161.21 > 192.168.9.1.7172: Flags [P.], seq 49:63, ack 7, win 510, options [nop,nop,TS val 1679426326 ecr 4223799711], length 14: FTP: 221 Goodbye.
15:18:54.800097 IP 138.201.203.161.21 > 192.168.9.1.7172: Flags [F.], seq 63, ack 8, win 510, options [nop,nop,TS val 1679426327 ecr 4223799711], length 0
^C
21 packets captured
14093 packets received by filter
0 packets dropped by kernel
> tcpdump auf DMZ, identischer Test
root@OPNsense1:~ # tcpdump -i igb1 -n src host 138.201.203.161 and port 21
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on igb1, link-type EN10MB (Ethernet), snapshot length 262144 bytes
15:21:54.680954 IP 138.201.203.161.21 > 192.168.99.30.51190: Flags [S.], seq 1678331187, ack 2477296451, win 65160, options [mss 1460,sackOK,TS val 1679606207 ecr 4223979612,nop,wscale 7], length 0
15:21:54.794893 IP 138.201.203.161.21 > 192.168.99.30.51190: Flags [P.], seq 1:49, ack 1, win 510, options [nop,nop,TS val 1679606322 ecr 4223979637], length 48: FTP: 220 ProFTPD Server (ProFTPD) [138.201.203.161]
15:21:54.827699 IP 138.201.203.161.21 > 192.168.99.30.51190: Flags [.], ack 7, win 510, options [nop,nop,TS val 1679606353 ecr 4223979751], length 0
15:21:54.827718 IP 138.201.203.161.21 > 192.168.99.30.51190: Flags [P.], seq 49:63, ack 8, win 510, options [nop,nop,TS val 1679606354 ecr 4223979751], length 14: FTP: 221 Goodbye.
15:21:54.829276 IP 138.201.203.161.21 > 192.168.99.30.51190: Flags [F.], seq 63, ack 8, win 510, options [nop,nop,TS val 1679606355 ecr 4223979751], length 0
^[[A^C
5 packets captured
79910 packets received by filter
0 packets dropped by kernel
ich hab die pcaps in Dateien geschrieben, aber keine Möglichkeit gefunden, die hier anzuhängen.---- gefunden.
Ich sehe gerade, dass ein anderer Server, welcher in einer anderen Zone ist antwortet.
Hierfür gibt es aber keine Regel.
Poste doch mal die Ausgabe von "ifconfig" auf der OPNsense. Und in die pcaps darfst du auch selbst reingucken :-)
Quote from: Patrick M. Hausen on October 26, 2025, 03:35:00 PMUnd in die pcaps darfst du auch selbst reingucken :-)
hab ich schon, dabei ist mir das ja aufgefallen.
root@OPNsense1:~ # ifconfig
igb0: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 1500
description: WAN (wan)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 20:7c:14:a1:68:2c
inet 192.168.9.11 netmask 0xffffff00 broadcast 192.168.9.255
inet 192.168.9.1 netmask 0xffffff00 broadcast 192.168.9.255 vhid 9
inet6 fe80::227c:14ff:fea1:682c%igb0 prefixlen 64 scopeid 0x1
carp: MASTER vhid 9 advbase 1 advskew 0
peer 224.0.0.18 peer6 ff02::12
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
igb1: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000
description: LAN (lan)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 20:7c:14:a1:68:2d
inet 192.168.99.251 netmask 0xffffff00 broadcast 192.168.99.255
inet 192.168.99.254 netmask 0xffffff00 broadcast 192.168.99.255 vhid 99
carp: MASTER vhid 99 advbase 1 advskew 0
peer 224.0.0.18 peer6 ff02::12
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
igb2: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
description: OPT1 (opt1)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 20:7c:14:a1:68:2e
inet6 fe80::227c:14ff:fea1:682e%igb2 prefixlen 64 scopeid 0x3
media: Ethernet autoselect
status: no carrier
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
igb3: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000
description: HALink (opt2)
options=4802028<VLAN_MTU,JUMBO_MTU,WOL_MAGIC,HWSTATS,MEXTPG>
ether 20:7c:14:a1:68:2f
inet 192.168.0.1 netmask 0xffffff00 broadcast 192.168.0.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x5
groups: lo
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
enc0: flags=0 metric 0 mtu 1536
options=0
groups: enc
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
pfsync0: flags=1000041<UP,RUNNING,LOWER_UP> metric 0 mtu 9000
options=0
syncdev: igb3 syncpeer: 192.168.0.2 maxupd: 128 defer: off version: 1400
syncok: 1
groups: pfsync
pflog0: flags=20100<PROMISC,PPROMISC> metric 0 mtu 33152
options=0
groups: pflog
vlan0.21: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000
description: LAN_VLAN21 (opt6)
options=4000000<MEXTPG>
ether 20:7c:14:a1:68:2d
inet 192.168.21.251 netmask 0xffffff00 broadcast 192.168.21.255
inet 192.168.21.254 netmask 0xffffff00 broadcast 192.168.21.255 vhid 21
groups: vlan
carp: MASTER vhid 21 advbase 1 advskew 0
peer 224.0.0.18 peer6 ff02::12
vlan: 21 vlanproto: 802.1q vlanpcp: 0 parent interface: igb1
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
vlan0.51: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000
description: LAN_VLAN51 (opt3)
options=4000000<MEXTPG>
ether 20:7c:14:a1:68:2d
inet 192.168.51.251 netmask 0xffffff00 broadcast 192.168.51.255
inet 192.168.51.254 netmask 0xffffff00 broadcast 192.168.51.255 vhid 51
groups: vlan
carp: MASTER vhid 51 advbase 1 advskew 0
peer 224.0.0.18 peer6 ff02::12
vlan: 51 vlanproto: 802.1q vlanpcp: 0 parent interface: igb1
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
vlan0.52: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000
description: LAN_VLAN52 (opt4)
options=4000000<MEXTPG>
ether 20:7c:14:a1:68:2d
inet 192.168.52.251 netmask 0xffffff00 broadcast 192.168.52.255
inet 192.168.52.254 netmask 0xffffff00 broadcast 192.168.52.255 vhid 52
groups: vlan
carp: MASTER vhid 52 advbase 1 advskew 0
peer 224.0.0.18 peer6 ff02::12
vlan: 52 vlanproto: 802.1q vlanpcp: 0 parent interface: igb1
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
vlan0.53: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000
description: LAN_VLAN53 (opt5)
options=4000000<MEXTPG>
ether 20:7c:14:a1:68:2d
inet 192.168.53.251 netmask 0xffffff00 broadcast 192.168.53.255
inet 192.168.53.254 netmask 0xffffff00 broadcast 192.168.53.255 vhid 53
groups: vlan
carp: MASTER vhid 53 advbase 1 advskew 0
peer 224.0.0.18 peer6 ff02::12
vlan: 53 vlanproto: 802.1q vlanpcp: 0 parent interface: igb1
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
vlan0.666: flags=1008943<UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,LOWER_UP> metric 0 mtu 9000
description: LAN_VLAN666 (opt7)
options=4000000<MEXTPG>
ether 20:7c:14:a1:68:2d
inet 10.66.6.251 netmask 0xffffff00 broadcast 10.66.6.255
inet 10.66.6.1 netmask 0xffffff00 broadcast 10.66.6.255 vhid 66
groups: vlan
carp: MASTER vhid 66 advbase 1 advskew 0
peer 224.0.0.18 peer6 ff02::12
vlan: 666 vlanproto: 802.1q vlanpcp: 0 parent interface: igb1
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
wg0: flags=10080c1<UP,RUNNING,NOARP,MULTICAST,LOWER_UP> metric 0 mtu 1420
options=80000<LINKSTATE>
inet 192.168.101.0 netmask 0xffffff00
groups: wg wireguard
nd6 options=109<PERFORMNUD,IFDISABLED,NO_DAD>
was könnte bewirken, dass ein anderer host aus einer anderen zone die Pakete bekommt?
Du solltest auf dem igb1 kein untagged Interface haben sondern nur VLANs.
Welche andere Zone denn? Poste bitte auch nochmal den Output von "netstat -rn4".
Grüße
Patrick
die 192.168.99.30 ist im vlan99 (untagged).
root@OPNsense1:~ # netstat -rn4
Routing tables
Internet:
Destination Gateway Flags Netif Expire
default 192.168.9.253 UGS igb0
1.1.1.1 192.168.9.253 UGHS igb0
9.9.9.9 192.168.9.254 UGHS igb0
10.66.6.0/24 link#13 U vlan0.666
10.66.6.1 link#5 UHS lo0
10.66.6.251 link#5 UHS lo0
127.0.0.1 link#5 UH lo0
192.168.0.0/24 link#4 U igb3
192.168.0.1 link#5 UHS lo0
192.168.9.0/24 link#1 U igb0
192.168.9.1 link#5 UHS lo0
192.168.9.11 link#5 UHS lo0
192.168.21.0/24 link#9 U vlan0.21
192.168.21.251 link#5 UHS lo0
192.168.21.254 link#5 UHS lo0
192.168.51.0/24 link#10 U vlan0.51
192.168.51.251 link#5 UHS lo0
192.168.51.254 link#5 UHS lo0
192.168.52.0/24 link#11 U vlan0.52
192.168.52.251 link#5 UHS lo0
192.168.52.254 link#5 UHS lo0
192.168.53.0/24 link#12 U vlan0.53
192.168.53.251 link#5 UHS lo0
192.168.53.254 link#5 UHS lo0
192.168.99.0/24 link#2 U igb1
192.168.99.251 link#5 UHS lo0
192.168.99.254 link#5 UHS lo0
192.168.101.0 link#5 UHS lo0
192.168.101.0/24 link#14 U wg0
Quote from: Patrick M. Hausen on October 26, 2025, 03:48:38 PMDu solltest auf dem igb1 kein untagged Interface haben sondern nur VLANs.
kann ich umstellen, kann das problem damit zu tun haben?
Evtl. Ich frag mich aber eher, aus welchem anderen VLAN die Antworten kommen ...
Die Routing-Tabelle der Sense sieht gut aus.
Hat der Server evtl. mehrere Interfaces?
Die Sense hat:
Physikalisch 4, angeschlossen 3
WAN untagged VLAN 9
OPT2 ha link
LAN untagged VLAN 99, tagged 21,51,52,53,666
Der FTP hat folgende Interfaces:
4x physikalisch, 1 angeschlossen
VLAN666 untagged, 10.66.6.3, hier ist auch das default Gateway drauf, 10.66.6.1
VLAN9 tagged, 192.168.9.3, testweise
VLAN99 tagged, 192.168.99.3
Die beiden getaggten könnte ich auch rausnehmen, werde ich mal testen.
Mich wundert es, dass das Paket, welches auf WAN ankommt und auf die 10.66.6.3 in VLAN 666 gehen soll, auf die 192.168.99.30 im VLAN 99 (untagged) geht. Das einzige was an den beiden targets gleich ist, ist der Port 21
Meine nächsten todos:
FTP auf 1 if runterkonfigurieren
Auf dem LAN if der Sense, reiner Trunk ohne native VLAN
Die Erklärung für die 99.30 hab ich gefunden. Das ist mein icinga, der bei dem Host prüft, ob ftp funktioniert. Kann also ignoriert werden.
Ergo geht am DMZ if VLAN 666 kein einziges Paket von port forwarding raus.
Also liegt es doch irgendwo an einer Regel.
Kann ich in irgendeinem log sehen, warum das ankommende Paket nicht durch geht?
Bei der palo war das Schön im log mit Angabe der Regel, warum so entschieden wurde.
so, todos erledigt.
FTP-Server hat nur noch 1 if
auf der LAN Seite der Sense ist nur noch tagged
aber Fehler ist immer noch da, tcpdump sieht Pakete auf dem WAN if, aber nicht auf dem DMZ if.
bei nem linux server mit iptables würde ich sagen ip forwarding ist nicht gesetzt, aber hier funktioniert es abgehend.
Noch irgend einen Tipp?
Ich werde den thread nochmal im englischen Bereich posten, dort lesen wesentlich mehr mit.
Wenn ich herausgefunden habe, welchen Fehler der typ vor meiner Tastatur gemacht hat, werde ich es hier posten.
ich hab noch weiter probiert und eine http Weiterleitung auf einen Testserver im Plan 99 gemacht, gleiches Problem.
Daher gehe ich davon aus, dass es etwas gemeinsames ist.
Gibt es irgend eine Einstellung, die Port forwarding komplett unterbindet?
Mir fallen wirklich nur gateway rules ein, die hier reinspucken könnten ...
Sorry, ich habe nicht alles gelesen.
ping, traceroute(mtr), und nmap sollten dein Freund sein. Zudem das loggin einschalten.
Ohne alles gelesen zu haben, wundere ich mich,das WAN auf vlan9 sein soll... aber nun denn.
Im weiteren. FTP active oder passive? Ich gehe davon auf, dass der ftp server auch wirklich lauscht auf dem interface und die verbindung aus demselben subnetz funktioniert?
Die Anmerkungen zu FTP im Speziellen hab ich mir noch gespart. So lange über das Port Forwarding das erste SYN Paket nicht beim Server landet, ist alles Weitere erst mal egal.
Ich stehe allerdings auch völlig auf dem Schlauch. Logging für alle relevanten Firewall-Regeln inkl. default deny einschalten und gucken ...
das wan if ist definitiv im Plan 9, von innen nach aussen geht alles. das einzige, was nicht geht ist port forward.
ich werde mir nochmal das logging ansehen.
Starting Nmap 7.94SVN ( https://nmap.org ) at 2025-10-29 05:46 UTC
Nmap scan report for xxxxxxxxx
Host is up (0.032s latency).
rDNS record for xxxxx: xxxxxx
PORT STATE SERVICE
21/tcp open ftp
Nmap done: 1 IP address (1 host up) scanned in 0.14 seconds
nmap sieht gut aus, aber es kommt kein Paket am dmz interface an.
ich baue mir das ganze nochmal in meinem VMware lab nach, evtl. hab ich bei der cluster config irgendwas zerkonfiguriert.
Ich habe weitere Nachforschungen angestellt und es sieht so aus, als handele es sich nicht um ein Problem mit der Portweiterleitung.
Die WAN-Schnittstellen haben die Adressen 192.168.9.11 (1.), 192.168.9.12 (2.) und eine virtuelle IP-Adresse 192.168.9.1.
Wenn der exposed Host auf der Fritz auf die virtuelle IP eingestellt ist, funktioniert die Portweiterleitung nicht.
Wenn ich ihn auf die IP des aktiven OPNsense (1., 192.168.9.11) einstelle, funktioniert die Portweiterleitung wie erwartet.
Es sieht so aus, als hätte das etwas mit der CARP-Adresse zu tun.
Irgendwelche Vorschläge?
Die CARP IP hat dieselbe Netzmaske wie die beiden festen IPs? Das muss so ...
Ja, beide /24
Hattest du schon einen Screenshot von der Virtuellen IP gepostet? Mach doch bitte mal.
hier
settings auf beiden OPNs gleich
die CARP IP ist auch pingbar
Hast du einen kleinen Switch? Häng den mal spaßeshalber zwischen die Fritzbox und die beiden OPNsense. Vielleicht kommt die Fritzbox mit dem Multicast nicht klar.
Die OPNs hängen nicht direkt an der Fritz, sondern an einem Ruckus ICX Cluster.
Was auch immer das ist. Sicher, dass dort alles richtig funktioniert? Ist das eine Art Hypervisor? Sind die OPNsensen VMs?
die OPNs sind HW.
Ich habe alle CARP Adressen testweise auf unicast gestellt, gleiches Problem.
Was ist das für ein Cluster? Was macht das Ding?
Ich denke inzwischen eher in Richtung "MAC Adresse fälschen" klappt nicht, weil irgendein Teil das unterbindet. Siehst du ARP replies bis zur Fritzbox?
Ein ganz normales ICX Cluster/Stack, 2 Units.
Werd gleich mal nach den arps sehen
ARP replies kommen von der fritz
Umgekehrt. Bekommt die Fritzbox replies von der CARP Adresse?
gibt es einen trick bei der fritz den arp cache zu leeren ohne reboot?
Keine Ahnung. Gratuitious ARP schicken?
Aber nochmal: was ist das für ein "Cluster Dings"? Und wo hast du bisher die Packet Traces gemacht?
arp request von der fritz für die 192.168.9.1 kommt
Quote from: Patrick M. Hausen on October 29, 2025, 03:30:21 PMAber nochmal: was ist das für ein "Cluster Dings"? Und wo hast du bisher die Packet Traces gemacht?
Ein ganz normales Switches Cluster auch Stack genannt.
Zwei Switch zu einer logischen Einheit zusammengesetzt.
Der Switch macht nur Layer 2, routing Funktionen werden nicht genutzt.
Captures jeweils auf der OPNsense.
Könnte alternativ in das Kabel zur Fritz!Box eine Allegro einschleifen.
so, einen Schritt weiter:
die Weiterleitung auf http und https funktioniert.
FTP leider immer noch nicht.
Der FTP steht in VLAN666, wenn ich von Innen (VLAN99) per Routing auf den FTP zugreife, funktioniert alles.
Von Aussen über das Port Forwarding funktioniert das Login, aber beim Listing des FTP-Verzeichnisses bleibt es hängen.
Beide Verbindungen über FTP mit SSL.
Ich habe auch noch andere FTP-Server in VLAN666 und VLAN99 ausprobiert, gleiches Ergebnis, von Innen (Routing) funktioniert alles, von aussen (Port Forwarding) geht wieder nur der Login, aber kein Listing.
Über den ftp-proxy als reverse funktioniert es einwandfrei, das ist ein workaround.
Ich würde trotzdem gerne wissen, warum es ohne mit dem listing nicht funktioniert.
Aus dem englischen Forum gibt es die Vermutung, dass zwar der Control Kanal steht, aber der Data Kanel geblockt wird.
Auch dann müsstest du das erste SYN-Paket für den Control-Kanal sehen, aber das kommt doch angeblich nie am Server an?
Verbindung aufbauen, Login etc. geht alles über den Control-Kanal. Erst wenn du ein DIR, GET oder PUT absetzt, wird ein Datenkanal aufgebaut.
Wundert mich auch. Aber zum Glück läufts mit dem Proxy.
Du solltest am Ruckus-ICX-Stack das IGMP-Snooping im VLAN 9 deaktivieren oder die Multicast-Adresse 224.0.0.18 statisch zulassen, damit CARP-Ankündigungen zwischen den OPNsense-Knoten sauber durchkommen.
Das Problem liegt mit hoher Wahrscheinlichkeit daran, dass die Fritte oder der Switch die CARP-Multicasts bzw. ARP-Updates nicht korrekt weiterleiten, weshalb die Fritte die virtuelle IP (192.168.9.1) nicht zuverlässig der aktiven Firewall zuordnet.
Falls vorhanden, würde ich ggf. mal ein TAP dazwischen hängen und mit Wireshark anschauen.
Wenn da vorher ein PA Cluster hing, frage ich mich so echt und wirklich, warum zur Hölle eine Fritte? Das sind zwei Welten. Den ganzen VOIP Rotz, so meine Spekulation, bekommt man auch anders hin.
Ich hab hier keinen Cluster Betrieb, aber hatte nur Ärger mit der 7590. Von daher läuft hier nun ein Vigor 166. Beste Investition in meinen Kupferlink und besonders meine Nerven^
@Patrick: Ruckus ist nen klassischer Switch Hersteller. Ehemals Brocade. Ich hatte damit aber auch noch keine Berührungspunkte im DC
Hi fastboot,
igmp snooping ist global aus.
TAP: Hab momentan ne Allegro dazwischen
Das PA Cluster war auch als Ex Host hinter der gleichen Fritz, hat immer funktioniert.
Ich vermute, dass der FTP versucht irgendwelche Ports zu benutzen, die nicht freigegeben sind. Die PA hat das Ganze applikationsbasiert gemacht, ähnlich dem FTP-Proxy.
Wenn ich etwas mehr Zeit habe, werde ich weiter testen, momentan muss ich noch Multi-WAN, Wireguard und mehrere VPN Tunnel zum laufen bekommen.
Die 76er und 78er machen sich gut im DC