Skip to main content

Kan het zijn dan KPN poorten blokkeert vanaf Internet richting mijn glasvezel aansluiting? En dan bedoel ik niet op de Experiabox oid maar binnen hun eigen infra?

Ik draai een OpenVPN server op een pfSense (al maanden) achter een Experiabox die ik dmv de DMZ functionaliteit ALLE verkeer richting de pfSense stuur.

Dit werkt perfect, met alle diensten/poorten etc. 

Echter merk ik sinds kort dat ik vanaf buiten UDP poort 1195 (waar ik altijd OpenVPN op draaide) ineens niet meer werkt. 

Packet captures laten zien dat er geen verkeer binnen komt. Bouw ik de configuratie om naar TCP 1195 dan werkt het wel.  Ook elke andere willekeurige UPD of TCP poort gekoppeld aan de OpenVPN server (inclusief firewall rules) werken vlekkeloos.  Het lijkt dus niet in de pfSense of OpenVPN config te zitten.

Ook testen vanaf server op internet m.b.t of de poort beschikbaar geeft alleen voor 1195 FILTERED aan terwijl alle andere poorten die ik gebruik OPEN zijn. 

The state is either open, filtered, closed, or unfiltered. Open means that an application on the target machine is listening for connections/packets on that port. Filtered means that a firewall, filter, or other network obstacle is blocking the port so that Nmap cannot tell whether it is open or closed. 

Misschien dat KPN monitoring toepast en misschien iets van misbruik heeft gedetecteerd (kan niet inzien wat ik gebruik het alleen voor benaderen thuis netwerk) en de betreffende protocol/poort dicht zet? 

Ik heb het getest vanaf diverse locaties met een eigen internet lijn, via mobiel/hotspot maar ook daar zit het niet in.

 

Ha @Telfort4Life, interessante vraag! Ik weet hier inhoudelijk niet zoveel van, maar voor zover ik weet, blokkeren wij niets. Wellicht kan @wjb, of een ander communitylid, hier iets over zeggen!


Ik draai al sinds jaar en dag een OpenVPN server op mijn Synology NAS zodat we overal ter wereld gebruik kunnen maken van de iTV app van KPN. (Mijn dochter woont in Zuid Afrika en wil ook graag "Wie is de Mol" kijken. :wink: )

Deze draait op UDP poort 1194 (de standaard voor OpenVPN) en dat geeft (uiteraard) geen problemen.

Het onderstaande screenshot toont een OpenVPN verbinding vanaf een Ziggo locatie naar mijn Synology thuis.

 

KPN zal dat ook niet blokkeren omdat zij dat wettelijk niet mag blokkeren.

Ik denk dus dat je de oorzaak toch elders zult moeten zoeken.

Wat zegt deze port-scanner over UDP poort 1195 (?) op jouw IP adres.


Als ik met nmap een portscan doe op 1195 UDP aan rechtstreeks op de WAN interface van de pfSense krijg ik de volgende resultaten:
PORT     STATE         SERVICE
1195/udp open           rsf-1

Kortom de pfSense staat goed. 

Doe ik vanaf internet een UDP scan op 1195 krijg ik  Open|filtered

 

 


Ik heb speciaal voor jou zowel UDP poort 1194 als UDP poort 1195 geforward naar mijn OpenVPN server op mijn Synology NAS.

De poort scanner geeft op UDP poort 1194 het onderstaande resultaat …

... terwijl op UDP poort 1195 het onderstaande resultaat gegeven wordt.

Mijn OpenVPN server is dan ook prima op UDP poort 1195 te benaderen.

Verwijder ik de port-forwarding voor UDP poort 1195 dan blijft het resultaat Open | filtered maar dan kan ik (uiteraard) geen verbinding meer opzetten.

Wat ik hiermee wil zeggen is dat die UDP scanners geen betrouwbaar resultaat geven.


Voor het testen van connecties simpel vanuit command promp  (CMD) Windows 

 

Commando pingen van destination server

Ping IPaddress + Poort  (voorbeeld:     Ping 88.999.87.01 1195) 

 

