Port Forwarding Problem mit Synology Diskstation

Adhemar · Apr 17, 2022, 7:24 AM

Hallo community,

meine Ausgangssituation ist folgende: Ich habe zwei WAN Leitungen
und möchte auf beiden WAN Leitungen Port Weiterleitungen einrichten, die auch gleichzeitig funktionieren sollen.
Leider funktioniert das auf der aktuell von uns eingesetzten UDM Pro
nur im Failover Modus. Nur wenn WAN1 down ist, geht die für WAN2 eingesetzte Weiterleitung durch.

Da PfSense ja eine viel mächtigere Routinglösung ist, dachte ich mir ok wir stellen das um auf PfSense,
da sollte sowas problemlos möglich sein. Gesagt, getan...

Entsprechende Hardware besorgt, PfSense 2.6.0 installiert.

Beide WAN Leitungen konfiguriert
(Vodafone mit static public ip/Telekom mit static public ip).

Vodafone (6591 via exposed host)
Telekom (Draytek Vigor 167 Modem)

Beide Leitungen funktionieren. DoppelWAN erstmal beiseite geschoben und nur
die Telekom an die PfSense gepackt um Port Forwarding zu testen.

Leider komme ich an der Stelle nicht weiter. Ich bin natürlich nach den
einschlägigen Anleitungen vorgegangen und habe versucht eine Synology
Diskstation über die externe statische IP erreichbar zu machen (DSM).

Internet <=> Draytek Vigor <=> PfSense <=> Switch <=> Synology

Als Alternative habe ich einmal folgendes versucht....

Internet <=> Draytek Vigor <=> PfSense <=> Switch <=> PC mit IIS Webserver

NAT
login-to-view
RULES
login-to-view

Das klappt problemlos. Sowohl mit Port 80 als auch mit 8080 von extern.
Sobald ich das jedoch dupliziere und mit Port 5000 auf die IP der Synology
versuche, ist da nichts mehr zu sehen.

Lokal ist die Synology von jedem PC im Netzwerk erreichbar (DSM Port 5000).
Auch die PfSense kann sie sehen, Ping funktionert.

Wenn ich eine Port Weiterleitung mit der Unifi UDMPro anlege, klappt es sofort.

Bin etwas ratlos und würde mich sehr über Euren Input freuen.

Frohe Ostern !

Adhemar

NOCling · Apr 17, 2022, 8:06 AM

Mache mal ein Bild davon was du als zweite NAT Regel angelegt hast.

Du kannst jedoch auf WAN Seite, pro WAN Interface und IP nur einmal einen Port vergeben.
Wenn du bei der Telekom WAN IP also den 8080 schon vergeben hast, kannst du diese nicht für eine zweite Regel eintragen.
Da muss dann 8081 verwendet werden, den kannst du wieder auf einen nach belieben weiterleiten.

Policy based NAT geht zwar, dann kannst du aber für die Source nicht * angeben, sondern müsstest hier die Quelle ganz genau angeben. Dann könntest du auch 8080 hier gesondert umleiten. In so einem Fall zählt dann aber auch wieder die Reihenfolge, sprich die Policy based Rule muss ganz nach oben, die mit * dann darunter.

Adhemar · Apr 17, 2022, 8:35 AM

@nocling

Guten Morgen ;-) ich habe um die Sache möglichst übersichtlich zu halten,
die Regel oben immer angepasst. Pro WAN Seite jeweils nur einmal ein Port
ist klar. Sind ja genug Ports da. Ich lege das mal für die Synology an... :

Ich habe auch einmal als Test, ICMP freigegeben für die externe IP, auch das
klappt einwandfrei.

Hier mein PF :

NAT
login-to-view

RULES
login-to-view

NOCling · Apr 17, 2022, 8:46 AM

Ok das sieht ja erstmal gut aus.

Mache mal das Logging für beide Regeln an, schaue unter Diag mit dem Packet Capture mal nach was wirklich von außen für Anfragen rein kommen.

Für dual WAN denke an die Einstellung für die stickyness -> System/Advanced/Miscellaneous

