Print pagina - Nas toegangsprobleem vanaf intern netwerk [Opgelost]

(Edit: titel aangepast. Was voorheen: Mail Server probleem vanaf intern netwerk)

Ik kom er met achter dat IMAP op mijn 2 desktop computers niet meer werkt. Wel op mijn laptop en ook met roundcube. SMTP vanaf mijn desktop werkt wel.

Na enig gepuzzel wat het verschil is, merkte ik dat alle werkende verbindingen via mijn domeinnaam lopen (dus via de router lopen) en de niet werkende verbinding intern opgezet worden. Na het aanpassen van de interne adres in mijn externe IP, had ik wel weer IMAP toegang tot de nas.

Dus op de een of andere manier wordt de toegang vanaf het interne netwerk geblokkeerd. Het eerste wat me te binnen schiet is de firewall, maar daar zie ik niets geks. Zowel de IMAP poort is vrijgegeven voor intern verkeer alsook het IP van mijn desktop heeft volledige toegang tot de nas.

RaRa. In elk geval heb ik nu een noodoplossing, maar ik wil juist via het interne adres verbinden voor een efficiënter netwerk verkeer.

Dit is nu al het derde DSM 5.1 pakket dat problemen geeft terwijl de beta versies vanaf het begin probleemloos werkten. :o

Heb je bij de IMAP hostname al geprobeerd het IP adres te gebruiken, ipv de naam van je Syno?

/Erik

Ik heb alle namen tevergeefs geprobeerd. :D

Alle namen die resolven in het interne IPv4 adres van mijn nas, wordt de toegang geblokkeerd. Het is dus breder dan allen Mail Station. Cloud Station gaf hetzelfde probleem en de browser ook. Ik heb daarom de titel van dit topic maar even aangepast.

Alleen mijn nasnaam werkt nog in de browser. Maar dat komt omdat hij dan via een IPv6 adres inlogt. Via bonjour is aan de nasnaam zowel een IPv4 als een IPv6 adres toegekend. Mijn mailprogramma stapt niet over op het IPv6 adres.
(IPv6 ondersteuning op de nas uitzetten maakt ook niets uit)

Dus effectief wordt toegang vanaf de interne IP range geblokkeerd. In de firewall wordt die echter expliciet toegestaan. Tijd voor wat meer testen…

De firewall uit zetten lost het probleem niet op. En ook op de blokkeringslijst staat geen enkel intern IP adres. Maar wat dan wel houdt een toegang vanaf een intern IPv4 adres dan tegen?

Echt alles werkt niet meer omdat alles via het locale netwerk de nas aanspreekt.
Mijn agenda synchroniseert niet meer, de DSN server op de nas is niet meer bereikbaar etc. Een deel kan ik fixen door het verkeer via de router te laten lopen, maar niet alles.

De shares kan ik ook niet meer via het IPv4 benaderen. Ik merk wel dat shares koppelen via bonjour nog wel werkt. Dan verbindt hij gewoon via IPv6 i.p.v. een intern IPv4 adres. (Even gechecked met Wireshark)

Ik zie dat security station ook geen beeld meer heeft omdat de cameras ook intern verbinden. Als ik naar de opnames kijk, zie ik dat die ook gestopt zijn op het moment dat dsm 5.1 geïnstalleerd is. Normaal zijn er > 500 opnames per dag. Gisteren was er naar één. Als ik naar het tijdstip van die opname kijk, was dat het moment dat ik de nas weer ge-reboot heb. Blijkbaar heeft hij tijdes het restarten wel een tijdje interne IP adressen geaccepteerd.

TimeMachine werkt nog wel. Als ik in het log kijk, verbond hij vroeger met een IPv4 adres en nu lukt dat niet en kiest hij om met IPv6 te verbinden.

Wat als je het IPv4 adres gebruikt (geen naam, geen DNS nodig)

Het IPv4 adres zelf invullen werkt ook niet. De cameras zijn b.v. alleen via het IPv4 adres ingesteld (Zij ondersteunen ook geen IPv6)
Ik realiseer me nu ook dat bij de cameras, het de nas is die de verbinding opbouwt en het niet de cliënt is die de nas probeert te benaderen. Dus in beide richtingen wordt het verkeer geblokkeerd.
Het zal toch ergens in de firewall zitten, maar niet in het deel van de firewall waar je via de DSM menu's bij kunt.

