Synology NAS niet extern te benaderen

[S-te-fan]

Ik heb een nieuwe NAS gekocht, de oude vertrekt naar een andere locatie om als externe backup gebruikt te worden. Dat wil ik doen via een DDNS adres, want hyper drive werkt niet via de Quickconnect van Synology.

Om het 1 en ander voor te bereiden wilde ik dit gaan testen maar dan met poort 5000 / 5001 om op de DSM pagina in te loggen, maar op geen enkele manier kom ik van een extern apparaat op mijn NAS terecht.

Dat geldt overigens voor beide apparaten. Een DS213j en de nieuwe DS224+ welke beide draaien op DSM7, allebei compleet nieuwe installaties.

Voor zover mijn NAS instellingen:
NAS staat ingesteld op vast ipadres
192.168.2.100 ipadres
255.255.255.0 subnet
192.168.2.254 gateway & dns server

Serviceprovider: Synology.me
Hostname: domein.synology.me (fictief)
Extern IPv4 adres: 123.123.123.123 (fictief)
IPv6 uigeschakeld
Omwille van testen geen certificaat ingesteld.

In mijn router ZTE H369a het volgende als portforwarding ingesteld voor IP 192.168.2.100
Start 5000 Eind 5000
Start 5001 Eind 5001

Via mijn IPad (via 4G) gecontroleerd met een online nslookup of domein.synology.me uitkomt bij mijn WAN IPadres en of poort 5000 open staat. Beide met positief resultaat.
Maar krijg geen verbinding.

Heb ook nog een DuckDNS domein aangemaakt en deze ingesteld op de NAS, maar met hetzelfde (geen) resultaat. Dit moet mij dan vermoeden dat ik toch ergens in de NAS een instelling niet juist heb staan.

Omwille van test heb ik even port forwarding ingesteld op 8123 naar het IP van HomeAssistant op een RPI4, 123.123.123.123:8123 komt dan gewoon bij mijn HomeAssistant uit.

Iemand nog enig idee waar dit aan kan liggen? Uiteindelijk gaan poorten 5000 en 5001 weer dicht en wordt alleen Synology HyperDrive gebruikt via de daarvoor bestemde poort.

[lier]

De titel van je topic is misleidend, DDNS op Synology werkt prima (daarom resolved hij goed). Alleen heb je een probleem met het forwarden van 2 poorten.

Kom je wel op de NAS uit als je 192.168.2.100:5000 lokaal gebruikt?
Kan je logging activeren op je Synology webserver (om te zien of de requests binnenkomen)?

Het is overigens niet handig om poort 5000 en 5001 te forwarden, heb je 2FA geactiveerd op je NAS?

[S-te-fan]

Klopt, had het anders kunnen benoemen inderdaad. Een suggestie die de lading beter dekt qua titel?

Mijn NAS werkt verder helemaal goed, lokaal kom ik via poort 5000 (die overigens automatisch doorstuurt naar 5001 voor een https connectie) goed in mijn NAS.
Ik ga eens zoeken naar het activeren van de logging om daar eens te kijken.

Zoals ik aangaf is het openzetten van 5000 en 5001 alleen nu tijdelijk omdat die makkelijk te testen zijn.
Straks gaat poort 6281 open voor de HyperDrive backup functie. En daarnaast is mijn account ook met 2fa beveiligd inderdaad.
Ik heb op dit moment ook de port forwarding regels weer eruit gehaald omdat ik nu niet ermee bezig ben.

[Shinji]

Ik zou trouwens niet die poorten open zetten maar VPN tussen de locaties bouwen en daarover de backups laten gaan.

[S-te-fan]

Wellicht is dat de volgende stap om te doen inderdaad, maar dan alsnog blijft de vraag waarom de huidige situatie niet werkt zoals het zou moeten werken ondanks dat alles goed lijkt te staan.

[lier]

Ben benieuwd naar de logging.
Heb je TCP als protocol geforward?

[S-te-fan]

Ik ga er vanavond weer even mee aan de gang om de logging aan te zetten en verder te testen.
TCP protocol is inderdaad geforward, volgens mij heb ik zelfs TCP&UDP aangevinkt omdat het niet werkte.

[Ora et Labora]

Anders even een screenshot delen van je router.
Het zit vrijwel zeker in de portforwarding van je router.

[Ben(V)]

S-te-fan schreef op dinsdag 25 juni 2024 @ 09:22:
Klopt, had het anders kunnen benoemen inderdaad. Een suggestie die de lading beter dekt qua titel?

Mijn NAS werkt verder helemaal goed, lokaal kom ik via poort 5000 (die overigens automatisch doorstuurt naar 5001 voor een https connectie) goed in mijn NAS.
Ik ga eens zoeken naar het activeren van de logging om daar eens te kijken.

Zoals ik aangaf is het openzetten van 5000 en 5001 alleen nu tijdelijk omdat die makkelijk te testen zijn.
Straks gaat poort 6281 open voor de HyperDrive backup functie. En daarnaast is mijn account ook met 2fa beveiligd inderdaad.
Ik heb op dit moment ook de port forwarding regels weer eruit gehaald omdat ik nu niet ermee bezig ben.

Hoe heb je dat automatisch doorsturen naar poort 5001 gerealiseerd.
Ik kan me zo voorstellen dat dit niet werkt vanaf het internet.

Verder heb je poort 5000 en/of 5001 nodig voor Hyper Backup maar alleen op de target Nas voor het configureren.
Als het eenmaal werkt kan die forward eruit en hoeft je alleen poort 6281 op de target Nas te forwarden.

Overigens is een VPN gebruiken zoals iemand suggereerde als je alleen poort 6281 nog geforward is volkomen overbodig.

[S-te-fan]

Dat is een functie van Synology zelf, om verkeer via een https verbinding te pushen.

For DSM 7.0 and above: Go to DSM Control Panel > Login Portal > DSM, tick Automatically redirect HTTP connection to HTTPS for DSM desktop and click Save.
For DSM 6.x: Go to DSM Control Panel > Network > DSM Settings, tick Automatically redirect HTTP connection to HTTPS (for DSM desktop) and click Apply.

[Orion84]