Adhemar · Apr 17, 2022, 9:39 AM

@nocling

login-to-view

Das sieht ansich ja gut aus...aber leider kommt nichts von der Synology zurück,
gleiches Problem auch mit anderen Synos. Auch mit anderen Ports wie FTP
auf den Synos.

login-to-view

Der Webserver jedoch zeigt sich wie er soll...und funktioniert.

NOCling · Apr 17, 2022, 9:36 AM

Dann solltest du mit den Synos weiter diskutieren, warum diese nicht auf die Anfragen von der WAN Seite sprechen wollen, ggf. ist hier ja ein Filter, eine Firewall oder was auch immer aktiv.

Kannst auch eine Virtuelle IP im LAN Netz auf der Sense anlegen und dann die Source hier mit verstecken, wenn das anders nicht laufen will.

Adhemar · Apr 17, 2022, 9:40 AM

@nocling

Mit einem Portscanner (yougetsignal.com) von außen wird 8080 offen
und 5000 als geschlossen angezeigt.

Die Synology Systeme können zwar eine Firewall haben, diese ist jedoch
deaktiviert.

NOCling · Apr 17, 2022, 9:40 AM

Erstelle einen PCAP mit den Diag Tools der pfSense, dann siehst du wo das Problem liegt.

Adhemar · Apr 17, 2022, 9:57 AM

@nocling

code_text
11:50:23.283748 AF IPv4 (2), length 64: (tos 0x0, ttl 53, id 13944, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.35391 > 78.79.101.102.5000: Flags [S], cksum 0x9a10 (correct), seq 349329309, win 14600, options [mss 1452,sackOK,TS val 1895850469 ecr 0,nop,wscale 8], length 0
11:50:24.283775 AF IPv4 (2), length 64: (tos 0x0, ttl 53, id 13945, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.35391 > 78.79.101.102.5000: Flags [S], cksum 0x9916 (correct), seq 349329309, win 14600, options [mss 1452,sackOK,TS val 1895850719 ecr 0,nop,wscale 8], length 0
11:50:24.285013 AF IPv4 (2), length 64: (tos 0x0, ttl 53, id 24475, offset 0, flags [DF], proto TCP (6), length 60)
    198.199.98.246.35393 > 78.79.101.102.5000: Flags [S], cksum 0x084b (correct), seq 3220454724, win 14600, options [mss 1452,sackOK,TS val 1895850719 ecr 0,nop,wscale 8], length 0
11:50:24.324774 AF IPv4 (2), length 45: (tos 0x0, ttl 127, id 42026, offset 0, flags [DF], proto TCP (6), length 41)
    78.79.101.102.59467 > 136.243.77.108.443: Flags [.], cksum 0x5d93 (correct), seq 1354291031:1354291032, ack 2094562013, win 1024, length 1
11:50:24.344251 AF IPv4 (2), length 56: (tos 0x0, ttl 57, id 18304, offset 0, flags [DF], proto TCP (6), length 52)
    136.243.77.108.443 > 78.79.101.102.59467: Flags [.], cksum 0xd965 (correct), seq 1, ack 1, win 501, options [nop,nop,sack 1 {0:1}], length 0
11:50:25.076499 AF IPv4 (2), length 56: (tos 0x0, ttl 127, id 38031, offset 0, flags [DF], proto TCP (6), length 52)
===group

Eine Idee woran es liegen könnte ?

NOCling · Apr 17, 2022, 10:04 AM

Das ist die WAN Seite, sieht doch gut aus, die LAN Seite?

Adhemar · Apr 17, 2022, 10:14 AM

    80.187.74.105.5436 > 192.168.11.250.5000: Flags [S], cksum 0xd650 (correct), seq 3365660571, win 65535, options [mss 1410,nop,wscale 6,nop,nop,TS val 1594867979 ecr 0,sackOK,eol], length 0
12:07:25.584888 00:90:27:e4:15:dd > 90:e2:ba:15:c4:1c, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 48, id 22860, offset 0, flags [DF], proto TCP (6), length 64)
    80.187.74.105.5434 > 192.168.11.250.5000: Flags [S], cksum 0x0bde (correct), seq 3882261684, win 65535, options [mss 1410,nop,wscale 6,nop,nop,TS val 1415168594 ecr 0,sackOK,eol], length 0
12:07:25.824929 00:90:27:e4:15:dd > 90:e2:ba:15:c4:1c, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 48, id 54203, offset 0, flags [DF], proto TCP (6), length 64)
    80.187.74.105.5439 > 192.168.11.250.5000: Flags [S], cksum 0x20c3 (correct), seq 686361697, win 65535, options [mss 1410,nop,wscale 6,nop,nop,TS val 1037963957 ecr 0,sackOK,eol], length 0