In de logs zie ik ook niets wat een clue geeft. Ik zie wel dat de TimeMachine backups doorlopen Voor DSM 5.1 ging dat via een IPv4 adres en nu via een IPv6 adres. (Gelukkig staat IPv6 aan op de nas ;))
Via ssh inloggen lukte eerst ook niet. Ik moest ssh eerst in de router forwarden, zodat ik de ssh via mijn url kon benaderen.

Ik ben nu een ticket aan het schrijven voor Synology.

NB ik kan de NAS ook niet pingen. En als ik via SSH inlog kan ik vanaf de nas ook niet naar een intern adres pingen, maar wel naar andere adressen:

Citaat

GedeeldeData> ping nu.nl <-- extern adres lukt wel
PING nu.nl (62.69.166.254): 56 data bytes
64 bytes from 62.69.166.254: seq=0 ttl=248 time=10.044 ms
64 bytes from 62.69.166.254: seq=1 ttl=248 time=11.806 ms
64 bytes from 62.69.166.254: seq=2 ttl=248 time=10.891 ms
^C
--- nu.nl ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 10.044/10.913/11.806 ms

GedeeldeData> ping 10.0.1.32 <-- een intern apparaat lukt niet
PING 10.0.1.32 (10.0.1.32): 56 data bytes
^C
--- 10.0.1.32 ping statistics ---
18 packets transmitted, 0 packets received, 100% packet loss <---- 100% loss

GedeeldeData> ping 10.0.3.1 <--- Een ander intern subnet lukt wel.
PING 10.0.3.1 (10.0.3.1): 56 data bytes
64 bytes from 10.0.3.1: seq=0 ttl=63 time=1.710 ms
64 bytes from 10.0.3.1: seq=1 ttl=63 time=0.896 ms
64 bytes from 10.0.3.1: seq=2 ttl=63 time=0.908 ms
^C
--- 10.0.3.1 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.896/1.171/1.710 ms

Een ander intern subnet lukt wel, dus is het alleen het subnet waar de nas in zit dat blokkeert. Van mijn laptop kan ik wel gewoon naar alle apparaten pingen dus de blokkade zit in de nas.

Na update 5.1 alleen maar ellende met het aanmelden ik ben Synology nu echt zat heb jaren Qnap gehad
nooit geen problemen zet de schijven over naar 2 QNAP NASSEN mijn DS 214play en DS214se zet ik binnenkort hier wel te koop

Briolet: hoe ziet een listing van je firewall eruit? Misschien wordt daar toch je lokale subnet geblocked?

Code: [Selecteer]

iptables -L --line-numbers

Ben al bezig met het omzetten naar QNAP heb het gehad met SYNOLOGY
Bedangt en gr.

Ik ken alleen de DSM versie, maar in Linux ziet het er als volgt uit:

Code: [Selecteer]