Dit zegt echter alleen dat de destination server socket (socket = ip + poort nummer combinatie) bestaat en gebruikt wordt in die combinatie. Je kan zelf specifiek ping met protocol UDP (User Datagram Protocol) of TCP (Transmission Control Protocol) waar ik TCP connectie Protocol had verwacht in combinatie van SSL Protocol voor VPN verbindingen, wat de connectie juist veilig maakt.

 

Commando telnet, connectie maken met destination server via TCP (telnet remote connecties staat sowieso uit bij destination server maar Error geeft meer inzicht).

Telnet IPaddress + poort (voorbeeld:     Telnet 88.999.87.01 1195)

 

Error zal iets in de richting van ....

connection refused (verkeerd protocol),

connection failed (verkeerde poort nummer) of

no route to destination (verkeerde socket).

 

Dit is alleen maar goed, betekend dat de firewall zijn ding doet op server niveau van destination.

 

Traceroute commando geeft route weer alle servers, routers of andere apparaten die verbinden kunnen opbouwen of forwarden voordat connectie destination server bereikt.

 

Tracert IPaddress     (voorbeeld:    tracert 88.999.87.01)

Geeft traceroute weer van de connectie. Bij tunnel connectie naar VPN server (of VPN thirdparty provider or VPN server gateway van private network van bedrijf werkzaam)  zou je eigenlijk niet veel kunnen mogen zien. Het hele idee erachter is een tunnel opzetten tussen source machine en VPN server zonder hobs te maken zoals traditioneel connecties over internet gemaakt worden.

 

 

 

UDP = User Datagram Protocol wat data in de vorm van pakketjes verstuurd naar destination host zonder te weten wat er gebeurt met die pakketjes bijeenkomst host.

 

TCP = Transmission Control Protocol wat per byte streams data naar destination host verstuurd waar te zien met tcpdump of de data daadwerkelijk aankomt. Alleen TCP connectie protocol maakt een zogeheten handshake voorafgaande van het maken van een connectie tussen beide partijen (clients, servers, laptops, ect). Als de connectie gerealiseerd kan data over de lijn gestuurd worden.


Voor het testen van connecties simpel vanuit command promp  (CMD) Windows 


Commando pingen van destination server

Ping IPaddress + Poort  (voorbeeld:     Ping 88.999.87.01 1195 )

Pingen op een poortnummer kan niet.  --->  "Bad parameter”
Alleen via telnet.  Maar niet via het UDP protocol.  Telnet is een TCP gebaseerde tool.
OpenVPN gebruikt standaard het UDP protocol.

Trace naar een IP adres zegt verder ook niets over de poorten m.b.t. VPN.


De Beste scanner daarin is dus NMAP. 

Zoals aangegeven klopt de pfSense config, zeker omdat ik een device rechstreeks aan de WAN heb gehangen van de pfSense. 

De Experia box forward alles dmv de DMZ functie. 

Ik begrijp niet waar het mis gaat. 


En als je probeert aparte port forwarders voor de services die je gebruikt in de plaats van DMZ ?
Misschien loopt dat beter?  Er zijn in het verleden wel meer problemen vastgesteld met de DMZ functie (Experia Box V8 - Telfort firmware).


Ik heb dit probleem verder niet meer onderzocht en besloten om maar op andere poorten te gaan draaien.

Echter: nu blijkt poort 80 van WAN naar LAN niet meer te werken. Deze heb ik eens in de zoveel maanden nodig voor het vernieuwen van let's encrypt certificaten en dat werkt nu niet meer.

Een online portscanner geeft ook aan dat de poort filtered is.

Ik gebruik de DMZ functionaliteit van de Experia box. Dus alles van WAN naar 192.168.100.50. (pfsense)

Doe ik een portscan in het zelfde netwerk (vanaf 192.168.100.10) richting de WAN interface van de  pfsense (192.168.100.50) dan geeft hij aan dat de poort open staat .

Ik heb alle NAT en Firewall rules uit de experiabox gegooid, DMZ uit/aan gehad, NAT rules voor poort 80 aangemaakt etc. Maar er komt gewoon NIETS door de Experiabox heen. Je kan er verder ook niets in monitoren dus het blokkeren kan ik ook niet zien.