12:07:26.584983 00:90:27:e4:15:dd > 90:e2:ba:15:c4:1c, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 48, id 22963, offset 0, flags [DF], proto TCP (6), length 64)
    80.187.74.105.5436 > 192.168.11.250.5000: Flags [S], cksum 0xd267 (correct), seq 3365660571, win 65535, options [mss 1410,nop,wscale 6,nop,nop,TS val 1594868980 ecr 0,sackOK,eol], length 0
12:07:26.585075 00:90:27:e4:15:dd > 90:e2:ba:15:c4:1c, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 48, id 22558, offset 0, flags [DF], proto TCP (6), length 64)
    80.187.74.105.5434 > 192.168.11.250.5000: Flags [S], cksum 0x07f5 (correct), seq 3882261684, win 65535, options [mss 1410,nop,wscale 6,nop,nop,TS val 1415169595 ecr 0,sackOK,eol], length 0
12:07:26.825200 00:90:27:e4:15:dd > 90:e2:ba:15:c4:1c, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 48, id 54991, offset 0, flags [DF], proto TCP (6), length 64)
    80.187.74.105.5439 > 192.168.11.250.5000: Flags [S], cksum 0x1cd9 (correct), seq 686361697, win 65535, options [mss 1410,nop,wscale 6,nop,nop,TS val 1037964959 ecr 0,sackOK,eol], length 0
12:07:27.584986 00:90:27:e4:15:dd > 90:e2:ba:15:c4:1c, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 48, id 22663, offset 0, flags [DF], proto TCP (6), length 64)
    80.187.74.105.5434 > 192.168.11.250.5000: Flags [S], cksum 0x040d (correct), seq 3882261684, win 65535, options [mss 1410,nop,wscale 6,nop,nop,TS val 1415170595 ecr 0,sackOK,eol], length 0
12:07:27.585065 00:90:27:e4:15:dd > 90:e2:ba:15:c4:1c, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 48, id 23480, offset 0, flags [DF], proto TCP (6), length 64)
    80.187.74.105.5436 > 192.168.11.250.5000: Flags [S], cksum 0xce7f (correct), seq 3365660571, win 65535, options [mss 1410,nop,wscale 6,nop,nop,TS val 1594869980 ecr 0,sackOK,eol], length 0
12:07:27.824973 00:90:27:e4:15:dd > 90:e2:ba:15:c4:1c, ethertype IPv4 (0x0800), length 78: (tos 0x0, ttl 48, id 54828, offset 0, flags [DF], proto TCP (6), length 64)
    80.187.74.105.5439 > 192.168.11.250.5000: Flags [S], cksum 0x18ef (correct), seq 686361697, win 65535, options [mss 1410,nop,wscale 6,nop,nop,TS val 1037965961 ecr 0,sackOK,eol], length 0
```===group
```java

===

Interface LAN

NOCling · Apr 17, 2022, 10:16 AM

Die Syno bekommt die Anfragen, antwortet aber nicht, deren Default GW ist aber die pfSense?

Adhemar · Apr 17, 2022, 10:53 AM

@nocling

Danke Dir echt, das war der gordische Knoten ;-) Ich honk hab den Gateway
nicht korrekt gesetzt. Der lag noch bei der UDMPro. Manchmal sieht man den
Wald vor lauter Bäumen nicht und braucht ein weiteres Paar Augen.

Vielen Dank nochmal und weiter frohe Ostern !