GedeeldeData> iptables -L --line-numbers
Chain INPUT (policy ACCEPT)
num  target     prot opt source               destination         
1    DOS_PROTECT  all  --  anywhere             anywhere            
2    ACCEPT     all  --  anywhere             anywhere            
3    ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
4    ACCEPT     all  --  10.0.1.60            anywhere            
5    ACCEPT     all  --  10.0.1.61            anywhere            
6    ACCEPT     all  --  10.0.1.20            anywhere            
7    ACCEPT     all  --  10.0.1.22            anywhere            
8    ACCEPT     tcp  --  59-120-41-39.HINET-IP.hinet.net  anywhere             multiport dports http,5000,ssh,telnet
9    ACCEPT     tcp  --  118-163-30-16.HINET-IP.hinet.net  anywhere             multiport dports http,5000,ssh,telnet
10   ACCEPT     tcp  --  125-227-152-103.HINET-IP.hinet.net  anywhere             multiport dports http,5000,ssh,telnet
11   DROP       tcp  --  anywhere             anywhere             tcp dpt:telnet
12   DROP       all  --  81.18.240.0/20       anywhere            
13   DROP       all  --  anywhere             anywhere             source IP range 89.248.170.8-89.248.171.127
14   DROP       all  --  89.248.168.0/24      anywhere            
15   DROP       all  --  93.174.88.0/21       anywhere            
16   DROP       all  --  94.102.48.0/20       anywhere            
17   ACCEPT     tcp  --  10.0.0.0/22          anywhere             multiport dports afs3-fileserver,9007,9008,8800,8801,8000,8001,9900,6690,smtp,smtps,imaps,50002,50001,domain
18   ACCEPT     tcp  --  10.0.0.0/22          anywhere             multiport dports ldap,ldaps,9025:9040,afpovertcp,netbios-ns,netbios-dgm,netbios-ssn,microsoft-ds,sunrpc,892,nfs,5005,rsync,5000
19   ACCEPT     udp  --  10.0.0.0/22          anywhere             multiport sports 19997,65001,5004,rfe,netbios-ns
20   ACCEPT     udp  --  10.0.0.0/22          anywhere             multiport dports bootpc,bootps,ntp,syslog,syslog,19998,1900,domain,65001,5004,rfe,5353,sunrpc,892,nfs
21   ACCEPT     udp  --  10.0.0.0/22          anywhere             multiport dports 1234,9997,9998,9999
22   ACCEPT     tcp  --  anywhere             anywhere             Source country: TW  tcp dpt:5000
23   ACCEPT     tcp  --  anywhere             anywhere             Source countries: BE,NL  multiport dports afs3-callback,9901,6281,6690,smtps,imaps,ldap,ldaps,1723,ftp,55536:55539,5006,https,http
24   ACCEPT     tcp  --  anywhere             anywhere             Source countries: BE,NL  multiport dports 5001,5000,ssh
25   ACCEPT     udp  --  anywhere             anywhere             Source countries: BE,NL  udp spt:19997
26   ACCEPT     udp  --  anywhere             anywhere             Source countries: BE,NL  multiport dports tftp,19998,l2tp,4500,isakmp
27   ACCEPT     47   --  anywhere             anywhere             Source countries: BE,NL 
28   ACCEPT     esp  --  anywhere             anywhere             Source countries: BE,NL 
29   ACCEPT     ah   --  anywhere             anywhere             Source countries: BE,NL 
30   ACCEPT     tcp  --  anywhere             anywhere             multiport dports smtp,smtps,submission
31   ACCEPT     udp  --  anywhere             anywhere             udp dpt:1194
32   DROP       all  --  anywhere             anywhere            
33   ACCEPT     all  --  anywhere             anywhere            

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination         

Chain DOS_PROTECT (1 references)
num  target     prot opt source               destination         
1    RETURN     icmp --  anywhere             anywhere             icmp echo-request limit: avg 1/sec burst 5
2    DROP       icmp --  anywhere             anywhere             icmp echo-request
3    RETURN     tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5
4    DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/RST
5    RETURN     tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 10000/sec burst 100
6    DROP       tcp  --  anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
GedeeldeData>

Het is globaal gelijk aan de DSM versie, maar ik zie toch verschillen. ik start b.v. met een IPv6 adres van mijn mac toe te staan. Die vind ik in de iptables niet terug. (staat waarschijnlijk in een specifieke IPv6 tabel?)

De eerste 4 10.0.1.x adressen zijn van mijn macs en die staan als eerste en zouden dus altijd toegang moeten hebben. Ik zie hier ook geen reden tot de blokkade.

Regel 1 zegt me eigenlijk niets en regel 2 & 3 komen voor mij uit de lucht vallen.

Ik zie niet echt iets bijzonders aan de firewall.
Sorry voor de verwarring trouwens:

Code: [Selecteer]

iptables -vL --line-numbers was duidelijker geweest: met -v staat ook de interface erbij. Dan zie je waarschijnlijk dat regel 2 voor de loopback is.
Waarschijnlijk heb je 'DoS protection' aangevinkt, daar is regel 1 van.
Regel 3 is om eventueel bestaande connecties niet om zeep te helpen wanneer de firewall opstart.

Het viel me wel op dat pingen zal gaan lukken vanaf de eerste 4 10.0.1.x adressen.

Maar wat veroorzaakt het probleem dan? Het is alleen het eigen subnet wat niet goed werkt. Misschien een route die verkeerd staat in de NAS of een DNS die niet goed werkt?
Je zou met ip route, netstat, arp, nslookup etc. kunnen kijken of je iets raars ziet gebeuren

Voor IPv6 is er inderdaad 'ip6tables'