S-te-fan schreef op dinsdag 25 juni 2024 @ 12:21:
Dat is een functie van Synology zelf, om verkeer via een https verbinding te pushen.


[...]

Heb je het ook al eens getest zonder die functie actief?

[jeroen3]

Die functie stuurt gewoon een redirect status terug. Dat zal het niet zijn denk ik.

Ik zou dit zoeken in je ZTE. Je kunt kijken of je uberhaupt tcp krijgt met iets achter 5001, met telnet o.i.d.

"Vroeger" toen ik nog wel kpn modems gebruikte moest een ip door de dhcp server zijn uitgedeeld anders weigerde hij netjes port-forwarding toe te passen.
Is dat nog steeds?

[Orion84]

jeroen3 schreef op dinsdag 25 juni 2024 @ 12:41:
Die functie stuurt gewoon een redirect status terug. Dat zal het niet zijn denk ik.

Wel als die redirect naar 192.168.2.100:5001, want dat werkt dan vanaf buiten niet.

[ Voor 3% gewijzigd door Orion84 op 25-06-2024 12:48 ]

[lier]

Orion84 schreef op dinsdag 25 juni 2024 @ 12:34:
Heb je het ook al eens getest zonder die functie actief?

Ik ga ervan uit dat het verkeer de Synolgy niet bereikt:

Maar krijg geen verbinding.

@S-te-fan, komt er een respons of niet (kijk eens naar het netwerkverkeer op je client via devtools)?
En wat betekent "geen verbinding" voor jou?

[S-te-fan]

lier schreef op dinsdag 25 juni 2024 @ 11:59:
Ben benieuwd naar de logging.
Heb je TCP als protocol geforward?

Krijg het niet gevonden waar ik logging moet vinden, of waar ik de logging moet aanzetten voor de webserver.

Ora et Labora schreef op dinsdag 25 juni 2024 @ 12:10:
Anders even een screenshot delen van je router.
Het zit vrijwel zeker in de portforwarding van je router.

En deze instellingen hangen aan 192.168.2.100
Met deze website check ik of de poort inderdaad open staat.
https://www.yougetsignal.com/tools/open-ports/
Als ik poort open 8123 open zet en koppel aan het IP van HomeAssistant dan kom ik met WANIP:8123 netjes op HomeAssistant uit. Dus port forwarding op mijn router werkt zoals verwacht.

Orion84 schreef op dinsdag 25 juni 2024 @ 12:34:
[...]

Heb je het ook al eens getest zonder die functie actief?

Staat nu uit, geen verandering helaas.

lier schreef op dinsdag 25 juni 2024 @ 13:06:
[...]

Ik ga ervan uit dat het verkeer de Synolgy niet bereikt:

[...]

@S-te-fan, komt er een respons of niet (kijk eens naar het netwerkverkeer op je client via devtools)?
En wat betekent "geen verbinding" voor jou?

Geen verbinding betekent voor mij dat mijn chrome op de iPad (via 4G) het volgende zegt:

Ik krijg na een poos proberen te verbinden de melding Deze site is niet bereikbaar:
ERR_CONNECTION_TIMED_OUT

[ Voor 4% gewijzigd door S-te-fan op 25-06-2024 17:58 ]

[Orion84]

Die screenshot is nu alleen de thumbnail, daar kunnen we zo niets uit opmaken

Heb je al rondgekeken in je DSM settings of er ergens iets van een firewall actief is die bijvoorbeeld alleen lokaal verkeer toestaat naar 5000/5001 en verkeer vanaf het internet blokkeert?

[S-te-fan]

@Orion84 Afbeelding gefixt, en nee kan zo’n optie ook niet vinden. Ook de (over het algemeen) duidelijke handleidingen van Synology spreken niet over zo’n functie.

[ Voor 5% gewijzigd door S-te-fan op 25-06-2024 18:34 ]

[Frogmen]

Wat gebeurt er als je op poort 5001 connect.

[Ora et Labora]

@S-te-fan
- Intern naar 192.168.2.100:5001 werkt dus wel?
- Extern via hostname werkt niet, werkt het ook niet via IP, dus Https://jouwwanip:5001?
- Op de synology, control panel, Security, Firewall, even de firewall uitzetten als test.
- Op de synology, control panel, Network, tab General, wat staat daar bij default Gateway? Is dat het adres van je router?
- Op de synology, control panel, Network, tab Network Interface, heb je die op handmatig of DHCP staan en als deze op handmatig staat, staat het vinkje "Set as default gateway" ook aan en is de gateway daar goed ingevuld?
- Tab static route staat toevallig niet iets verkeerds?
- Tab protection, auto block even uitzetten voor test.

[ThinkPad]

Ik vermoed dat je in de Synology firewall ook nog de poort moet openzetten, volgens mij is de standaard daar ook 'dicht, tenzij'.

Zoals al gesuggereerd zou ik ook de boel via een VPN inrichten. Dat is veel veiliger dan de NAS openzetten naar internet. En uiteraard sterke wachtwoorden + 2FA gebruiken. Je zal niet de eerste zijn bij wie de Synology wordt gehackt en data versleuteld wordt door ransomware.

[ Voor 54% gewijzigd door ThinkPad op 26-06-2024 11:18 ]

[E - Jay]

Net even testje gedaan op mijn eigen DS224+ maar ik hoef er niets geks voor te doen.
portforwarding in de router van 5000 naar intern ip nas poort 5000 en ik fiets hem er zo in met m'n domeinnaam:5000

Niet per ongeluk bij testen IP geblokkeerd door de nas?
Of heb je toevallig een aparte gebruiker gemaakt die geen toegang heeft tot de webgui?

[S-te-fan]

@Ora et Labora Dat rijtje ga ik vanavond eens proberen, maar intern werkt het allemaal zoals het moet. En rechtstreeks op https://wanip:5001 werkt ook niet.

@ThinkPad Daar staat niks ingesteld, het is een compleet nieuwe Synology waarbij ik een gebruiker (administratorrechten) heb aangemaakt en daarna getest met DDNS. En zoals aangegeven is extern benaderen van 5000/5001 enkel voor testen. Ik ga hem enkel gebruiken voor hyperdrive backup.
Het moet ook gewoon werken ookal is er een alternatieve (betere) methode.

