Portforwarding naar NAS als VPN werkt niet meer sinds update naar V10.C.25.08.15

Beste ​@Survue zie onderstaande link voor een mogelijke oplossing:

Succes

Hoe staat de firewall beveiliging in de v10? Na een software update kan deze wat strikter zijn dan voorheen. Probeer “Standaard”.

Beste JanD en Edu2020,

Dank voor jullie reacties. Uiteraard heb ik de instructies voor port forwarding gelezen en conform gebruikt. Ik heb de beveiliging ingesteld op “middel”, daarna “standaard” zonder resultaat.

Ik heb ook de router teruggezet naar fabrieksinstellingen om eventuele issues met eerdere instellingen te voorkomen. Tot nu toe alles zonder het gewenste resultaat.

Kun je een schermafdruk plaatsen van de poortforwardings? 

Hoi ​@Survue, welkom op onze community! Ik heb hier zelf niet veel kaas van gegeten maar ik zie dat ​@Edu2020, ​@JanD en ​@Marlon92 al goed meedenken. In principe zou het met de stappen uit het kennisbankartikel wel op te lossen moeten zijn.

Beste Thomas, dank voor je aanmoediging. Wellicht kun het probleem bespreken met een collega die hier wel kaas van lust. Het lijkt erop dat de update van de V10 een issue oplevert voor portforwarding. De aanwijzingen in het kennisbankartikel (en ook andere) hebben, althans bij mij, niet het gewenste resultaat.
Tot het moment van de update werkte mijn OpenVPN verbinding met mijn Synology NAS prima. Ik heb nog steeds de hoop/verwachting dat dit probleem met de Experia V10 opgelost kan worden.

 

Hier staat niet alles op. Heb je geen groter scherm? Of even uitzoomen in de browser?

Welke poortchecker gebruik je dan? De meeste kunnen alleen TCP controleren en jij hebt de OpenVPN alleen op UDP staan (en geforward).

We zien inderdaad net niet alles op de screenshot.

Ik heb de poorten gecontroleerd met portchecker.com (geen UDP), dnschecker.org en youhetsignal.com. 

ping.eu controleert expliciet TCP: gesloten…..

Op welke poort geeft die TCP: gesloten? Poort 443?

Voor poort 1194 heb je TCP niet open staan. Alleen UDP (die dus niet getest wordt).

Met 443 TCP zou je dus kunnen testen of port-forwarding wel goed werkt.

Portforwarding naar poort 443 gaat prima. Als ik poort 1194 open voor UDP en TCP blijkt de poort open…

Als ik met ipvoid.com alle poorten controleer zie ik diverse udp-poorten open, maar 1194 blijft dicht. Heel vreemd.

Heb je de NAS al herstart en het dan verkregen IP adres vastgezet? 

En dan poort 1194/UDP forwarden naar dat IP adres. 

De standaard instelling van OpenVPN is poort 1194 UDP, dat moet in de setup van de NAS te vinden zijn.

UDP is moeilijk of niet  te controleren met poort checkers. Het correcte gereedschap om verbinding met OpenVPN te controleren is OpenVPN.

Meestal is er wel een log te vinden, als daarin steeds mislukte verbindingsprogingen te zien zijn, of SSL/TLS fouten is er geen verbinding mogelijk. 

Voor zover ik weet werkt port forwarding naar OpenVPN op de  V10.

Beste hmmsjan_2,

Uiteraard heb ik dat allemaal gedaan. Tot vrijdag (update router software) werkte alles prima. En kon ik met OpenVPN een verbinding opzetten. 

Ik heb een V10 met firmware versie V10.C.25.08.15 en ben momenteel vanaf een externe locatie  ingelogd op mijn OpenVPN server via IPv4, poort 1194/UDP.  De firmware zou dus in orde moeten zijn.  

Er kan iet geks aan de hand zijn met de router, wat misschien met een reset naar fabrieksinstellingen op te lossen is, of er is iets anders aan de hand. 

Anders eens proberen om in de NAS een andere poort te kiezen en zien of het op die andere poort werkt? Meestal zijn die poorten instelbaar op server en client.

Ik heb complete reset gedaan, naar fabrieksinstellingen en standaard beveiliging. Open poort 1194 voor UDP. En doe port check. Zie udp poorten  open behalve. 1194. Heel vreemd

Welke port checker heb je gebruikt en welke poorten? Dat wil ik ook hier wel eens testen. Was dat direct na reset? Ik verwacht dan dat alle TCP en UDP poorten gesloten zijn, behalve misschien een die door KPN voor beheer gebruikt wordt. 

De  “nmap” scanner geeft (getest tussen 2 linux systemen) 

Firewall open en OpenVPN actief : 1194/udp open 
Firewall DROP:    1194/udp open filtered 
Firewall REJECT:  1194/udp closed 
Firewall open en  OpenVPN niet actief: 1194/udp closed

Aangezien de router inkomende firewall op “DROP” staat, zal deze scanner voor UDP  ALLE poorten als “open/filtered” weergeven, omdat hij geen antwoord terugkrijgt en  dus niet kan beoordelen wat er aan de hand is. 

“Closed” betekent dat een “port unreachable” of “admin-prohibited”  melding terugkomt en dat de firewall wel openstaat maar op de ontvanger geen bijbehorende service draait.

Dus of de OpenVPN service op de NAS draait niet of op een andere poort,  of OpenVPN komt op het verkeerde systeem terecht. Dat kon bij de oude firmware gebeuren als handmatig IP adressen ingesteld worden,  bij de nieuwe is mij dat niet bekend.

U zou kunnen proberen op de NAS handmatig een adres in te stellen buiten het DHCP gebied, bijv. 192.168.2.240 netmask 255.255.255.0 of /24, gateway en DNS 192.168.2.254. Dan de DHCP reservering verwijderen en de port forwarding aanpassen. Bij mij werkt dat.   

Overigens: nmap stuurt speciale pakketten naar poort 1194 om OpenVPN tot antwoord te dwingen,  maar geeft ook “open/filtered” (plus opmerkingen in de server logs)  als OpenVPN  WEL draait maar de “tls-auth” optie + sleutel bevat. Vandaar mijn opmerking dat OpenVPN de enige test is om verbinding met OpenVPN te testen. 

Daar is niks vreemds aan. UDP kun je niet scannen met een poortscanner. Ik gebruik wireguard. Dat is ook UDP. Er is geen enkele poortscanner die de poort open ziet staan. Toch werkt het prima.

Ik gebruikte ipvoid.com/udp-port-scan. 

Dan gebruikt ipvoid.com dus ook het programma “nmap” als backend, dat de resulaten dus technisch correct naar buitengewoon verwarrend weergeeft. Dir betekent dat alle poorten dicht (“filtered”) staan behalve openvpn. OpenVPN staat open maar er is geen contact met een OpenVPN server.

Of het probleem in de router zit of erbuiten kan ik niet beoordelen, maar in ieder geval is port forwarding ingesteld op 1194/udp. 

How Nmap interprets responses to a UDP probe

​@Survue  Zijn er misschien wijzigingen in het Wan-IP (of DDNS) die aanpassingen noodzakelijk maken in je openvpn client file?