Citaat van: BartS op 09 november 2014, 23:36:13

met -v staat ook de interface erbij. Dan zie je waarschijnlijk dat regel 2 voor de loopback is.
Waarschijnlijk heb je 'DoS protection' aangevinkt, daar is regel 1 van.
Regel 3 is om eventueel bestaande connecties niet om zeep te helpen wanneer de firewall opstart.

Klopt als een bus. :D
Ik zie zelfs dat je per firewall rule ziet hoeveel data door die rule toegelaten is. Regel 8,9,10 zijn de IP adressen die Synology nodig heeft voor support, dan zie ik dus direct hoeveel data zij via telnet, ssh, poort 5000. bekeken hebben, of zie ik dat verkeerd?

Code: [Selecteer]

GedeeldeData> iptables -vL --line-numbers
Chain INPUT (policy ACCEPT 3855 packets, 768K bytes)
num   pkts bytes target     prot opt in     out     source               destination         
1      13M 7820M DOS_PROTECT  all  --  br0    any     anywhere             anywhere            
2     653K   64M ACCEPT     all  --  lo     any     anywhere             anywhere            
3      13M 7816M ACCEPT     all  --  any    any     anywhere             anywhere             state RELATED,ESTABLISHED
4    12733  857K ACCEPT     all  --  br0    any     10.0.1.60            anywhere            
5        0     0 ACCEPT     all  --  br0    any     10.0.1.61            anywhere            
6     4743  374K ACCEPT     all  --  br0    any     10.0.1.20            anywhere            
7     2959  208K ACCEPT     all  --  br0    any     10.0.1.22            anywhere            
8        0     0 ACCEPT     tcp  --  br0    any     59-120-41-39.HINET-IP.hinet.net  anywhere             multiport dports http,5000,ssh,telnet
9        0     0 ACCEPT     tcp  --  br0    any     118-163-30-16.HINET-IP.hinet.net  anywhere             multiport dports http,5000,ssh,telnet
10       0     0 ACCEPT     tcp  --  br0    any     125-227-152-103.HINET-IP.hinet.net  anywhere             multiport dports http,5000,ssh,telnet
11     162  9452 DROP       tcp  --  br0    any     anywhere             anywhere             tcp dpt:telnet
12       0     0 DROP       all  --  br0    any     81.18.240.0/20       anywhere            
13       0     0 DROP       all  --  br0    any     anywhere             anywhere             source IP range 89.248.170.8-89.248.171.127
14       0     0 DROP       all  --  br0    any     89.248.168.0/24      anywhere            
15       0     0 DROP       all  --  br0    any     93.174.88.0/21       anywhere            
16       0     0 DROP       all  --  br0    any     94.102.48.0/20       anywhere            
17       0     0 ACCEPT     tcp  --  br0    any     10.0.0.0/22          anywhere             multiport dports afs3-fileserver,9007,9008,8800,8801,8000,8001,9900,6690,smtp,smtps,imaps,50002,50001,domain
18       0     0 ACCEPT     tcp  --  br0    any     10.0.0.0/22          anywhere             multiport dports ldap,ldaps,9025:9040,afpovertcp,netbios-ns,netbios-dgm,netbios-ssn,microsoft-ds,sunrpc,892,nfs,5005,rsync,5000
19     534 49008 ACCEPT     udp  --  br0    any     10.0.0.0/22          anywhere             multiport sports 19997,65001,5004,rfe,netbios-ns
20    9431 1839K ACCEPT     udp  --  br0    any     10.0.0.0/22          anywhere             multiport dports bootpc,bootps,ntp,syslog,syslog,19998,1900,domain,65001,5004,rfe,5353,sunrpc,892,nfs
21       0     0 ACCEPT     udp  --  br0    any     10.0.0.0/22          anywhere             multiport dports 1234,9997,9998,9999
22       0     0 ACCEPT     tcp  --  br0    any     anywhere             anywhere             Source country: TW  tcp dpt:5000
23    1203 76356 ACCEPT     tcp  --  br0    any     anywhere             anywhere             Source countries: BE,NL  multiport dports afs3-callback,9901,6281,6690,smtps,imaps,ldap,ldaps,1723,ftp,55536:55539,5006,https,http
24      35  2168 ACCEPT     tcp  --  br0    any     anywhere             anywhere             Source countries: BE,NL  multiport dports 5001,5000,ssh
25       0     0 ACCEPT     udp  --  br0    any     anywhere             anywhere             Source countries: BE,NL  udp spt:19997
26       0     0 ACCEPT     udp  --  br0    any     anywhere             anywhere             Source countries: BE,NL  multiport dports tftp,19998,l2tp,4500,isakmp
27       0     0 ACCEPT     47   --  br0    any     anywhere             anywhere             Source countries: BE,NL 
28       0     0 ACCEPT     esp  --  br0    any     anywhere             anywhere             Source countries: BE,NL 
29       0     0 ACCEPT     ah   --  br0    any     anywhere             anywhere             Source countries: BE,NL 
30      25  1480 ACCEPT     tcp  --  br0    any     anywhere             anywhere             multiport dports smtp,smtps,submission
31       0     0 ACCEPT     udp  --  br0    any     anywhere             anywhere             udp dpt:1194
32    1118  208K DROP       all  --  br0    any     anywhere             anywhere            
33       0     0 ACCEPT     all  --  br0    any     anywhere             anywhere            