Ik heb nog een oude experiabox, maar kan ik deze omruilen voor een andere? Want dit is dramatisch en ben er behoorlijk klaar mee. Geen idee wanneer hij ermee gestopt maar enige tijd geleden deed hij het nog wel. Herstarten, resetten niets werkt. 


Ha @Telfort4Life, interessante vraag! Ik weet hier inhoudelijk niet zoveel van, maar voor zover ik weet, blokkeren wij niets. Wellicht kan @wjb, of een ander communitylid, hier iets over zeggen!

Kun jij wellicht een andere Experiabox sturen?


Ha @Telfort4Life, welke Experia Box heb jij? Wil je ook je forumprofiel aanvullen met je adres, klantnummer en de laatste 4 cijfers van je rekeningnummer? Dan ga ik kijk wat ik voor je kan doen.


Ha @Telfort4Life, welke Experia Box heb jij? Wil je ook je forumprofiel aanvullen met je adres, klantnummer en de laatste 4 cijfers van je rekeningnummer? Dan ga ik kijk wat ik voor je kan doen.

 

Ik heb mijn gegevens aangevuld, de rest via PB aangezien ik mijn bankrekeningnummer niet in mijn profiel kan aanvullen. 


Dank! Ik zie dat je een V8 hebt: die is zeker aan vervanging toe. Er komt een nieuwe Experia Box naar een PostNL punt bij jou in de buurt. In jouw geval betekent dat de Albert Heijn in jouw wijk. Je krijgt een sms wanneer deze voor je klaarligt. Dat zal vermoedelijk dinsdagmiddag zijn. Je V8 mag je in een doos stoppen en meenemen: die lever je namelijk direct in. Laat je nog even weten hoe het nieuwe modem bevalt?


Het is mooi dat er sites zijn waar je kunt scannen of een poort open is op de router. Jammer is dat het nogal een kunst is de resultaten te interpreteren. Programma dat op de achtergrond gebruikt wordt kan "nmap" zijn,

nmap geeft bij UDP "open/filtered"  als het geen terugmelding heeft gekregen. Dat zegt dus weinig.

nmap geeft "closed" als het een ICMP melding terug krijgt dat er geen programma op die poort luistert. Voorwaarde om zo'n melding te krijgen is, dat op de router de poort OPEN staat. Anders zou het achterliggende apparaat geen melding sturen.

Dus alleen bij UDP: zowel "Open" als "Closed"  is een indicatie dat de poort op de router open is, open/filtered geeft hier geen informatie over. 

 

 

 

 

 

 

 


Ik gebruik de DMZ functionaliteit van de Experia box.

Dank! Ik zie dat je een V8 hebt: die is zeker aan vervanging toe. Er komt een nieuwe Experia Box naar een PostNL punt bij jou in de buurt.

DMZ met een Experia Box V8 is (was) altijd al een probleem geweest. Daar kon je niet van op aan. Indertijd gebruikte ik om die reden aparte port forwarders voor achterliggende services.
Dat werkte wel stabiel.

Hopelijk dat het probleem wat je ervaart daarmee nu ook is opgelost.


Nou, vandaag de nieuwe Experiabox ontvangen. Wat een ELLENDE!!!!

Blijkbaar kan je de DHCP scope niet aanpassen, mijn netwerk achter de pfsense zit in het zelfde subnet als de Experiabox. Hoe haalt KPN het zich in zijn hoofd om een dergelijke functie uit te schakelen!! Helemaal gek geworden. Hier op het forum blijkbaar 2 jaar geleden melding van gemaakt, update zou komen maar nog altijd is deze functie niet beschikbaar.

Ik heb een behoorlijk netwerk achter de pfsense zitten, maar de boel even omnummeren is er niet bij...…

Zucht....kon ik maar weer terug naar de V8. 


Een Experia Box V10 is nog wel om te nummeren in LAN IP bereik.

Vraag de Box 12 (?) om te ruilen voor de V10.


Aanvullend:

Ik heb een behoorlijk netwerk achter de pfsense zitten, maar de boel even omnummeren is er niet bij...…

Zucht....kon ik maar weer terug naar de V8. 


Configureer Pfsense voor directe connectie achter glasvezel zonder gebruik KPN modem/router.

https://gathering.tweakers.net/forum/list_messages/2076232