Synology-Forum.nl
Synology Router => Synology Router => Topic gestart door: B3rt op 19 november 2015, 11:45:12
-
Heb de router sinds gisteren in huis en ben al enkele bugs tegen gekomen..
1.
forward regels: indien je een range wilt forwarden naar een lokaal IP dan kan je maar 1 destination poort ingeven....
bv range 1000 t/m 2000 wil je door sturen naar intern IP 192.168.1.2, je geeft dan naast het interne IP op de public ports range: 1000-2000, echter in de private range veld kan je maar 1 poort invullen, geen range of leeg laten.. Je moet dus 1000 regels gaan aanmaken...
2.
Firewall regel, als je hier een DOEL ip ingeeft wordt deze inkomen regel NIET door gestuurd naar het DOEL ip.
Voorbeeld, je wilt web verkeer (poort 80 en 443) door sturen naar je webserver op IP 192.168.1.2
Je geeft in: poort 80,443 afkomstig van ALLE ip adressen, DOEL IP: 192.168.1.2
Zodra je de firewall regel opslaat dan gaat je web verkeer nog steeds naar de eigen SRM of als je uPNP hebt aanstaan naar een willekeurig device in je netwerk wat poort 80 draait. Het zou eigenlijk naar het IP moeten gaan, maar dat gebeurd niet, je moet naast de firewall dus ook nog eens gaan portforwarden....
3.
(inkomende) VPN, je installeerd de VPN app, stelt alles in, deze werkt, je krijgt netjes verbinding maar vervolgens kan je niets je hebt geen internet.... Gebruik je dezelfde instellingen op je (synology) NAS en je verbind naar deze dan werkt alles wel.....
4.
Je kan niet je quickconnect ID van je NAS gebruiken, ook kun je niet inloggen met je synology account in SRM, je krijgt een connectie error, zo ook als je een support request instuurt.
Herkend iemand dit, weet toevallig een oplossing of work around (of toch instelling probleem)?
Ik heb uiteraard al een support ticket bij synology aangemaakt, geen idee hoelang het duurt voordat deze reageren.
-
1. Heb ik ook gemeld, wordt als het goed is in volgende SRM update gefixt
4. Quickconnect is per device naar mijn weten. Je maakt dus een nieuwe quickconnect aan binnen je huidige Synology account.
Ik kan overigens wel gewoon inloggen met Synology account en ticket aanmaken vanuit SRM.
-
Ik vindt 2 absoluut geen bug. In de firewall geef je aan dat verkeer op een bepaalde poort alleen naar een bepaald IP adres mag.
Als verkeer naar een ander IP gaat wordt het tegengehouden.
Dat extern verkeer ook naar een bepaald ip moet worden gestuurd is een functie van portforwarding en niet van de firewall.
-
MOD: Onnodige citaat is verwijderd, lees even. (http://www.synology-forum.nl/vragen-en-opmerkingen-over-het-forum/gebruik-de-citaatknop-met-mate-17838/)
Niet???
Situatie:
- ik wil dat ik vanaf 1 specifieke locatie(extern IP) poort 65003 kan benaderen (op mijn NAS), de rest van internet dus niet!
- maak ik dan alleen een firewall regel aan dat poort 65003 afkomstig van extern IP X naar internet IP Y moet, dan werkt dit weer niet..
- als ik een poort forwading instel van poort 65003 naar mijn intern IP kan IEDEREEN naar die poort verbinden, port forwarding overruled blijkbaar namelijk de firewall!
- maak ik een firewall regel dat alleen extern IP X toegang heeft tot die specifiiek poort aan maak dan een forwarder aan dat die poort naar dat interne ip Y moet dan werkt dat ook niet, de forwarder overruled namelijk blijkbaar weer de firewall met als resultaat dat iedereen er weer bij kan!
Maw je kan dus niet per IP of poort een firewall instellen, dit is dus zeer zeker wel een bug...
-
De laatste optie die je omschrijft zou inderdaad moeten werken. De firewall moet ook verkeer dat geforward wordt monitoren en filteren. Als dat niet zo is, is het een bug.
Maar dat is iets anders dan je oorspronkelijk beschreef. Daar geef je aan dat je wil dat de firewall ook het forwarden voor zijn rekening neemt, en dat kan niet.
Maar kun je in het forward scherm geen bronadres opgeven? In mijn router kan ik opgeven of alles van het internet op een bepaalde poort geforward wordt naar de interne machine, of alleen een specifiek internet adres dat die poort aanspreekt. Dus een source IP en destination IP.
-
dat dacht ik in begin ook, de forward rule gaat altijd voor in de router.
Dus ik dacht, dan moet je in de firewall regel dit als doel IP opgeven, dan heb je die forward regel niet nodig.
Maarja, beide werkt niet zoals het hoort...
Je kan dus niet iets forwarden en dat begrenzen van 1 specifiek IP...
Mijn VPN probleem is inmiddels ook 'opgelost', zodra je ipsec gebruikt werkt alles normaal, pptp maakt ie alleen verbinding maar kan je verders niets.... Gebruik dus nu maar ipsec :)
Maar dat de forwarders niet werken vind ik echt een DIKKE bug, hoop niet dat ze daar lang over doen om dat te fixen.
-
Ik wilde eerst mijn asus rt-ac68u vervangen voor deze router.
Maar ik houd het wel daar nog even bij met de Merlin firmware (tomato gaf rare bug).
En anders haal ik mijn alix bordje weer uit de kast met pfsense erop.
Het is verrekt jammer dat pfsense geen betere hardware ondersteuning heeft.
-
Alle beweringen die bovenaan worden genoemd als bug KLOPPEN NIET :!: :!:
Kennelijk nog net te weinig ervaring met de router hoe je het een en ander instelt of gebruikt.
Het is misschien een goed gebruik om eerst te kijken wat er reeds aan informatie op het forum voorhanden is, om zodoende onnodige onrust van andere (potentiële) gebruikers te vermijden. :ugeek: ;)
Alleen punt 1 het invullen van port forwarders, is niet zozeer een bug, maar had wel een stuk efficiënter gekund.
Daar is door mij en anderen al eerder op gewezen. Opmerking doorsturen van poorten zie < HIER > (http://www.synology-forum.nl/synology-router/1e-gebruikservaringen-synology-router-rt1900ac/msg172331/#msg172331) en < HIER > (http://www.synology-forum.nl/synology-router/1e-gebruikservaringen-synology-router-rt1900ac/msg172359/#msg172359) (+ vervolgreactie (http://www.synology-forum.nl/synology-router/1e-gebruikservaringen-synology-router-rt1900ac/msg172360/#msg172360)).
Firewall regels. Heb ik op een paar plekken wat over geschreven.
Misschien het meest uitgebreid en het makkelijkste te begrijpen, juist in combinatie met VPN, zie reactie < HIER > (http://www.synology-forum.nl/synology-router/vpn-verbinding-met-rt1900ac-als-vpn-server/msg173529/#msg173529) en vervolgreacties naar beneden (voor de Firewall) en ervoor voor resultaten met ALLE VPN-protocollen. Ook specifiek de opties om connectie met internet te hebben bij VPN.
Bij QuickConnect gebruik ik gewoon het ID wat ik reeds voor mijn NAS had ingesteld, (nog niet een nieuwe)
aangevuld met poortnummer :8000 om bij de router uit te komen. Idem de DDNS domein-service werkt als zodanig.
Zonder ingave van poortnummer kom ik uit op de webserver van mijn NAS (precies wat de bedoeling is).
De wijze van hoe poorten door te sturen en Firewall regels op te stellen zoals eerder in de reactie hierboven (http://www.synology-forum.nl/synology-router/diverse-bugs-gevonden/msg173972/#msg173972) geopperd, is een verkeerde werkwijze. Poorten doorsturen staat los van Firewall regels en andersom.
Wil je expliciet van één enkel extern IP de toegang geven tot je NAS op één poort, en niet van "al het internetverkeer",
kun je dat regelen met een goede invulling van Firewall regels.
Algemene uitleg hoe Firewallregels in te stellen zie < HIER > (http://www.synology-forum.nl/overige-software/firewall-correct-instellen/msg125496/#msg125496) met uitgebreide Jip- en Janneke voorbeelden bij vervolgreacties.
-
punt 1 is wel absoluut een bug hoor.
Het is nu simpelweg onmogelijk om 1 of meerdere specifieke poorten te forwarden voor enkel 1 of meerdere specifieke IP adressen zodat alle andere IP adressen geen toegang krijgen tot deze poorten.
Deze functionaliteit is toch echt een basis onderdeel van een firewall.
Zodra je nu een forwarder instelt staat deze open voor iedereen en deze kun je dus ook niet dicht zetten zonder de forwarder te verwijderen, je kan zeggen wat je wilt dat is een bug, helaas vind ik in jou artikel nergens terug hoe dit wel zou moeten werken.
Heb zelf veel ervaring met linux firewalls etc, wat ik omschrijf is een basic functionaliteit van elke firewall en dat kan hier niet. Als het wel kan dan is dit ERG onduidelijk en wordt niet tot nu toe nergens uitgelegd hoe, tenminste ik heb het nog niet kunnen vinden...
Punt 2 vond ik zelf ook al vreemd maar dit komt omdat punt 1 niet werkt en je andere manieren gaat zoeken om je firewall dicht te timmeren.
punt 3 had ik al eerder gemeld werkt inmiddels door eenvoudig een ander protocol te kiezen.
Blijft wel vreemd dat als je exact dezelfde VPN APP installeert op je NAS en exact deze instellingen gebruikt en dan daar naar toe verbind wel werkt en connect je naar de router dan niet, gebruik je een ander protocol werkt het probleemloos...
-
Nee hoor, je snapt de werking zeer duidelijk niet. Wel of geen ervaring met Linux, je bewering snijdt geen hout !!
Doorsturen van poorten staat verder helemaal LOS van Firewallregels om expliciet een bepaald IP-wel of geen toegang te verschaffen.
Omdat je je reactie redelijk snel achter die van mij hebt geplaatst, vermoed ik dat je (nog) niet de moeite hebt genomen de uitleg naar werkende oplossingen zoals eerder aangehaald hebt gelezen, bestudeerd en hebt uitgeprobeerd.
-
punt 1 is wel absoluut een bug hoor.
Het is nu simpelweg onmogelijk om …
Nee, zoiets is geen bug. Dan snap je niet wat een bug is: Een bug is een feature die niet werkt zoals hij bedoeld is.
Deze forwards werken gewoon zoals de programmeurs het bedoeld hebben.
-
ik had je stuk al eerder gelezen voordat ik de post heb gestart.
Kijk de forwarders zelf werken wel echter de firewall weer niet als een forwarder is ingesteld en dat hoort niet......
Wellicht zit de bug dan niet in de forwarder maar meer in de firewall, maar het feit blijft dat het nu onmogelijk is om 1 poort te forwarden en dat dan enkel voor 1 extern IP adres....
Ik zou zeggen probeer het zelf ook maar eens, het werkt gewoon niet en dat is volgens mij toch echt wel een bug en ik kan me niet voorstellen dat zoals de moderator zo leuk zegt 'bedoeld door de ontwikkelaar' bij design zo is, indien wel dan zou het nut van de firewall een stuk minder zijn..
Een firewall is er immers voor om regels in te stellen wat wel en niet mag en nu dus geen firewall regels aanmaken voor een forwarder en bij een forwarder kun je weer niet instellen dat deze enkel door een extern IP te gebruiken is.
Als jij zeker weet hoe dit wel werkt mag je mij dit dan uitleggen, zoals ik al zei in jou stukje lees ik nergens hoe je dus een port forwarding kunt instellen en deze enkel toegang geven vanaf 1 extern ipadres.
Ben erg benieuwd naar jou uitleg hoe dit dan zou moeten werken, want ik kan dit dus echt niet vinden.
-
Je beredenering klopt gewoon niet. Het is zuiver een kwestie van instellen.
Geef eerst eens wat meer informatie wat er aan modem/router vóór de RT1900ac zit.
Staat die in bridge-mode, of gebruik je wel het lokale LAN van die modem/router en heb je de RT1900ac bijv. in DMZ staan??
Wat heb je verder aan zaken achter je RT1900ac gehangen (o.a. een NAS begrijp ik)?
Wat wil je bereiken?
- 1. In ieder geval toegang vanuit je PC's aangesloten binnen je RT1900ac LAN neem ik aan?
- 2. VPN, welk protocol?
- 3. Wil jezelf van buiten alleen connectie via VPN of ook nog "gewoon" remote van je RT1900ac ?
- 4. En zoals ik denk te begrijpen van buiten uit enkel toegang voor één IP-adres voor een service die poort 65003 gebruikt.
Die service voor poort 65003 staat die op de NAS of geldt dat nog voor een ander apparaat?
- 5. Wil je nog andere services van buitenaf kunnen benaderen voor bijv. een NAS, XBOX e.d.?
Nog andere opties die ik vergeten ben?
-
het hangt achter een ziggo modem (bridge mode is helaas niet mogelijk, deze functie is uitgeschakeld door ziggo).
Hij heeft een (gereserveerd) DHCP adres en zit in een DMZ van het ziggo modem, uiteraard stat alles UIT op het ziggo modem, er zitten geen andere apparaten op aangesloten en ook geen firewall/forward regels ingesteld.
Wel dus de DMZ voor het IP adres van de synology router.
1. ca 30 apparaten, waaronder pc's, laptop's, rasperrypy, nuc, camera's tablets, telefoons, homeautomation en natuurlijk de synology NAS
2. VPN werkt inmiddels via ipsec protocol, bij PPTP kreeg ik alleen verbinding maar geen internet of LAN.
3. zoals ik al zei, via VPN werkt het al, maar ik wil ook 'gewoon' verbinding kunnen maken
4. Poort 65003 (maar zo zijn er nog veel meer poorten en diensten) dient verbinding te maken met inderdaad de synology NAS, niet met andere apparaten.
5. yep, ook de TV (streaming) en homeautomation
6. de firewall van de nas moet UIT blijven, daarvoor heb ik immers de router gekocht.......
De volgende applicaties op de NAS dienen toegankelijk te zijn vanaf specifieke IP adressen:
sabnzb 65000 en 65001
mailserver (poort 25, 2 verschillende IP's)
sickbeardb 65002
couchpotato 65003
SSH
de volgende diensten dienen voor iedereen te bereiken zijn (ook op de nas)
ftp (incl passive port range) 2121, 5666
webdav (5006)
survaillance station
cloud station
DSM (5001)
De nas zelf heeft ip 192.168.1.2 in het netwerk, de router 192.168.1.1 (lan) en 192.168.0.100 (wan)
Ben erg benieuwd wat je hiermee kunt...
-
Volgens <dit filmpje> (https://www.youtube.com/watch?v=dhQZGbXQsW8#t=481) (vanaf 7:15) kun je gewoon 1 IP toewijzen als bron voor de port forwarding, dus daarmee dien je de rest uit te kunnen sluiten. Als dat niet werkt lijkt het wel een bug.
Je geeft dan 1 IP vrij, maar als je de rest niet blokkeert dan kan ik me voorstellen dat lijkt alsof het niet werkt.
Heb je wel ingesteld dat als er niet aan de regel voldaan wordt dat toegang dan geweigerd wordt? Dat werkt tenminste zo op DSM.
Als je een range poorten forward en je laat de destination poort leeg dan werkt dat toch gewoon?
Enkel als je een poortwissel wilt doorvoeren vul je wat in.
-
het hangt achter een ziggo modem (bridge mode is helaas niet mogelijk, deze functie is uitgeschakeld door ziggo).
Even helpdesk ziggo bellen. Zij kunnen hem wel vanaf afstand in bridge modus zetten.
-
ja zoals dat filmpje, alleen laat ie alle IP adressen door zodra je een forwarder aanmaakt, ondanks je een firewall regel hebt aangemaakt dat ie maar 1 IP moet toestaan.
En ja, hij staat op weigeren onderaan en ja je hebt gelijkt zo werkt het in DSM (nas) maar helaas niet in SRM.......
En wat forwarden betreft, de regel mag niet leeg zijn, je moet dus een public EN private poort opgeven, laat je deze leeg kun je niet submitten. Daarnaast kun je de public port WEL ranges opgeven, dmv - of , te scheiden, echter bij private (de bestemming) kan je maar 1 enkele poort opgeven...... moet je bv in theorie 100 opeenvolgende poorten forwarden dan moet je dus 100 forward rules aanmaken.
-
@Robstar
AL zo vaak voor gebeld, doen ze simpelweg niet. Sterker nog, ik heb dat zelfs als 'issue' voor opzeggen uitstaan bij de afdeling retentie/opzegging bij ziggo, maar helaas ze doen het niet. (belachelijk, maar goed is op dit moment niet anders)
Als reden geven ze op dat dit niet mogelijk is bij een zakelijk ZZP connect abonnement, je moet volgens ziggo dan upgraden naar MKB, wat ruim 20,00 per maand duurder is of downgraden nr consument (met verlies van vast IP) OF andere aanbieder kiezen (en in mijn regio is er geen alternatief qua (upload) snelheden).....
-
En wat forwarden betreft, de regel mag niet leeg zijn, je moet dus een public EN private poort opgeven, laat je deze leeg kun je niet submitten. Daarnaast kun je de public port WEL ranges opgeven, dmv - of , te scheiden, echter bij private (de bestemming) kan je maar 1 enkele poort opgeven
En als je dan alleen de start poort van die range als destination opgeeft, zet hij dan niet de rest automatisch liniair door?
-
@B3rt Daar was ik niet van op de hoogte. Heb zelf mijn modem afgelopen juli in bridge modus laten zetten door Ziggo, maar ik heb geen zakelijk abonnement. Vreemde beredenering dat het bij een zakelijk abbo niet mogelijk is.
-
Ik denk wel dat synology een hoop dingen gaat aanpassen in updates.
En neem aan dat een range poorten open zetten er ook wel in gaat komen.
Bijna elke router ondersteunt dat dus synology kenende komt dit er wel.
Ik wacht wel wat versies af.
-
@Robbedoes
Nee, de private range port is een verplicht veld.
Als je deze leeg laat dan wordt ie rood als je op submit klikt met een error melding dat die niet juist is.
Als je een comma of streep wilt ingeven dan doet ie niet, deze worden niet geaccepteerd.
Je kan dus enkel 1 getal ingeven.....
Ik heb het forward probleempje tijdelijk opgelost op de volgende manier:
- de router in DMZ op het ziggo modem en dan mijn hele netwerk incl de NAS
- de NAS (heeft 4 eth aansluiten) ook op de ziggo modem/router en in het ziggo modem de poorten geforward die voor de NAS bedoeld
Deze setup werkt voor nu goed, maar hopelijk komt er een oplossing uiteindelijk dat je dit ook in de router kunt regelen.
-
Even tussendoor.
(Na eerst een diner wat later op de avond).
Naar aanleiding van de eerdere vragen vandaag van @B3rt kroop ik opnieuw achter de router en weer driftig aan de gang met instellingen.
Ik kon ze ook allemaal bewerkstelligen. Mooie screendumps gemaakt, en alles voorbereid. Maar dat heb je nog tegoed.
De meeste services die @B3rt gebruikt kan ik niet controleren omdat ik ze zelf niet gebruik.
Maar ja, ik had toch een testcase nodig of het ook werkelijk allemaal klopt,
dus ging met een paar eigen services aan de gang, en die werkte ook netjes zoals bedoeld.
(Ik ga morgen vanuit een andere locatie van "buiten uit" verder testen. Met een smartphone met telkens wisselend IP ging dat vervelend).
Ik ben echter wel enkele kleine "interpretatie"-verschillen tegengekomen tegenover de instellingen van Firewall-regels in een NAS.
Maar wel begrijpelijke verschillen, waar je echter wel rekening mee moet houden met wat je gewend bent in vergelijking bij die van een NAS.
Het belangrijkste verschil is dat je bij benadering van de router vanuit een LAN-netwerk, jezelf "niet kunt buitensluiten" bij ondoordacht ingestelde Firewall regels. Bij zo'n ondoordachte instelling in een NAS is het in het vervelendste geval noodzakelijk om de NAS te resetten (https://www.synology.com/nl-nl/knowledgebase/tutorials/493).
Waarna Firewall regels worden uitgeschakeld, en instellingen van een admin teruggaan naar de standaardwaarde.
Dat is bij de Synology router dus niet aan de orde.
Zelfs benadering naar de RT1900ac vanuit de eerste modem/router als die niet in bridge-mode staat en dan typisch een IP-adres met "LAN" signatuur doorgeeft, naar de WAN-poort van de Synology router, is kennelijk een signaal dat men een gebruiker nooit buitensluit.
Je kunt de router dus altijd vanuit een LAN benaderen, ongeacht de Firewall instellingen :!: :!:
De achterliggende gedachte is wellicht dat een router doorgaans is afgestemd om internetverkeer door te laten. Typisch aan internet gerelateerde poorten als poort 80 (8080) en 443 met achterliggend een web-interface worden niet tegengehouden. Zelfs als het via een omweg vanuit een andere poort (8000, 8001) uiteindelijk tot een "webpagina" wordt getransformeerd, krijgt men ook een web-interface te zien van SRM.
Die "andere" benaderingswijze maakt dat men geen Firewallregels voor typisch web-gebaseerde protocollen hoeft op te nemen
Vandaar dat ik ze standaard ook niet tegenkom als je achterliggende services in Firewall-regels gaat instellen.
Om die reden had ik ze zelfs dan maar handmatig erbij gezet. (Zie eerdere opmerking daarover < HIER > (http://www.synology-forum.nl/synology-router/1e-gebruikservaringen-synology-router-rt1900ac/msg172333/#msg172333) ).
Heb je een NAS achter de router hangen, en zijn poorten doorgestuurd naar de NAS om die eventueel van buiten uit te benaderen, is het ook daar niet nodig de typische "doorstuur-poorten" 5000 en 5001 dan ook nog in Firewallregels op te nemen als service.
Voor alle niet web-based protocollen geldt dat echter wel.
Of die "andere" benaderingswijze om web-based protocollen binnen Firewall-regels niet meer op te nemen, nu zo'n verstandige keus is, moet nog worden bezien. Ik moet er nog wat verder op testen. Als bijv. een NAS (met poort 5000/5001) dan niet meer gefilterd wordt op regio-gebied binnen Firewall-regels, is dit IMO een verkeerde benadering. Men kan het dan wel weer verder in de NAS zelf afblokken, maar een meer consequent beleid tussen verschillende apparaten heeft mijns inziens toch de voorkeur.
Verder heeft de Firewall wat extra instellingen tegenover die welke in een NAS gebruikt, waarbij services / poorten expliciet voor bepaalde LAN-IP adressen gefilterd kunnen worden (SRM, een specifiek IP, range van IP adressen of compleet LAN netwerk).
Een en ander wat @Robbedoes eerder aanhaalt < HIER > (http://www.synology-forum.nl/synology-router/diverse-bugs-gevonden/msg174048/#msg174048).
Aangemaakte Firewall-regels kan men zelf benoemen (als korte tekst), zodat makkelijker te herkennen is waar het betrekking op heeft.
-
Ik vindt het wel een beetje vreemd hoor. Want bij een firewall geldt dat jij bepaald wat je door wilt laten, niet de fabrikant van je router. En als jij web verkeer wilt blokkeren, moet dat gewoon kunnen. Ik ken genoeg firewall configuraties waarbij men alle web verkeer wil blokkeren omdat de internet toegang niet gewenst is. Dit zou voor mij al een reden zijn om de router niet aan te schaffen.
Als ik dit lees dan zou ik echter eerder denken dat er een fout in de firewall zit, hij filtert intern web-verkeer niet.
Als ze web verkeer niet tegenhouden in de firewall zouden ze dat zeker moeten vermelden in de handleiding.
Ik zou hiervoor in ieder geval een ticket aanleggen bij Synology.
-
Ik vindt het wel een beetje vreemd hoor. Want bij een firewall geldt dat jij bepaald wat je door wilt laten, niet de fabrikant van je router. En als jij web verkeer wilt blokkeren, moet dat gewoon kunnen.
Dat ben ik helemaal met je eens.
Ik denk dat de gebruikersmarkt waar men zich met deze router op mikt, men dat teveel voor de "eenvoudige" gebruiker wil "bijsturen".
Maar het heeft verdergaande consequenties, zelfs voor verkeer "van buiten". Ik ben er inmiddels achter (via een 3G connectie vanuit een smartphone), dat als de Firewall van de achterliggende NAS uitstaat, en je in de router geen Firewallregels voor toegang voor extern verkeer hebt toegelaten (en al het overige verkeer van buiten dan zou moeten worden afgeblokt), je voor wat betreft de "web-based" protocollen, (dus ook DSM via poort 5000/5001) nog steeds bij DSM van je NAS kunt komen. Dat is onacceptabel.
(Eerder merkte ik het niet op, omdat de Firewall van de NAS nog aanstond en daarin wel consequent werkt, en het daar opgevangen werd).
Dat is mogelijk datgene wat @B3rt ook heeft opgemerkt, wat toch wel onder de noemer gezien kan worden als "bugs".
Een excuus van mijn kant naar hem is dan ook op zijn plaats, want ik deed dat te gemakkelijk af als dat de Firewall wel correct zou werken.
Verdergaand;
De toegang voor SRT (het OS van de router) kun je dan wel hebben uitgeschakeld, en daar geen toegang voor hebben, het is inconsequent voor erachter liggende apparaten. En zelfs ook in die functie van wel of niet uitschakelen van connectie met SRT van buitenaf zitten een paar sturende elementen, die niet consequent werken als je daar van afwijkt.
Vanuit Netwerkcentrunm -----> Beheer -----> SRM-instellingen kun je een instelling maken om wel of geen toegang van buitenaf naar SRT te maken. (In het menu helemaal onderaan).
[attach=1]
Als je bij de Firewall nog niets hebt ingesteld, worden vanuit het inschakelen van die functie twee extra Firewallregels aangemaakt in het menu van de Firewall (Netwerkcentrunm -----> Beveiliging -----> Firewall). Eentje voor http, de ander voor https.
[attachimg=2]
Desgewenst kun je die toegang van buitenaf voor "Alles" dan nog veranderen voor een regio-filtering.
In onderstaand geval voor Nederland. (Alles wat er buiten valt, wordt de toegang dan ontzegd).
[attachimg=3]
Opnieuw uitschakelen van toegang van buitenaf door het vinkje in dat eerste menu bovenaan, is dan keurig netjes gekoppeld met die twee Firewall-regels. Die zijn dan ook uitgevinkt.
[attachimg=4]
Maar let op !!!
Als je reeds zelf Firewallregels had aangemaakt, anders benoemd, voor meerdere protocollen tegelijk en er tevens die van poort 8000 en 8001 had bijgezet, en de twee extra door SRT aangemaakte Firewallregels dan overbodig zijn, en weghaalt, is de koppeling verbroken met die functie in het menu helemaal bovenaan bij Beheer en SRT van buitenaf inschakelen / uitschakelen.
De stand van dat vinkje maakt dan niets meer uit. Het werkt volgens de regels die jezelf "afwijkend" hebt ingesteld.
Kun je die functie beter weglaten. Het is dan alleen maar verwarrend als je niet netjes volgens de richtlijnen die functies inregelt zoals Synology je het voor je had bedacht.
(Of om verwarring te voorkomen, beter exact de procedure volgen van Synology, en van daaruit de andere Firewallregels aanmaken).
-
Het resultaat van de Firewall van de RT1900ac blijkt nog veel meer bizar te zijn dan gedacht :!: :!:
In de volgende set-up heb ik bewust achterliggende web-based protocollen niet ingeschakeld.
Alleen VPN-connectie en daaraan gerelateerde protocollen.
(Met het verschuiven van de menu's binnen de Firewall-regels komen nog een aantal services naar boven die me nog op andere tests attendeerde om die ook eens te gebruiken.). De Firewall van de achterliggende NAS heb ik uitgeschakeld.
[attach=1]
Feitelijk zou ik alleen connectie mogen hebben via VPN, maar heb die bewust NIET benut in de volgende tests.
Gewoon de "normale" manieren van benadering.
Wat heb ik via mijn smartphone via het 3G mobiele netwerk en Android apps wel- of niet kunnen bewerkstelligen.
- GEEN connectie met het SRM van de router (dat klopt met functies van uitgeschakelde toegang van buitenaf voor SRM)
Maar dan bizar :!: :!:
- Een WERKENDE connectie met het DSM van de NAS
- Een WERKENDE connectie met de NAS via DS File
- Een WERKENDE connectie met de NAS via DS Audio
- Een WERKENDE connectie met de NAS via DS Photo+
- Een WERKENDE connectie met de NAS via een browser op de smartphone naar de web-server op de NAS
Benadering van SRM via het interne LAN + gebruik internet-browser
- Een WERKENDE connectie naar de router met SRM gebruiksinterface
- Een WERKENDE connectie via SRM met de SD-geheugenkaart en aangekoppelde USB harddrive.
Benadering van de router via de verkenner van de PC onder Netwerk
- Een WERKENDE connectie met de SD-geheugenkaart en aangekoppelde harddrive.
Benadering van de NAS via het interne LAN
- Een WERKENDE connectie via een internet-browser met de webs-server op de NAS
- Een WERKENDE connectie via een internet-browser met Photo Station op de NAS
- Een WERKENDE connectie via een internet-browser + DSM Audio Station op de NAS
- Een WERKENDE connectie via een internet-browser + DSM File Station op de NAS
Benadering van de NASvia de verkenner van de PC onder Netwerk
- Een WERKENDE connectie met de achterliggende shares.
En wellicht werken ander services ook gewoon die ik nu niet in gebruik heb.
Het lijkt erop dat Synology een heel stuk vergeten is in de ontwikkeling van de firmware.
-
@Babylonia ik begreep dat jij je ziggo modem niet in bridge had maar alles geforward?
Of heb ik het nu verkeerd.
-
dat is dus ongeveer hetzelfde wat ik meld.
Je forward regels gaan VOOR de firewall regels, dus als je een forward regel aanmaakt wordt er verder geheel niet meer gekeken naar je firewall instellingen, ook al blokkeer je deze voor iedereen of 1 specifiek IP adres.
Dit heb ik zo ook gemeld aan synology vanmorgen als reply op een ticket wat ik gisteren heb aangemaakt.
Maar we zijn het erover eens dat dit niet wenselijk is, ik noem dit een bug ;)
Wat ziggo modem betreft:
Die staat niet bridged, maar routed. De synology router staat in de DMZ.
Wel heb ik een uurtje geleden telefoon gehad van Ziggo klanten service wegens mijn uitstaande klacht.
Ze gaan mijn modem (als zeer hoge uitzondering) in bridge mode zetten vanmiddag, als ik vanavond thuis kwam moest ik mijn modem een factory reset geven en dan ging die vanzelf in bridge mode. Moet dan de IP adressen handmatig instellen op de router.
-
en idd logisch want als je alles van je ziggo forward of dmz dan heeft je synology een intern ip.
Dus gaan al die externe ip's die je wilt blokkeren niet werken.
want je synology ziet dan alleen maar intern ip binnen komen.
En een router achter een router dmv nat gaat zo echt niet goed werken.
edit dit ff snel gegoogled
http://www.allesoverdraadloosinternet.nl/draadloze-router/draadloze-router-aansluiten-op-ziggo-upc-modem/
-
@spikehome
Ik heb een glasvezel account + Telfort Experiabox voor de RT1900ac zitten, geen Ziggo.
Je forward regels gaan VOOR de firewall regels, dus als je een forward regel aanmaakt wordt er verder geheel niet meer gekeken naar je firewall instellingen, ook al blokkeer je deze voor iedereen of 1 specifiek IP adres.
Zo zou de Firewall IMO toch niet bedoeld zijn. Je kunt namelijk expliciet regels opstellen voor de functies bedoeld in de router zelf, een expliciet LAN-adres (achter de router), een range aan LAN IP-adressen of het gehele LAN.
Wat heeft het dan voor zin als dat overruled wordt met een port forward?
Zonder port forward komen services niet op hun plek uit en is een firewallregel voor die service overbodig om naar een intern LAN IP-adres te verwijzen. Of zie ik iets over het hoofd?
-
@spikehome
Ik heb een glasvezel account + Telfort Experiabox voor de RT1900ac zitten, geen Ziggo.
Ok maar die is ook een wifi ap en roteert verkeer dus die moet ook dan in bridge
zie b.v. http://experiabox-bridge-modus.weebly.com/telfort-vdsl--adsl.html
-
Ik schreef het verkeerd..
ik schreef"
Je forward regels gaan VOOR de firewall regels, dus als je een forward regel aanmaakt wordt er verder geheel niet meer gekeken naar je firewall instellingen, ook al blokkeer je deze voor iedereen of 1 specifiek IP adres.
Maar bedoelde:
Je forward regels gaan nu VOOR de firewall regels, dus als je een forward regel aanmaakt wordt er verder geheel niet meer gekeken naar je firewall instellingen, ook al blokkeer je deze voor iedereen of 1 specifiek IP adres.
De bedoeling van een firewall is dat je alle in en uitgaand verkeer kunt filteren, dus de firewall regels dienen voor je forward regels te gaan. Dus als je in je firewall een DENY zet op poort 5555 en diezelfde poort 5555 is ook geforward dan dient deze alsnog te worden tegengehouden.
Als ik vanavond thuis kom kan ik als het goed is het Ziggo modem omzetten in bridge, dit ga ik doen en dan ga ik nogmaals testen of de regels dan wel/niet werken. Echter de situatie is wel een beetje gewijzigd want ik krijg schijnbaar nu 5 publieke IP adressen ipv 1
Ik ga dus nu 1 publiek IP toewijzen aan de router en 1 aan de NAS die ik ook direct aan het modem ga hangen.
De NAS komt met eth1 in mijn LAN en via eth4 direct met publiek IP aan het modem.
Op deze manier hoeft de router ook niet alle inkomende mail/web/download verkeer van mijn NAS te managen, valt om wat voor reden 1 van de 2 apparaten uit kan ik altijd nog op mijn netwerk komen via VPN die ik activeer op beide apparaten.
-
De bedoeling van een firewall is dat je alle in en uitgaand verkeer kunt filteren, dus de firewall regels dienen voor je forward regels te gaan. Dus als je in je firewall een DENY zet op poort 5555 en diezelfde poort 5555 is ook geforward dan dient deze alsnog te worden tegengehouden.
Precies, zo had ik dat in gedachte dat het als zodanig zou (moeten) werken.
-
Zo werkt een 'normale' firewall in de praktijk ook.
Als je dit via iptables via de commandline doet dan werkt dit ook zo.
-
klein tekening als voorbeeld.
zie bijlage
-
ander vraagje..
Kan jij via laptop (wifi) via netwerk andere apparaten zien in je netwerk?
Ik kan bv op de laptop geen enkel apparaat meer vinden sinds ik deze router heb.
De NAS vind ie niet, ga ik direct via de verkenner erheen //192.168.1.2 dan krijg ik ook een connectie error.
Zodra ik een kabel (utp) in de laptop duw en via bedraad netwerk zoek vind ie ze wel.
Is dit ook een regel/instellingen ergens?
-
@B3rt
Zie ook mijn laatste post het topic 'Probleem met netwerkdevices'.
-
Je forward regels gaan VOOR de firewall regels, dus als je een forward regel aanmaakt wordt er verder geheel niet meer gekeken naar je firewall instellingen, ook al blokkeer je deze voor iedereen of 1 specifiek IP adres.
Op zich is dat wel hoe het zou werken als je alles binnen de firewall instelt. Als de firewall een treffer heeft, stopt hij met verder checken. Dus als je in de firewall instelt om poort 80 voor alle IP adressen door te laten en verderop maak je een regel aan op een bepaald IP altijd te blokkeren, dan wordt dat IP toch doorgelaten op grond van de eerdere regel.
Maar ik ben het er mee eens dat forwards onafhankelijk van de firewall regels moeten werken. Een forward is nml. geen firewall regel.
-
ander vraagje..
Kan jij via laptop (wifi) via netwerk andere apparaten zien in je netwerk?
Ik kan bv op de laptop geen enkel apparaat meer vinden sinds ik deze router heb.
EDIT:
Vraag verkeerd begrepen. Als ik na het weekend thuis ben zal ik via WiFi kijken of ik in Netwerk de andere apparaten zie.
----------------------------------------------------------------------------
Met de app "Fing" (https://play.google.com/store/apps/details?id=com.overlook.android.fing&hl=nl) zie ik alle apparaten die binnen het netwerk zijn aangesloten en actief online zijn.
Maar ook in de router zelf onder Netwerkcenter -----> Locaal netwerk -----> DHCP Clients
vind ik de apparaten waar ik (eerder) contact mee heb gehad.
Overigens ben ik nu elders, en probeerde toen vanuit een Laptop contact te maken met de RT1900ac
Dat lukte aanvankelijk niet. Omdat de Firewall instellingen nog stonden zoals eerder in een schermafdruk weergegeven, dat alleen een VPN-verbinding actief was ingeschakeld, heb ik met mijn smartphone via VPN en de app < "DS Router" > (https://play.google.com/store/apps/details?id=com.synology.dsrouter&hl=nl) de Firewall aangepast.
Daarna kon ik wel via de "normale" weg in de router inloggen.
Dus met benadering via PC / laptob "lijken" de geldende Firewall instellingen die ik eerder had gedaan wel functioneel.
De verschillende resultaten in benadering via een PC of smartphone zijn me eerder ook al opgevallen bij het zoeken naar de juiste instellingen voor VPN, waarvoor extra instellingen gedaan moesten worden voor een positief resultaat voor een Windows PC, en het met een smartphone eerder al direct werkte.
Zal er dezer dagen vanuit locatie elders nog eens verder op testen.
@spikehome
Een set-up m.b.t. bridge is me bekend.
Alleen met de laatste Telfort/KPN firmware upgrade van hun Experiabox V8 modem/router gelden de eerdere "onofficiële" opties die op fora circuleerden om in bridge te zetten niet meer. Opties die ik heb geprobeerd zijn niet succesvol verlopen. Daarmee verlies ik telefonie en TV-signaal.
(Zie eerste regel van mijn onderschrift, in dat geval echter net andersom om van twee WiFi punten gebruik te kunnen maken).
-
@B3rt
(Ben nog niet thuis), maar herinner me ineens een specifieke situatie m.b.t. WiFi.
Via netwerk, naast de eigen apparaten zelfs nog andere onbekende apparaten.
Was een bericht voor in de "lounge", < zie dit bericht > (http://www.synology-forum.nl/the-lounge/'ghost'-devices/)
-
@B3rt
Ik weet niet of jij je set-up nog via een bridge-mode van de eerste modem/router hebt kunnen bewerkstelligen, maar bij mij (waar het vooralsnog NAT achter NAT is, omdat bridge vooralsnog niet mogelijk is), lijk ik het spoor volledig bijster te zijn voor wat betreft Firewall instellingen. Het heeft een zodanig effect dat ook de Firewall-instellingen van de erachter hangende NAS niet goed meer functioneren.
Nu wordt eerder door o.a. @spikehome geopperd dat NAT achter NAT niet zou kunnen werken omdat de RT1900ac dan alleen verkeer vanuit een "intern LAN" aangeboden krijgt, maar zo werkt dat IMO niet als zodanig. Verkeer van buiten uit wordt alleen "doorgestuurd", maar blijft zijn classificatie houden van een "externe" verbinding.
Mijn oude situatie waarbij mijn NAS achter een enkele modem/router hing, was per per definitie een aansluiting met LAN IP-adres.
Daarbij werkte de Firewall van de NAS correct als zodanig.
Dus of nu een RT1900ac achter een eerste modem/router zou hangen (niet in bridge, achter een LAN) met dan een Firewall of voorheen een NAS achter een modem/router met Firewall, lijkt me weinig verschillend te zijn. Beide zitten in dat geval in een LAN IP netwerk.
In de logboeken van zowel de router als de NAS wordt ook gewoon verschil gemaakt met benadering / inloggen van "buiten uit", (ik krijg het IP-adres te zien, waar ik nu op een andere locatie aanwezig ben en krijg ook de eerdere inlog-sessies te zien van de IP-adressen uitgegeven via mijn mobiele 3G netwerk of via VPN-verbinding). Als de verschillende connecties als zodanig worden herkend zou dat IMO ook door de Firewall moeten worden herkend, en de nodige acties moeten worden ondernomen afhankelijk van de instellingen (doorlaten of blokken).
Kun jij {of Ben(V) }daar nog iets aan informatie aan toevoegen?
-
Het Source Adres is altijd genoemd in het Ethernet pakket, anders kan hij nooit meer terug gestuurd worden naar degene die via het internet jouw NAS bezoekt.
Heb je het IP van de de 1900RT in de DMZ instellingen van je ADSL/VDSL modem gezet? Dan hoef je namelijk maar op 1 plek portforwarding uit te voeren, alleen op de Synology.
Wat gaat er " mis " in jouw NAS firewall rules, dat maakt het verhaal niet echt duidelijk?
-
Je forward regels gaan VOOR de firewall regels, dus als je een forward regel aanmaakt wordt er verder geheel niet meer gekeken naar je firewall instellingen, ook al blokkeer je deze voor iedereen of 1 specifiek IP adres.
Dit heb ik zo ook gemeld aan synology vanmorgen als reply op een ticket wat ik gisteren heb aangemaakt.
Maar we zijn het erover eens dat dit niet wenselijk is, ik noem dit een bug ;)
De bedoeling van een firewall is dat je alle in en uitgaand verkeer kunt filteren, dus de firewall regels dienen voor je forward regels te gaan. Dus als je in je firewall een DENY zet op poort 5555 en diezelfde poort 5555 is ook geforward dan dient deze alsnog te worden tegengehouden.
Naar aanleiding van verder opvolgende testen met de Firewall regels die mijns inziens nogal tegenstrijdige resultaten opleveren en waarvan de praktische uitwerking afwijkt met de Firewall regels gebruikt in een NAS, waarbij diezelfde regels WEL als zodanig goed werken, had ik ook een ticket ingelegd.
Hier het antwoord van Synology:
Developers already checked this issue, unfortunately this is software limitation at the moment. This is because Router behavior is defined port forwarding as a higher priority, so if you setup port forwarding rules, the related firewall rules will not take effect. As a temporary workaround, we will suggest to add firewall rules on NAS, and we will support this function in the future SRM release, we apologize for the inconvenience.
If you have any great suggestions or feature requests, please kindly send them to our Product Management group at:
https://www.synology.com/en-global/form/inquiry/feedback
Best Regards,
Jason Ren
Deze handicap is voor gebruikers dus erg belangrijke informatie, omdat de werking beslist NIET datgene oplevert wat vergelijkbare Firewall regels van een NAS WEL opleveren.
In het kort de instellingen beschreven < zoals ze eerder bijv. voor een NAS functioneel werken> (http://www.synology-forum.nl/overige-software/firewall-correct-instellen/msg125496/#msg125496), met name voor wat betreft de beperkingen voor een regio, pakken NIET als zodanig uit voor de RT1900ac router voor al het verkeer wat met Port Forwarders wordt doorgestuurd naar achterliggende apparaten.
Feitelijk heeft het überhaupt geen zin Firewall regels in de router op te nemen voor alles wat van buiten binnenkomt en wordt doorgestuurd naar achterliggende apparaten. Dat moet je dus regelen in het achterliggende apparaat.
Voor typische zaken die NIET worden doorgestuurd, maar "tot en met de router komen", geldt het echter wel.
Dus bijv. wel voor het op afstand benaderen van de gebruikersinterface SRM van de router zelf, en geïnstalleerde pakketten die op de router zelf draaien zoals een VPN-server, en File Station op de router (als benadering van de SD-geheugenkaart of aangekoppelde USB-drive).
Babylonia@
-
ok iig wat duidelijkheid nu.
overigens kan je poorten testen met deze site of ze wel goed dicht zijn.
https://www.grc.com/x/ne.dll?bh0bkyd2
-
Geen bug maar wel een missende optie (die er volgens de help functie wel zou moeten zijn):
Enable WMM QoS: Wi-Fi Multimedia (WMM) QoS (Quality of Service) over Wi-Fi. This option allows the wireless network to prioritize traffic and optimize how resources are shared among applications.
Ik kan deze optie niet vinden, wie wel?
-
Ik vind deze optie niet in de Handleiding (http://global.download.synology.com/download/Document/UserGuide/SRM/1.0/Syno_UsersGuide_RouterRT1900ac_nld.pdf). :S
(Heb zelf geen RT dus kan niet kijken ;) )
-
Ik heb even een screenshot van de ingebouwde help functie gemaakt. Wellicht is het een toekomstige optie!?
-
Geen bug maar wel een missende optie (die er volgens de help functie wel zou moeten zijn)
Dan is het toch een bug in SRM of SRM Help die je moet melden ;)
Maar, wacht even af wat anderen zeggen.
-
Overigens, het staat ook in de Product Sheet:
[attachimg=1]
En is ook vrij standaard voor hedendaagse Routers dus, ik verwacht dat het een bug is of je kunt het echt niet vinden. ;)
-
Netwerkcenter -----> Verkeerbeheer
Bij de tab "Algmeen" kun je direct op de icoontjes klikken en daar opties mee instellen.
uitgebreid of simpel: Hogere prioriteit / Lagere Proriteit.
Voorbeeld: Alleen hogere prioriteit is ingeschakeld. Dat zie je dan aan de geactiveerde blauwe kleur met pijltje omhoog.
[attachimg=1]
Bekijk de verschillende opties bij Geavanceerd -----> Bewerken
Lees goed de Help-bestanden hoe de beste instellingen te benutten m.b.t. de bandbreedte die ter beschikking is en hoe je dat verdeelt over de verschillende apparaten.
[attachimg=2]
Nagekomen naar aanleiding van getoonde schermafbeelding Help-bestanden door @Joopr instellingen WiFi.
Bij het betreffende menu "Draadloos", klap simpel "het pijltje" naar beneden voor meer geavanceerde opties.
[attachimg=3]
-
@Babylonia: Je hebt nu wel je WiFi wachtwoord op het forum gezet ....
-
Heb het afgedekt ;)
-
Beetje verwarrend dus:
Product Sheet: Toepassingslaag QoS
Handleiding: Verkeerbeheer
SMR Help: WMM QoS
SMR zelf: Snelheid
-
Het zal in SRM 2.0 een stuk beter zijn denk ik. Als ik nog aan alle fouten in de help / interface van DSM 2.x denk ......
-
Developers already checked this issue, unfortunately this is software limitation at the moment. This is because Router behavior is defined port forwarding as a higher priority, so if you setup port forwarding rules, the related firewall rules will not take effect.
Deze handicap is voor gebruikers dus erg belangrijke informatie, omdat de werking beslist NIET datgene oplevert wat vergelijkbare Firewall regels van een NAS WEL opleveren.
Als je een firewall in je router maakt moet die natuurlijk wel op de router functioneren. Juist bij poortforwarding.
Het is nu gewoon een DMZ forwading op een bepaalde poort en dat maakt het als geheel onbruikbaar.
Je wilt immers naar meer apparaten in je netwerk kunnen forwarden dan alleen naar de NAS functie.
-
Het zal in SRM 2.0 een stuk beter zijn denk ik. Als ik nog aan alle fouten in de help / interface van DSM 2.x denk ......
De verwarring m.b.t. QoS zit misschien meer in de termen die men gebruikt, waarbij men vrij eenvoudige begrippen hanteert om het dataverkeer te regelen. In het gebruik vind ik de onderdelen waar een en ander is ondergebracht een prima volgorde hebben, en overzichtelijk.
Vanuit de grafische interface kun je zo zien welke apparaten een hogere prioriteit hebben, ofwel "voorrang" hebben in dataverwerking dan andere apparaten.
-
Als je een firewall in je router maakt moet die natuurlijk wel op de router functioneren. Juist bij poortforwarding.
Dat ligt helemaal aan de toepassing. Op mijn Ubee router gaan de firewall settings wel boven de forwarding regels, maar daar baal ik juist van. Effectief komt het er bij mij op neer dat ik de firewall op de router geheel uit moet zetten omdat hij anders ingrijpt op mijn forwards. Zelfs op de DMZ worden de firewall regels toegepast, terwijl dat juist een zone moet zijn zonder beperkingen. (DMZ op een mainframe staat voor DeMilitarizedZone, dus zonder restricties)
Blijkbaar heeft Synology de verkeerde keus gemaakt voor sommige gebruikers. En uit de reactie van Synology maak ik op dat ze deze volgorde instelbaar gaan maken zodat hij voor iedereen bruikbaar wordt.
-
Bij Firewall regels vóór de forwarding zou je voor de Synology router in ieder geval meer kunnen regelen, omdat er nu reeds instellingen zijn om de Firewallregels te laten gelden voor enkel verkeer tot de router, een achterliggend apparaat waar men specifiek het IP-adres kan opgeven, bereiken, of het complete LAN "erachter".
Alleen die verdeling nu werkt erg verwarrend, als men een port forwarding heeft gebruikt, want dan is de regel domweg niet meer geldig. Wordt overruled door de port forwarding.
-
De verwarring m.b.t. QoS zit misschien meer in de termen die men gebruikt
Uiteraard echter, in de Handleiding en SMR zelf kunnen ze natuurlijk blijven benoemen QoS:
Handleiding: Verkeerbeheer (QoS)
SMR zelf: Snelheid (QoS) of beter: Verkeerbeheer (QoS)
Daarbij is QoS wel een begrip in de wereld van Routers 8)
Maar goed, documenteren en dan nog eenduidig zijn blijft "moeilijk" en kan zeker verwarrend zijn, het bewijst is geleverd ;)