Chain FORWARD (policy ACCEPT 1834 packets, 320K bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain OUTPUT (policy ACCEPT 7082K packets, 381M bytes)
num   pkts bytes target     prot opt in     out     source               destination         

Chain DOS_PROTECT (1 references)
num   pkts bytes target     prot opt in     out     source               destination         
1       22  2100 RETURN     icmp --  br0    any     anywhere             anywhere             icmp echo-request limit: avg 1/sec burst 5
2        0     0 DROP       icmp --  br0    any     anywhere             anywhere             icmp echo-request
3        7   280 RETURN     tcp  --  br0    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/RST limit: avg 1/sec burst 5
4        0     0 DROP       tcp  --  br0    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/RST
5    27011 1723K RETURN     tcp  --  br0    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN limit: avg 10000/sec burst 100
6        0     0 DROP       tcp  --  br0    any     anywhere             anywhere             tcp flags:FIN,SYN,RST,ACK/SYN
GedeeldeData>

Ik heb de meeste problemen opgelost zodat het werkbaar geworden is. Ik denk dat het beter is als Synology dit probleem oplost. Dan kunnen ze de oplossing van dit probleem ook in een volgende update verwerken zodat anderen er ook wat aan hebben. Ik gebruik alleen Synology pakketten, dus iets in hun software heeft dit probleem veroorzaakt.

Citaat

Het viel me wel op dat pingen zal gaan lukken vanaf de eerste 4 10.0.1.x adressen.

Waar maak je dat uit op? Een ping vanaf die adressen werkt niet en ook een ping vanaf de nas naar die adressen werkt niet.

En het is inderdaad alleen het 10.0.1.x subnet van de nas. Mijn router hangt al jaren achter een andere router in het 10.0.3.x subnet. Apparaten in dat subnet kan ik wel pingen. Ik heb nu ook in Security Station het IP adres van de kameras vervangen door het WAN IP van mijn router (10.0.3.10) Nu ik de cameras via dat subnet benader, ziet de nas ze weer.

Het blijft natuurlijk vreemd dat het bij mij mis gaat en deze bug nergens anders gemeld wordt. Wat is bij mij anders. Ik weet wel dat ik een paar maand geleden een Wifi-dongel in de USB poort gestopt heb. Bij het aanmaken van de extra Wifi interface via DSM om de dongel als extra Wifi-accesspoint te kunnen gebruiken, zijn alle oude iptables gewist en waren mijn firewall rules weer leeg.

Dat was nog onder DSM 5.0 en is het enige wat misschien niet standaard is en wel met interfaces te maken heeft.

Citaat van: Briolet op 10 november 2014, 10:05:53

....Regel 8,9,10 zijn de IP adressen die Synology nodig heeft voor support, dan zie ik dus direct hoeveel data zij via telnet, ssh, poort 5000. bekeken hebben, of zie ik dat verkeerd?

Zoveel weet ik ook weer niet, dus dat kan ik je niet vertellen :D. Maar is telnet echt nodig voor Synology? Ik heb ze nooit meer dan 22 en 5000 hoeven geven. Op zich heb je telnet zo wel dichtgetimmerd, maar toch...

Citaat

Ik heb de meeste problemen opgelost zodat het werkbaar geworden is. Ik denk dat het beter is als Synology dit probleem oplost. Dan kunnen ze de oplossing van dit probleem ook in een volgende update verwerken zodat anderen er ook wat aan hebben. Ik gebruik alleen Synology pakketten, dus iets in hun software heeft dit probleem veroorzaakt.

Het wordt inderdaad wel een ingewikkeld verhaal... Het lijkt wel naar de NAS te wijzen, maar ik begin te vermoeden dat de firewall niet het probleem is. T.z.t. hoor ik natuurlijk graag wat Synology voor oorzaak heeft gevonden.

Citaat

Citaat
Het viel me wel op dat pingen zal gaan lukken vanaf de eerste 4 10.0.1.x adressen.

Waar maak je dat uit op? Een ping vanaf die adressen werkt niet en ook een ping vanaf de nas naar die adressen werkt niet.

Oeps, typefoutje. Ik bedoelde dat pingen naar de NAS zou moeten werken, maar alleen vanaf de 4 Mac's: voor de andere locale adressen staat er nergens ICMP of 'all protocol' open. Vandaar ook dat ik denk dat het probleem niet in de firewall zit.

Citaat

En het is inderdaad alleen het 10.0.1.x subnet van de nas. Mijn router hangt al jaren achter een andere router in het 10.0.3.x subnet. Apparaten in dat subnet kan ik wel pingen. Ik heb nu ook in Security Station het IP adres van de kameras vervangen door het WAN IP van mijn router (10.0.3.10) Nu ik de cameras via dat subnet benader, ziet de nas ze weer.

Ik gebruik Security Station niet, ik kan niet helemaal volgen wat je hebt gedaan. Heb je de camera's het adres van de router zelf gegeven, of heb je ze nu een adres gegeven in de 10.0.3.0 range?

Maar wat veroorzaakt het probleem dan? Het is dus alleen het eigen subnet wat niet goed werkt.
mDNS/Bonjour?: misschien omdat het broadcast/multicast address niet open staat?

Maar dan nog zou pingen van de NAS naar een 10.0.1.x adres moeten werken.
Toch een routeringsprobleem? Misschien toch de moeite waard om hier even naar te kijken met 'ip route' of 'netstat -r'? Misschien levert 'traceroute' ook wat interessants op.
En al geprobeerd om zonder de Wifi-dongle te starten (ik weet niet of dat veel werk is?)

Je zei dat het ook niet werkt als je de firewall helemaal uitzet: dat is eigenlijk nog wel een indicatie dat die niet het probleem is (waren toen wel alle caches en tables refreshed?)
Als je firewall problemen toch wilt uitsluiten zou je kunnen loggen welke packets allemaal gedropped worden. Laat maar weten, dan post ik een kleine instructie.

(Misschien ben ik een beetje paranoide, maar misschien beter je firewall instellingen van het forum te halen?)

Citaat van: BartS op 10 november 2014, 12:30:42

Ik gebruik Security Station niet, ik kan niet helemaal volgen wat je hebt gedaan. Heb je de camera's het adres van de router zelf gegeven, of heb je ze nu een adres gegeven in de 10.0.3.0 range? …
…
(Misschien ben ik een beetje paranoide, maar misschien beter je firewall instellingen van het forum te halen?)

De oplossing voor Security Station is een beetje off-topic.
In de nas stond de camera op 10.0.1.31 met poort 80
Nu heb ik er staan 10.0.3.10 met poort xxxx
Dat is de WAN kant van de router en via nat-loopback en port forwarding verbindt hij gewoon weer op de camera 10.0.1.31 en poort 80. Alleen de nas ziet de camera nu als zijnde in een ander subnet.

Voor de firewall regels is het inderdaad paranoïde om ze te verbergen.

Citaat

Maar is telnet echt nodig voor Synology? Ik heb ze nooit meer dan 22 en 5000 hoeven geven.

Ik weet het ook niet. Volgens hun mail wel:

Citaat

Remote Access Instructions
===============================================================
1. Standard Ports we need you to open: 23, 80, 5000
2. Please enable the TELNET and SSH function in Web Management of your Synology NAS. ([Network Service] > [Terminal] )

Vreemd is natuurlijk dat in regel 1 helemaal geen poort 22 genoemd wordt en in regel 2 willen ze wel SSH toegang. ;)