@E - Jay Precies wat de handleiding van Synology ook beschrijft inderdaad. DDNS aanmaken, poorten open zetten en gaan… Maar helaas.

@Frogmen Net zoveel als op poort 5000 helaas.

Heb ook ticket lopen bij Synology zelf, zei geven aan dat het ergens in mijn eigen netwerkapparaten moet zitten en niet in de NAS. Klinkt aannemelijk, maar port forwarding gaat perfect naar alle apparaten die ik tijdelijk even open zet behalve de NAS.

Iemand een idee hoe je logging moet aanzetten of bekijken om te kijken of er requests binnenkomen?

[ Voor 5% gewijzigd door S-te-fan op 26-06-2024 16:20 ]

[Ora et Labora]

S-te-fan schreef op woensdag 26 juni 2024 @ 16:12:
@Ora et Labora Dat rijtje ga ik vanavond eens proberen, maar intern werkt het allemaal zoals het moet. En rechtstreeks op https://wanip:5001 werkt ook niet.

@ThinkPad Daar staat niks ingesteld, het is een compleet nieuwe Synology waarbij ik een gebruiker (administratorrechten) heb aangemaakt en daarna getest met DDNS. En zoals aangegeven is extern benaderen van 5000/5001 enkel voor testen. Ik ga hem enkel gebruiken voor hyperdrive backup.
Het moet ook gewoon werken ookal is er een alternatieve (betere) methode.

@E - Jay Precies wat de handleiding van Synology ook beschrijft inderdaad. DDNS aanmaken, poorten open zetten en gaan… Maar helaas.

@Frogmen Net zoveel als op poort 5000 helaas.

Heb ook ticket lopen bij Synology zelf, zei geven aan dat het ergens in mijn eigen netwerkapparaten moet zitten en niet in de NAS. Klinkt aannemelijk, maar port forwarding gaat perfect naar alle apparaten die ik tijdelijk even open zet behalve de NAS.

Iemand een idee hoe je logging moet aanzetten of bekijken om te kijken of er requests binnenkomen?

En is het gelukt?
Ik dacht aan een verkeerde gateway-instelling in de synology zodat die z'n weg terug niet meer weet, of de firewall blokkeert de verbinding maar dat is vreemd want dat zou gewoon moeten werken.

[FreakNL]

Gateway is een prima gok inderdaad

[Orion84]

S-te-fan schreef op woensdag 26 juni 2024 @ 16:12:
Iemand een idee hoe je logging moet aanzetten of bekijken om te kijken of er requests binnenkomen?

SSH toegang aanzetten op je Synology, inloggen met je admin user, switchen naar root (sudo su), sudo pass is zelfde als je admin pass.

En dan kan je tcpdump draaien: tcpdump -A -i any dst port 5000

Zodra dat staat te luisteren proberen te verbinden vanaf buiten (zorg dat je niet nog ergens anders de DSM webconsole open hebt staan, want dan krijg je een boel ruis). Dan kan je zien of er netwerkverkeer binnenkomt op poort 5000 en wat daarmee gebeurt.

[Flans]

Heb je je cache al eens leeggegooid?

[S-te-fan]

@Ora et Labora Het voorgestelde rijtje stond al goed of uit, enkel het vinkje bij "Set as default gateway" stond uit. Maar dat maakt helaas geen verschil.

@Orion84

code:

09:36:36.858662 eth0  In  IP ********.mobile.kpn.net.61717 > 192.168.2.100.DSM-http: Flags [F.], seq 316, ack 1, win 4106, options [nop,nop,TS val 72058946 ecr 496261260], length 0
E..4..@.;.v....&...d........$......
c......
.K.B..X.
09:36:36.858662 bond0 In  IP ********.mobile.kpn.net.61717 > 192.168.2.100.DSM-http: Flags [F.], seq 316, ack 1, win 4106, options [nop,nop,TS val 72058946 ecr 496261260], length 0
E..4..@.;.v....&...d........$......
c......
.K.B..X.
09:36:42.378692 eth0  In  IP ********.mobile.kpn.net.61717 > 192.168.2.100.DSM-http: Flags [FP.], seq 0:316, ack 1, win 4106, options [nop,nop,TS val 72064468 ecr 496261260], length 316
E..p..@.;.u....&...d........$......
.......
.K....X.GET /favicon.ico HTTP/1.1
Host: ********.synology.me:5000
Connection: keep-alive
User-Agent: Mozilla/5.0 (iPad; CPU OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/125.0.6422.80 Mobile/15E148 Safari/604.1
Accept-Encoding: gzip, deflate
Accept-Language: nl-NL,nl;q=0.9,en-US;q=0.8,en;q=0.7


09:36:42.378692 bond0 In  IP ********.mobile.kpn.net.61717 > 192.168.2.100.DSM-http: Flags [FP.], seq 0:316, ack 1, win 4106, options [nop,nop,TS val 72064468 ecr 496261260], length 316
E..p..@.;.u....&...d........$......
.......
.K....X.GET /favicon.ico HTTP/1.1
Host: ********.synology.me:5000
Connection: keep-alive
User-Agent: Mozilla/5.0 (iPad; CPU OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/125.0.6422.80 Mobile/15E148 Safari/604.1
Accept-Encoding: gzip, deflate
Accept-Language: nl-NL,nl;q=0.9,en-US;q=0.8,en;q=0.7


09:36:49.047459 eth0  In  IP ********.mobile.kpn.net.61717 > 192.168.2.100.DSM-http: Flags [FP.], seq 0:316, ack 1, win 4106, options [nop,nop,TS val 72071132 ecr 496261260], length 316
E..p..@.;.u....&...d........$......
z......
.K....X.GET /favicon.ico HTTP/1.1
Host: ********.synology.me:5000
Connection: keep-alive
User-Agent: Mozilla/5.0 (iPad; CPU OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/125.0.6422.80 Mobile/15E148 Safari/604.1
Accept-Encoding: gzip, deflate
Accept-Language: nl-NL,nl;q=0.9,en-US;q=0.8,en;q=0.7


09:36:49.047459 bond0 In  IP ********.mobile.kpn.net.61717 > 192.168.2.100.DSM-http: Flags [FP.], seq 0:316, ack 1, win 4106, options [nop,nop,TS val 72071132 ecr 496261260], length 316
E..p..@.;.u....&...d........$......
z......
.K....X.GET /favicon.ico HTTP/1.1
Host: ********.synology.me:5000
Connection: keep-alive
User-Agent: Mozilla/5.0 (iPad; CPU OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/125.0.6422.80 Mobile/15E148 Safari/604.1
Accept-Encoding: gzip, deflate
Accept-Language: nl-NL,nl;q=0.9,en-US;q=0.8,en;q=0.7

Krijg wel netwerkverkeer binnen, bovenstaande wordt meerdere malen herhaald, alleen timestamp wijzigt.

[ Voor 61% gewijzigd door S-te-fan op 27-06-2024 09:38 ]

[Orion84]

Aangezien er ook daadwerkelijk de http requests binnenkomen komt er dus ook daadwerkelijk wel een tcp verbinding tot stand.

Kan je het eens proberen met: tcpdump -A -i any port 5000

Zodat we de responses ook zien langskomen?

[S-te-fan]

@Orion84

code:

09:59:15.508858 bond0 In  IP ******.mobile.kpn.net.61797 > 192.168.2.100.DSM-http: Flags [P.], seq 1:388, ack 1, win 4106, options [nop,nop,TS v                                                                                      al 3005663915 ecr 497649866], length 387
E.....@.;.um...&...d.e....m........
0V.....
.&......GET / HTTP/1.1
Host: ******.synology.me:5000
Upgrade-Insecure-Requests: 1
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
User-Agent: Mozilla/5.0 (iPad; CPU OS 17_5 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) CriOS/125.0.6422.80 Mobile/15E148 Safari/604.1
Accept-Language: nl-NL,nl;q=0.9
Accept-Encoding: gzip, deflate
Connection: keep-alive


09:59:15.508885 bond0 Out IP 192.168.2.100.DSM-http > ******.mobile.kpn.net.61797: Flags [.], ack 388, win 235, options [nop,nop,TS val 49764990                                                                                      9 ecr 3005663915], length 0
E..4t.@.@..^...d...&...e......o............
.....&..
09:59:15.508889 eth1  Out IP 192.168.2.100.DSM-http > ******.mobile.kpn.net.61797: Flags [.], ack 388, win 235, options [nop,nop,TS val 49764990                                                                                      9 ecr 3005663915], length 0
E..4t.@.@..^...d...&...e......o............
.....&..
09:59:15.633857 bond0 Out IP 192.168.2.100.DSM-http > ******.mobile.kpn.net.61797: Flags [P.], seq 1:2170, ack 388, win 235, options [nop,nop,TS                                                                                       val 497650034 ecr 3005663915], length 2169
E...t.@.@......d...&...e......o......s.....
...r.&..HTTP/1.1 200 OK
Server: nginx
Date: Thu, 27 Jun 2024 07:59:15 GMT
Content-Type: text/html; charset="UTF-8"
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
Vary: Accept-Encoding
Cache-control: no-store
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
Content-Security-Policy: base-uri 'self';  connect-src data: ws: wss: http: https:; default-src 'self' 'unsafe-eval' data: blob: https://*.synology.com                                                                                       https://www.synology.cn/ https://help.synology.cn/; font-src 'self' data: https://*.googleapis.com https://*.gstatic.com; form-action 'self'; frame-an                                                                                      cestors 'self'; frame-src 'self' data: blob: https://*.synology.com https://*.synology.cn http://*.synology.com http://*.synology.cn http://global.syno                                                                                      logydownload.com https://global.synologydownload.com; img-src 'self' data: blob: https://*.google.com https://*.googleapis.com http://*.googlecode.com                                                                                       https://*.gstatic.com https://global.download.synology.com; media-src 'self' data: about: https://*.synology.com https://help.synology.cn;  script-src                                                                                       'self' 'unsafe-eval' data: blob: https://maps.google.com https://maps.googleapis.com https://ajax.googleapis.com https://help.synology.com https://help                                                                                      .synology.cn; style-src 'self' 'unsafe-inline' https://*.googleapis.com;
Content-Encoding: gzip

2ee
...........UKo.0.>7.B3..*;..l..X.a..u..CO.l1..[2$9..?Jv.[..[.;..)..>...g..........j<....JR1).`l..N...{'q....`....L>.w...%.      ..V..6 ...$....E.a)r.^8                                                                                      %B
+XIM.JH.a..C.E.T.....2..J*..
[.p.^.Je..B....`.G...).\.B.4    ".kQ[.....Z...}..
........r....m.T!J..........P&....L.....F............FD..?.j......D`*...
2.M4e.M%C....J.l.1........c9 c...4z..3q.R..~../..p.faU..`.Pr.,{...|     ....K.  .......h9{}..j.. .`.w..$.c..U............|I..r..9.]29Kd.[..3.
......<.}w...........r...;=....t..M)...c...)h.t.5..p_.^...-.....d...G...F...l....5..Y.5-...8..........Z..s.....!.0<.....I.bV.3.%..$>...Ls.:{...i..=.BJ.                                                                                      ...P.........[....w-+..l........p;M0...
.p..`...hI%)...T......eKa..za7g....<..ES...5..g....c.(...1..G).j.w.....k....jM}^...M..*|v.I./....       ;....v.....N|.#.R.{?.....

09:59:15.633873 eth1  Out IP 192.168.2.100.DSM-http > ******.mobile.kpn.net.61797: Flags [P.], seq 1:2170, ack 388, win 235, options [nop,nop,TS                                                                                       val 497650034 ecr 3005663915], length 2169
E...t.@.@......d...&...e......o......s.....
...r.&..HTTP/1.1 200 OK
Server: nginx
Date: Thu, 27 Jun 2024 07:59:15 GMT
Content-Type: text/html; charset="UTF-8"
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
Vary: Accept-Encoding
Cache-control: no-store
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
P3P: CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"
Content-Security-Policy: base-uri 'self';  connect-src data: ws: wss: http: https:; default-src 'self' 'unsafe-eval' data: blob: https://*.synology.com                                                                                       https://www.synology.cn/ https://help.synology.cn/; font-src 'self' data: https://*.googleapis.com https://*.gstatic.com; form-action 'self'; frame-an                                                                                      cestors 'self'; frame-src 'self' data: blob: https://*.synology.com https://*.synology.cn http://*.synology.com http://*.synology.cn http://global.syno                                                                                      logydownload.com https://global.synologydownload.com; img-src 'self' data: blob: https://*.google.com https://*.googleapis.com http://*.googlecode.com                                                                                       https://*.gstatic.com https://global.download.synology.com; media-src 'self' data: about: https://*.synology.com https://help.synology.cn;  script-src                                                                                       'self' 'unsafe-eval' data: blob: https://maps.google.com https://maps.googleapis.com https://ajax.googleapis.com https://help.synology.com https://help                                                                                      .synology.cn; style-src 'self' 'unsafe-inline' https://*.googleapis.com;
Content-Encoding: gzip

2ee
...........UKo.0.>7.B3..*;..l..X.a..u..CO.l1..[2$9..?Jv.[..[.;..)..>...g..........j<....JR1).`l..N...{'q....`....L>.w...%.      ..V..6 ...$....E.a)r.^8                                                                                      %B
+XIM.JH.a..C.E.T.....2..J*..
[.p.^.Je..B....`.G...).\.B.4    ".kQ[.....Z...}..
........r....m.T!J..........P&....L.....F............FD..?.j......D`*...
2.M4e.M%C....J.l.1........c9 c...4z..3q.R..~../..p.faU..`.Pr.,{...|     ....K.  .......h9{}..j.. .`.w..$.c..U............|I..r..9.]29Kd.[..3.
......<.}w...........r...;=....t..M)...c...)h.t.5..p_.^...-.....d...G...F...l....5..Y.5-...8..........Z..s.....!.0<.....I.bV.3.%..$>...Ls.:{...i..=.BJ.                                                                                      ...P.........[....w-+..l........p;M0...
.p..`...hI%)...T......eKa..za7g....<..ES...5..g....c.(...1..G).j.w.....k....jM}^...M..*|v.I./....       ;....v.....N|.#.R.{?.....

09:59:15.636563 bond0 Out IP 192.168.2.100.DSM-http > ******.mobile.kpn.net.61797: Flags [P.], seq 2170:2190, ack 388, win 235, options [nop,nop                                                                                      ,TS val 497650036 ecr 3005663915], length 20
E..Ht.@.@..G...d...&...e...~..o............
...t.&..a
..      .......
0


09:59:15.636573 eth1  Out IP 192.168.2.100.DSM-http > ******.mobile.kpn.net.61797: Flags [P.], seq 2170:2190, ack 388, win 235, options [nop,nop                                                                                      ,TS val 497650036 ecr 3005663915], length 20
E..Ht.@.@..G...d...&...e...~..o............
...t.&..a
..      .......
0

[Orion84]

Dat ziet er allemaal tamelijk gezond uit er gaat een GET heen en er komen HTTP 200 responses terug met data, dus een beetje vreemd dat je iPad alsnog aangeeft geen verbinding te kunnen krijgen

[S-te-fan]

Bedankt voor het bekijken van de logs, ik kan daar niet echt wijs uit worden...

Ik ga eens mijn oude NAS terugzetten naar DSM6 ipv 7. Wellicht dat er gewoon een bug zit in de software.
Het is namelijk ook bij beide NAS'sen hetzelfde. Die beide draaien op de laatste versie van DSM7.

Had gelijktijdig een ticket lopen bij Synology support center, maar die geven de schuld aan mijn eigen netwerk en dat ik een andere router moet proberen. Die heb ik niet zomaar liggen. Dus daar houdt het nu ook op.

En voor de rest kan ik al mijn apparaten in mijn thuisnetwerk extern benaderen zodra ik ip-adres / portforwarding juist instel.

@Flans Yup, maar geen resultaat helaas.

[ Voor 9% gewijzigd door S-te-fan op 27-06-2024 10:48 ]

[Orion84]

Dat de client daadwerkelijk een HTTP GET stuurt betekent (als ik me niet vergis) dat er daarvoor al een succesvolle TCP handshake is geweest, waarmee routing issues eigenlijk wel uitgesloten zijn. Dat een firewall pas later in de sessie dwars gaat liggen lijkt me ook wat vreemd.

Je zou eigenlijk aan de client kant ook het verkeer moeten capturen om te zien wat er wel en wat er niet doorkomt. Maar dat is met een iPad wat lastig. Kan je een ander systeem (via een personal hotspot of zo) gebruiken om vanaf buiten te testen, waar je wel iets als wireshark of tcpdump of zo op kan laten meedraaien?

En liefst ook nog testen via een ander extern netwerk. Wie weet doet KPN wel iets aan filtering of zo wat roet in het eten gooit. Of je eigen ISP filtert iets om klanten te beschermen die per ongeluk hun NAS naar buiten hebben opengezet of zo.

PS: dit alles is nu tijdelijk zonder de redirect naar poort 5001 of is dat mechanisme weer actief?

[ Voor 22% gewijzigd door Orion84 op 27-06-2024 10:59 ]

[Orion84]

S-te-fan schreef op dinsdag 25 juni 2024 @ 09:22:
Klopt, had het anders kunnen benoemen inderdaad. Een suggestie die de lading beter dekt qua titel?

Ik heb 'm even aangepast voor je, laat maar weten als je een betere suggestie hebt

[Flans]

S-te-fan schreef op donderdag 27 juni 2024 @ 10:42:
Bedankt voor het bekijken van de logs, ik kan daar niet echt wijs uit worden...

Ik ga eens mijn oude NAS terugzetten naar DSM6 ipv 7. Wellicht dat er gewoon een bug zit in de software.
Het is namelijk ook bij beide NAS'sen hetzelfde. Die beide draaien op de laatste versie van DSM7.

Had gelijktijdig een ticket lopen bij Synology support center, maar die geven de schuld aan mijn eigen netwerk en dat ik een andere router moet proberen. Die heb ik niet zomaar liggen. Dus daar houdt het nu ook op.

En voor de rest kan ik al mijn apparaten in mijn thuisnetwerk extern benaderen zodra ik ip-adres / portforwarding juist instel.

@Flans Yup, maar geen resultaat helaas.

Even helemaal iets anders... Je zou je nog kunnen verdiepen in (argo) Tunnels van Cloudflare. Die zijn op dit moment vrij simpel in te stellen en zorgen ervoor dat je geen poorten hoeft open te zetten. Uiteindelijk denk ik een betere optie dan wat je op dit moment aan het proberen bent/was.

[rjong5]

Als laatste kan je nog proberen een andere port te forwarden, pak bijvoorbeeld die 8123, en forward die naar 5000 of 5001 ( of pas de port aan naar 8123 in je nas)

[fsfikke]

Kan je het op de iPad ipv via de browser eens via de DS Finder app van Synology proberen? https://apps.apple.com/nl/app/ds-finder/id429865523?l=en-GB

[Kabouterplop01]

Wat about (ism) eens je hele internet cache leeg gooien m.u.v. je passwords e.d. (zoals ik het lees heb je geen password manager... hint ) dus ook cookies e.d.

Het heeft als ik je log goed lees niets met je router te maken.
als je je synology pingt en je krijgt antwoord...dan is het routeringsmechanimse OK.
wellicht heb je een firewall feature aan staan op je router, dat zou je volgende troubleshoot punt worden.

[ Voor 45% gewijzigd door Kabouterplop01 op 01-07-2024 08:40 ]

[Panzer_V]

Je hebt iets aan settings in je syno verkeerd staan. Heeft niets te maken met DSM 7 imho.

Check:
1) De firewall in je syno. Zet deze desnoods voor de test uit.
2) Check de rechten van de gebruiker die je gebruikt voor het inloggen. Of nog beter, gebruik voor de test je admin account om in te loggen. Je hebt desktop/dashboard rechten nodig, anders kom je er niet in.

Het is echt zo simpel als wat, ik ben er van overtuigd dat een setting binnen je NAS de boel tegenhoud. Of je firewall staat verkeerd, of (en dat is waarschijnlijker) je gebruiker heeft te weinig rechten.

Houdt het simpel, zet alle beveiliging uit en gebruik alleen admin users (met echt alle rechten). En probeer het dan.

Als het werkt met alle beveiliging uit ga je stap voor stap de beveiliging terug aanzetten. Dan kom je vanzelf het punt tegen waar het nog niet goed geconfigureerd staat.

[ Voor 3% gewijzigd door Panzer_V op 01-07-2024 08:49 ]

[fsfikke]

Panzer_V schreef op maandag 1 juli 2024 @ 08:49:
2) Check de rechten van de gebruiker die je gebruikt voor het inloggen. Of nog beter, gebruik voor de test je admin account om in te loggen. Je hebt desktop/dashboard rechten nodig, anders kom je er niet in.

Hij komt niet eens op de inlog-pagina...

[Ben(V)]

Terug naar DSM 6 kan helemaal en zou ook nutteloos zijn.
Zet voor de zekerheid de firewall van die Synology even geheel uit.

Verder kan het niet in die Synology zitten, want lokaal werkt alles goed.
Je moet het waarschijnlijk zoals Synolgy support al zei, zoeken in je router.

Heb je soms ook forwards van poort 5000/5001 naar je andere Nas staan?
Probeer zoals al door @rjong5 al voorstelde een andere poort naar port 5000 van die Nas te forwarden en daarmee te connecten.

[SambalBij]

Dat uit die tcpdumps daadwerkelijk requests naar en antwoorden van de webserver naar voren komen sluit eigenlijk bijna alle netwerk/internet/routing issues uit. Je portforwardings zijn in orde, je routing is in orde. Anders zou het op de TCP handshake al stuklopen en nooit zo ver komen als dit.

Ik zie in die tcpdumps de antwoorden dubbel naar buiten gaan; je hebt zo te zien 2 netwerkpoorten gebundeld. Het verkeer gaat eerst door interface 'bond0' naar buiten, en daarna nog een keer via interface 'eth1' (de tweede netwerkpoort)
Zitten beide netwerkpoorten wel goed aangesloten? Zelfde switch, zelfde segment/VLAN, juiste bonding protocol (simpele etherchannel, load balancing, LACP etc)

Helaas maakt die webserver gebruik van gzip, dus kunnen we niet de inhoudelijke HTML zien die hij terugstuurt. Misschien eens kijken met een webbrowser op een normale PC ipv een iPad? Misschien gaat de eerste HTML pagina wel goed, maar probeert die bijvoorbeeld een redirect te doen van http naar https en gebruikt dan het interne IP ofzo... (En vanaf je iPad gaat hij dan https://192.168.2.100:5001 natuurlijk niet kunnen vinden)

[jeroen3]

De ipad zal sowieso https://192.168.2.100:5001 weigeren want daar heb je geen certificaat voor.

Het forwarden werkt zo, met dank aan wireshark.

code:

HTTP/1.1 200 OK
Server: nginx
Date: Mon, 01 Jul 2024 08:33:41 GMT
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=20
Cache-control: no-store

e8
<!DOCTYPE html>
<html>
  <script type="text/javascript">
    var uri = location.pathname + location.search + location.hash;
    var URL = 'https://' + location.hostname + ':5001' + uri;
    location.replace(URL);
  </script>
</html>

[Panzer_V]

fsfikke schreef op maandag 1 juli 2024 @ 08:53:
[...]

Hij komt niet eens op de inlog-pagina...

Heb je al geprobeerd door de firewall in de Syno uit te zetten?

En je had aangegeven dat je ipv6 hebt uitgeschakeld. Schakel dat eens terug in. Internet is standaard ipv6 en alleen bij uitzondering nog ipv4.

Als laatste middel kan je nog overwegen om je syno terug naar fabrieksinstellingen te zetten en dan, op basis van het standaard admin account e.e.a. aan de hand van de RTFM in te richten.

Het zit echt ergens in jouw instellingen.

[fsfikke]

Panzer_V schreef op maandag 1 juli 2024 @ 10:49:
[...]


Heb je al geprobeerd door de firewall in de Syno uit te zetten?

En je had aangegeven dat je ipv6 hebt uitgeschakeld. Schakel dat eens terug in. Internet is standaard ipv6 en alleen bij uitzondering nog ipv4.

Als laatste middel kan je nog overwegen om je syno terug naar fabrieksinstellingen te zetten en dan, op basis van het standaard admin account e.e.a. aan de hand van de RTFM in te richten.

Het zit echt ergens in jouw instellingen.

Nee hoor, mijn Synology werkt gewoon. Die van de TS daarentegen...

[S-te-fan]

@Flans klopt, dat is zeker een optie. Maar daar gaat het nu niet meer om, ik wil erachter komen waarom een optie die zou moeten werken niet werkt.

@rjong5 dit is al geprobeerd, port forwarding werkt naar alle devices in mn netwerk behalve de nas. Verander ik de poorten van de nas dan werkt die je ook niet op de poort.

@fsfikke ik begrijp niet wat dit toevoegt als ik eerlijk ben, de nas is binnen mijn eigen netwerk heeft in te benaderen. Die ds Finder app maakt toch gebruik van je eigen netwerk of via Quick connect?

@Kabouterplop01 er draait wel een password manager
Cache leeggooien al geprobeerd, geen resultaat.

@Panzer_V het is een volledig nieuwe installatie, geen firewall settings en ik heb een admin account aangemaakt. Nog niet geprobeerd met het originele admin account. Dat kan ik nog eens proberen.

@Ben(V) dsm6 maakte inderdaad geen verschil, firewall staat uit en omwille van het testen heb ik op nas 1 5000/5001 ingesteld en op nas 2 5010/5011 en soms heb ik 1 van beide uit staan. Ik heb overigens altijd maar 1 portforwarding instelling tegelijk staan.

[fsfikke]

S-te-fan schreef op maandag 1 juli 2024 @ 11:16:


@fsfikke ik begrijp niet wat dit toevoegt als ik eerlijk ben, de nas is binnen mijn eigen netwerk heeft in te benaderen. Die ds Finder app maakt toch gebruik van je eigen netwerk of via Quick connect?

DSM 6 installeren voegt ook niks toe en toch heb je het gedaan
Het idee is dat je iPad een TCP verbinding opbouwt, maar niet naar het login scherm geraakt. Dus daar gaat ergens iets mis. Die app logt via een api in, mogelijk werkt die wel. Je kan in de DS Finder app gewoon je externe IP invullen en daarmee proberen te verbinden. Dat kan je vanuit je lokale netwerk proberen en vanaf 4G.

[ Voor 4% gewijzigd door fsfikke op 01-07-2024 11:23 ]

[S-te-fan]

fsfikke schreef op maandag 1 juli 2024 @ 11:22:
[...]


DSM 6 installeren voegt ook niks toe en toch heb je het gedaan
Het idee is dat je iPad een TCP verbinding opbouwt, maar niet naar het login scherm geraakt. Dus daar gaat ergens iets mis. Die app logt via een api in, mogelijk werkt die wel. Je kan in de DS Finder app gewoon je externe IP invullen en daarmee proberen te verbinden. Dat kan je vanuit je lokale netwerk proberen en vanaf 4G.

Ik wilde uitsluiten dat het een bug is in dsm7, kostte me een uurtje werk. Dus geen ramp.

Ah, goeie. Dan ga ik dat met die ds Finder eens proberen.

[rjong5]

Wat misschien nog een optie is om te proberen :

schakel ssh / telnet toegang in op de nas, en maak een portforward.
en dan vanaf internet op je nas proberen te ssh-en.

als dat ook niet werkt is het wel heel vreemd, dat geen enkele portforwarding naar je nas werkt, maar naar andere devices wel.

overigens lijkt het er op dat je nas indd het probleem ook niet is, want intern werkt alles zeg je, dan kom je toch terecht op je modem/router/gateway waar het fout gaat.

ps.. misschien je nas een ander ip geven, dan kan je uitsluiten dat die het probleem geeft.. ik roep ook maar wat.

[ Voor 14% gewijzigd door rjong5 op 01-07-2024 11:29 ]

[Ora et Labora]

rjong5 schreef op maandag 1 juli 2024 @ 11:28:


overigens lijkt het er op dat je nas indd het probleem ook niet is, want intern werkt alles zeg je, dan kom je toch terecht op je modem/router/gateway waar het fout gaat.

ps.. misschien je nas een ander ip geven, dan kan je uitsluiten dat die het probleem geeft.. ik roep ook maar wat.

Het kan wel de gateway zijn. layer2-verkeer werkt intern maar layer3 niet, routering.
Maar dat had TS al gechecked dacht ik.

@TS, je zou de NAS nog wel een keer op DHCP kunnen zetten als deze op fixed IP staat.

[Ben(V)]

Als je van buiten de Nas probeert te benaderen doet de gateway er niet toe.
Je benadert de router met z'n Wan ipadres en poortnummer vanaf het internet, de router stuurt dat door naar de Nas volgens zijn port forwarding rule en zo zou je op de Nas moeten komen.
Het antwoordt van de Nas gaat gewoon de omgekeerde weg retour en daar gebruikt hij het gateway adres niet bij.
De gateway is alleen van belang als de Nas zelf initieert om naar buiten het internet op te gaan.

Maar aangezien hij helemaal nergens uitkomt kan de router blijkbaar de Nas niet vinden.
Dus ofwel de portforwarding is verkeerd, ofwel een firewall blokkeert de boel, ofwel de router kan het ipadres van de Nas niet vinden.
Vandaar deze timeout melding

ERR_CONNECTION_TIMED_OUT

Kijk in de log van de router wat daar gebeurd.

[ Voor 4% gewijzigd door Ben(V) op 01-07-2024 12:24 ]

[rjong5]

Als je van buiten de Nas probeert te benaderen doet de gateway er niet toe.
Je benadert de router met z'n Wan ipadres en poortnummer vanaf het internet, de router stuurt dat door naar de Nas volgens zijn port forwarding rule en zo zou je op de Nas moeten komen.
Het antwoordt van de Nas gaat gewoon de omgekeerde weg retour en daar gebruikt hij het gateway adres niet bij.
De gateway is alleen van belang als de Nas zelf initieert om naar buiten het internet op te gaan.

ik twijfelde hierover, maar je hebt helemaal gelijk. zojuist zelf getest, en zonder gateway kan ik gewoon op mijn NAS vanaf extern.

ik was er eigenlijk heilig van overtuigd dat ik wel een gateway nodig had hiervoor. weer wat geleerd.

[ Voor 7% gewijzigd door rjong5 op 01-07-2024 12:59 ]

[ThinkPad]

SambalBij schreef op maandag 1 juli 2024 @ 09:13:
[...]
Ik zie in die tcpdumps de antwoorden dubbel naar buiten gaan; je hebt zo te zien 2 netwerkpoorten gebundeld. Het verkeer gaat eerst door interface 'bond0' naar buiten, en daarna nog een keer via interface 'eth1' (de tweede netwerkpoort)
Zitten beide netwerkpoorten wel goed aangesloten? Zelfde switch, zelfde segment/VLAN, juiste bonding protocol (simpele etherchannel, load balancing, LACP etc)

[....]

Die bond0 viel mij ook op. Wellicht eerst eens met één NIC proberen en kijken of dat werkt.

[laurens0619]

rjong5 schreef op maandag 1 juli 2024 @ 12:57:
[...]


ik twijfelde hierover, maar je hebt helemaal gelijk. zojuist zelf getest, en zonder gateway kan ik gewoon op mijn NAS vanaf extern.

ik was er eigenlijk heilig van overtuigd dat ik wel een gateway nodig had hiervoor. weer wat geleerd.

Ik ben daar eigenlijk ook heilig van overtuigd
Tenminste bij standaard SRC NAT met Masquerading. Bij andere vormen van NAT (als je router het afzender IP lijkt) zou het ook zonder GW werken.

Maar misschien maak ik 1 grote denkfout en geeft die gewoon het return traffic op een established session.

maar ontopic zou ik hier idd naar die dubbel interface kijken wat @SambalBij scherp had opgemerkt

[ Voor 7% gewijzigd door laurens0619 op 01-07-2024 14:49 ]

[Orion84]

ThinkPad schreef op maandag 1 juli 2024 @ 13:39:
[...]

Die bond0 viel mij ook op. Wellicht eerst eens met één NIC proberen en kijken of dat werkt.

Uitsluiten kan natuurlijk nooit kwaad, maar ik zou het wel gek vinden als er wel een tcp verbinding tot stand komt, maar door die bonding daarna daarna het http verkeer op een of andere manier in een zwart gat verdwijnt op de terugweg naar de iPad...

Zeker aangezien een en ander lokaal wel werkt...

Idem voor andere L2/L3 oorzaken.

[ Voor 10% gewijzigd door Orion84 op 01-07-2024 14:57 ]

[jeroen3]

Het kan ook een nog mtu probleem zijn. SYN/ACK past dan wel, maar de data zelf niet. Dit zijn alleen wel verregaande speculaties. Die eigenlijk geen probleem zouden moeten zijn met een syno en standaard providermodems.

Heb je de mogelijkheid om met een hub of switch met port mirror een wireshark capture te maken, of gaat dat te ver?

[ Voor 21% gewijzigd door jeroen3 op 01-07-2024 15:03 ]

[rjong5]

ik vind het een heel vreemd issue in geval en erg benieuwd wat straks de oorzaak blijkt te zijn geweest.

wireshark is een goed idee indd

[ Voor 14% gewijzigd door rjong5 op 01-07-2024 15:47 ]

[S-te-fan]

Dat de bond een issue is lijkt mij uitgesloten.

Dat zou enkel het geval zijn op de nieuwe variant waarbij ik 2 netwerkpoorten gekoppeld heb, maar op de DS211j is die optie er niet.

@jeroen3 wireshark ken ik, maar de rest wat je zegt is voor mij een beetje onbekend helaas.

[ Voor 20% gewijzigd door S-te-fan op 01-07-2024 17:20 ]

[Orion84]

Zoals ik al zei in Orion84 in "Synology NAS niet extern te benaderen" zou ik om te beginnen eens proberen of je de test kan doen vanaf een andere externe machine dan die iPad en als het dan nog steeds faalt op die machine via wireshark of iets dergelijks een capture doen, zodat je die kan vergelijken met de capture aan de kant van de NAS.

[S-te-fan]

Nou, jullie zullen het niet geloven...
Maar de verbinding is gemaakt.

Ik heb mijn router teruggezet naar fabrieksinstellingen.
Vervolgens "mijn" DHCP range instellingen weer gedaan.
de DHCP range teruggezet naar 192.168.2.1 t/m 80 ipv 200 en voor deze situatie port forwarding opnieuw ingesteld.

Exact dezelfde instellingen die ik ongeveer een 1,5 maand geleden ook gedaan heb toen ik deze router gekregen heb ook ingesteld heb.

Het bleek uiteindelijk dus toch in de router gezeten te hebben, maar ik heb geen idee welke instelling dit geweest moet zijn. En het is mij al helemaal een raadsel waarom die alleen maar invloed had op de NAS en niet op overige port forwarding naar andere netwerkapparatuur.

[ Voor 11% gewijzigd door S-te-fan op 01-07-2024 21:13 ]

[Ben(V)]

laurens0619 schreef op maandag 1 juli 2024 @ 14:47:
[...]

Ik ben daar eigenlijk ook heilig van overtuigd
Tenminste bij standaard SRC NAT met Masquerading. Bij andere vormen van NAT (als je router het afzender IP lijkt) zou het ook zonder GW werken.

Maar misschien maak ik 1 grote denkfout en geeft die gewoon het return traffic op een established session.

maar ontopic zou ik hier idd naar die dubbel interface kijken wat @SambalBij scherp had opgemerkt

Je "misschien" is correct.

Enkel bij het zelf opzetten van een connectie zal de Nas via de gateway een andere IP-adres zoeken er moet dan gerouteerd worden.
Als de connectie vanaf een andere source wordt opgezet is dat nooit nodig, want hij weet dan al waar hij heen moet, want de session is al established.

En een LACP kon nooit het probleem zijn die gedraagt zich netwerk technisch gezien gewoon als een enkel IP-adres, als daar is mis mee zou zijn zou je lokaal die Nas ook niet kunnen bereiken.