Er kloppen wel meer dingen niet. Ik heb gisteren de bugmelding gedaan. Via de nieuwe support instelling in DSM heb ik alvast een syslog gedownload. Dat was een 19 MB groot bestand dat ik aan de bugmelding toegevoegd heb. Volgens die pagina mag het attachment 30MB groot zijn, toch kwam de melding terug dat het attachment te groot was.
Dus later die dag heb ik de melding nog eens gedaan en zag in het berichten centrum dat de melding verstuurd is en door de grote belangstelling voor DSM 5.0 kon een reactie wel 3 à 5 dagen duren.
Volgens mij bedoelen ze DSM 5.1, en is deze melding zelf ook nog een bug. ;)

Ah ok, ik heb ook zoiets met loopback geknutseld voor OpenVPN: hoef ik het server adres niet aan te passen als ik lokaal wil testen.

Bij mij vonden ze SSH genoeg: blijkbaar verschillen de meningen daar.
En ach, wat kleine type-/update foutjes hier en daar... Zolang het maar niet in de config files is :D

Citaat van: BartS op 09 november 2014, 23:36:13

Je zou met ip route, netstat, arp, nslookup etc. kunnen kijken of je iets raars ziet gebeuren

Ik heb een traceroute gedaan:

Code: [Selecteer]

iMac-DDR2-2:~ briolet $ traceroute gedeeldedata.local
traceroute to gedeeldedata.local (10.0.1.30), 64 hops max, 52 byte packets
 1  * * *
 2  * * *
 3  * * *
^C

[hier heb ik mijn switch (Netgear SG108) gereset]

iMac-DDR2-2:~ briolet$ ping 10.0.1.30
PING 10.0.1.30 (10.0.1.30): 56 data bytes
64 bytes from 10.0.1.30: icmp_seq=0 ttl=64 time=0.334 ms
64 bytes from 10.0.1.30: icmp_seq=1 ttl=64 time=0.238 ms
64 bytes from 10.0.1.30: icmp_seq=2 ttl=64 time=0.216 ms
64 bytes from 10.0.1.30: icmp_seq=3 ttl=64 time=0.247 ms
64 bytes from 10.0.1.30: icmp_seq=4 ttl=64 time=0.217 ms
64 bytes from 10.0.1.30: icmp_seq=5 ttl=64 time=0.215 ms
64 bytes from 10.0.1.30: icmp_seq=6 ttl=64 time=0.237 ms
64 bytes from 10.0.1.30: icmp_seq=7 ttl=64 time=0.242 ms
64 bytes from 10.0.1.30: icmp_seq=8 ttl=64 time=0.228 ms
64 bytes from 10.0.1.30: icmp_seq=9 ttl=64 time=0.300 ms
64 bytes from 10.0.1.30: icmp_seq=10 ttl=64 time=0.278 ms
64 bytes from 10.0.1.30: icmp_seq=11 ttl=64 time=0.269 ms
64 bytes from 10.0.1.30: icmp_seq=12 ttl=64 time=0.261 ms
^C

--- 10.0.1.30 ping statistics ---
13 packets transmitted, 13 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.215/0.252/0.334/0.034 ms
iMac-DDR2-2:~ briolet $ traceroute gedeeldedata.local
traceroute: unknown host gedeeldedata.local

Het probleem lijkt toch niet in de nas gezeten te hebben, maar in mijn switch. Maar waarom mijn twee iMacs, die aan dezelfde switch hangen als de nas, wel volledig op het interne netwerk kunnen komen is mij onduidelijk.
En waarom is dit probleem ontstaan bij de update. En als het alleen aan de switch lag, waarom het security station gedurende een reboot wel kort toegang tot de interne cameras. Het moet toch iets te maken hebben met de manier waarop de nas de switch aanspreekt. (Als je naar Jumbo Frames overschakelt moet je ook altijd de switch resetten.)

Ik zie nu ook dat Cloud Station op mijn twee iMacs weer gaat synchroniseren. :P

Wat ik nog vreemd vind aan het traceroute commando, is dat hij bij de eerste keer het IP van de host vind, en na de reset, praat over een 'unknown' host.

Synology-Forum.nl

Firmware => Synology DSM 5.1 en eerder => Topic gestart door: Briolet op 08 november 2014, 12:27:04