Firewall: OpenVPN Hits blijft oplopen zonder een verbinding te hebben.

[Babylonia]

Vind elders wel een typische melding op een forum m.b.t.   4daexxxx.ftth.telfortglasvezel.nl   maar dan met een ander nummertje ertussen.

https://forum.telfort.nl/wifi-269/smtp-telfortglasvezel-nl-48324#post432422

"Mijn hostname (dat kunnen jullie vast herleiden tot een ip-adres) is 4daeyyyy.ftth.telfortglasvezel.nl"

EDIT:
Naar aanleiding van bericht @MMD ook bij mij die nummertjes maar even vervangen door xxxx en yyyy.

[Birdy]

Zegt mij niets @Babylonia

Overigens, ik heb SSH nooit aanstaan, vanmiddag dus wel ff, gelijk zat er een Koreaanse rakker aan de deur te rammelen (kreeg mailtjes binnen van de Router) en is nu geblokkeerd forever



Blokkeren werkt in ieder geval 

( SSH is weer uit )

[Babylonia]

Die meldingen zeggen mij ook niets.  Ik wachtte eigenlijk een beetje af met wat jij vond.   
Met dat kijken in de root (??) of SSH Telnet sessies, dat is te lang geleden dat ik me met zoiets bezig hield,
dus weet niet meer "hoe die kaas smaakt".  (Als alternatief op "daar heb ik geen kaas van gegeten").

[Pippin]

Code: [Selecteer]

xxxxx.ftth.telfortglasvezel.nlis je externe adres, ff weghalen uit de berichten.

Beter dan

Code: [Selecteer]

tcpdump port 1900is

Code: [Selecteer]

tcpdump -n -i any port 1900Foutje van mij, het is mogelijk dat andere apparaten in je netwerk SSDP doen.

[Pippin]

Doelpoort 1900 blokkeren op alle interfaces en geen hits meer?

Nog geprobeerd?

[Babylonia]

Ik heb poort 1900 binnen het lokale Open VPN VLAN netwerk nu even geblokkeerd, en dat werkt dan inderdaad dat er geen hits meer zijn.

Ter informatie (niet in het plaatje), het "normale" LAN netwerk heeft al ver boven de 2400 hits (die lijken zelfs sneller op te lopen).
De Firewall regels zijn nu zodanig opgesteld, dat  EERST  poort 1900 binnen het OpenVPN VLAN netwerk wordt geblokkeerd (= deny).
De opvolgende regel dat alles binnen het eigen OpenVPN VLAN netwerk mogelijk is.   (Ik gebruik andere IP reeksen dan @Birdy ).
Omdat die eerdere regel er aan vooraf gaat, in dat geval poort 1900 uitgezonderd. (Die is al weg gefilterd).



Nog niet getest wat het inhoudt voor mijn media-server.  (Vermoed eigenlijk niets, want dat speelt zich af in het normale LAN).

EDIT:
Inmiddels uitgetest met media-server.  Geen problemen gevonden.
Ook een OpenVPN verbinding vanuit mobiele telefoon geen problemen.

Als resumé. Men zou de bovenste Firewall regel zoals in het plaatje weergegeven er nog bij kunnen voegen om het "netjes" volgens de regels gesloten te houden zonder "hits" als er geen VPN-verbindingen actief zijn.

[Babylonia]

Het leek zo mooi, maar nu worden bij een actieve OpenVPN connectie (vanuit mijn smartphone) binnen het menu van de Firewall helemaal geen hits meer weergegeven. Ook niet voor de OpenVPN service zelf.

En het wordt nog vreemder als ik die ene poort 1900 Firewall regel weer uitschakel (zodat je feitelijk op de oude situatie zou uitkomen).
Actieve "hits" laten zich nu niet meer zien. (Dus die blijven nu op 0 staan, zowel voor het VLAN als voor de regel met de OpenVPN service zelf.
OpenVPN verbinding is nu bovendien onbetrouwbaar.  De eerste keer wel een verbinding, erna niet meer voor "alle internetverkeer".
Wel verbinding met het profiel voor alleen een VPN-verbinding "met de server" (aangekoppelde HD's).

Dus die poort 1900 doet op een of andere wijze achterliggend toch vreemde dingen.

Ik ga gewoon weer even terug naar de oude situatie en geef een reboot. Kijk later wel een keer verder.

[Birdy]

Code: [Selecteer]

xxxxx.ftth.telfortglasvezel.nlis je externe adres, ff weghalen uit de berichten.

Beter dan

Code: [Selecteer]

tcpdump port 1900is

Code: [Selecteer]

tcpdump -n -i any port 1900Foutje van mij, het is mogelijk dat andere apparaten in je netwerk SSDP doen.

-- ff weghalen: done.
-- tcpdump -n -i any port 1900 Ga ik nog doen later.

Doelpoort 1900 blokkeren op alle interfaces en geen hits meer?

Nog geprobeerd?

Ga ik nog doen later.

Kortom, ik kom erop terug........... tx !

[Birdy]

tcpdump -n -i any port 1900

Code: [Selecteer]

SynologyRouter> tcpdump -n -i any port 1900
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes
23:09:58.343861 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:09:58.343892 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:09:58.343923 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:09:58.343767 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:09:58.344579 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 337
23:09:58.344611 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 337
23:09:58.344611 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 341
23:09:58.344642 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 341
23:10:01.344749 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:01.344843 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:01.344749 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:01.345218 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 337
23:10:01.345249 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 337
23:10:01.345249 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 341
23:10:01.345280 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 341
23:10:04.345544 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:04.345606 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:04.345638 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:04.345544 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:04.346044 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 337
23:10:04.346075 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 337
23:10:04.346075 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 341
23:10:04.346075 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 341
23:10:08.365389 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:08.365451 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:08.365482 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:08.365514 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:08.365389 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:08.365732 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 337
23:10:08.365732 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 337
23:10:08.365763 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 341
23:10:08.365763 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 341
23:10:11.379647 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:11.379710 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:11.379741 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:11.379741 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:11.379647 IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
23:10:11.379960 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 337
23:10:11.379991 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 337
23:10:11.379991 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 341
23:10:11.379991 IP 192.168.1.1.1900 > 192.168.1.7.60531: UDP, length 341
^C
41 packets captured
42 packets received by filter
0 packets dropped by kernel


Doelpoort 1900 blokkeren op alle interfaces en geen hits meer?

Test: geen hits meer op OpenVPN UDP

[Babylonia]

Weet niet of in mijn situatie de eerdere meldingen kwamen door mogelijk achterliggend minder logische instellingen??

Specifiek voor mijn situatie (dat hoeft voor een ander dus niet te gelden):
Met diverse reboots, en controle van menu's, kwam ik aan een actief openstaande VPN "Client" verbinding (als instelling in de router).
Omdat vanuit de SMART WAN de Interface priority VPN niet de hoogste prioriteit heeft, was die VPN verbinding praktisch gezien niet actief doorgezet. (Is afhankelijk van o.a. Policy Route instellingen onder Smart WAN). De VPN Client instellingen stonden daarbij zodanig dat opnieuw een verbinding geforceerd wordt opgezet met elders wanneer er een onderbreking in de connectie is geweest (door reboot, storing e.d.).

Heb wat aanvullende aanpassingen gedaan zodat een VPN Client niet automatisch opstart.  (Als je geïnteresseerd mocht zijn in die functies om naar keuze selectief apparaten via de VPN Client functies in de router een VPN te laten opzetten met een server elders, zie draadje < HIER>).

Inmiddels ben ik gewoon weer terug bij de oude situatie, zonder een "deny" Firewall regel voor poort 1900.
Reboots van zowel router als PC.

Afgezien van de hits binnen het eigen LAN netwerk, kom ik eerlijk gezegd nu helemaal geen hits meer tegen als er een VPN connectie wordt gemaakt. Niet onder het VLAN, niet als VPN service. Ongeacht of het om OpenVPN gaat of L2TP/IPSec.

In het Overview menu van de VPN Plus interface kom ik evenwel wel actieve VPN-verbindingen tegen bij testen met een smartphone.
Tevens worden de verbindingen gelogd, en kom ik ze tegen in de geschiedenis van de connecties.

Voor testdoeleinden wel regels voor VPN - PPTP ingesteld, maar doorgaans is PPTP uitgeschakeld. (Geen vinkje).
Verder zijn er in deze situatie VPN-servers actief voor 3 verschillende VPN methoden. (Met PPTP erbij 4).
Vandaar de opeenstapeling van Firewall regels. (Kan ze daarmee makkelijk selectief uit- en inschakelen).

[Birdy]

@Babylonia
Bovenstaande, voegt, volgens mij, niet zoveel toe aan mijn Topic, of ik zie het niet helemaal.

Echter, wat ik wel zie bij jou:


En zie bij mij (waar dit Topic overgaat):


Jij hebt geen hits, komt dat soms omdat jij VLAN hebt/gebruikt ?

[Babylonia]

Elk Virtueel VPN IP subnet is in feite een "VLAN" (Virtual Local Area Network).
Alleen hangen ze er bij Synology geen VLAN ID nummertjes aan. Maar ze zijn wel degelijk actief. Kijk bij VPN Plus onder "Object",
en je vindt de subnets die actief zijn, zijnde je gewone LAN netwerk, je gast netwerk, en de subnets m.b.t. VPN.
Omdat ik die Firewall regels zelf heb aangemaakt, heb ik er die benaming aan gegeven.

Verder:
Binnen de Firewall regel heb ik het IP subnet open gesteld voor zowel TCP als UDP, net zoals dat geldt voor het "gewone" LAN netwerk, omdat binnen dat subnet zelf naar ik vermoed diverse datastromen kunnen lopen die zowel TCP als UDP kunnen zijn?
(De Synology router is met een webbrowser tevens te benaderen met een IP-adres gerelateerd aan elk van die VPN subnets).
Jij hebt bij dat VPN subnet alleen het UDP protocol toegankelijk gemaakt. (En blokt ook alleen 1900 als UDP).

Alleen de datastromen van het Open VPN-protocol wat over het internet loopt is een UDP protocol.
Maar dat is geen (virtueel) "subnet" binnen je thuis netwerk.  Of zie ik iets over het hoofd in de afhandeling van het een en ander?

Verder lijkt het me wel degelijk passen binnen het topic, omdat jij andere instellingen gebruikt (UDP versus TCP/UDP), waardoor de resultaten kennelijk dan net anders uitpakken?

[Birdy]

Omdat ik die Firewall regels zelf heb aangemaakt, heb ik er die benaming aan gegeven.

Ah....vandaar VLAN (waarvan ik de betekenis wel wist)

Verder lijkt het me wel degelijk passen binnen het topic, omdat jij andere instellingen gebruikt (UDP versus TCP/UDP), waardoor de resultaten kennelijk dan net anders uitpakken?

Ok....nu TCP/UDP:



Blijf hits krijgen.
Wat zou ik meer moeten wijzigen dan ?

[Pippin]

Wat voor apparaat is 192.168.1.7?

Nu zijn de hits er weer want de blok regel (udp 1900) is ook weg in je laatste screenshot.

[Babylonia]

Dat is juist het vreemde.

@Birdy  heeft nu (als test) vergelijkbare instellingen gebruikt voor het virtuele subnet (TCP + UDP) als ikzelf zonder die blok regel (udp 1900).
Hij krijgt dan wel die hits, en ik niet?  Aanvankelijk had ik ze ook, maar kon mogelijk liggen aan verwarrende achterliggende instellingen van de VPN Client functie in de router die ik gebruik met connecties elders??

Dus er lijkt niet een consequente werking te zitten in de uitwerking van die hits m.b.t. die instellingen?
Wij (ik athans) probeer juist te achterhalen wat de logische werking is van het een en het ander.

Als vergelijk heb ik nu als test de regel met het virtuele VPN subnet nu ook gelijk gezet met de instelling van @Birdy - dus met alleen UDP.
Maar daarbij NIET de blokregel voor poort 1900 erbij gezet.  Dus feitelijk de situatie waarmee @Birdy de draad begon .

Krijg (na aanpassing VPN Client instellingen in de router) daarbij nog steeds GEEN hits bij die OpenVPN subnet regel.
Heb als test erna een VPN-verbinding opgezet via mijn Smartphone. Ook dan krijg ik in die specifieke regel geen hits.

Frappant is wel dat ik wel hits krijg voor de remote toegang "vanuit Nederland" wat ik als optie tevens heb ingeschakeld en erbij heb gezet in de Firewall. Die teller loopt alleen op als ik via VPN met een webbrowser (die flash / html5 ondersteunt zodat ik geen router app nodig heb) daadwerkelijk SRM aanroep en inlog.  Die teller loopt NIET op als ik via de DS File app mijn router benader. Dus echt alleen "remote" afhankelijk.

(Een deel van mijn Firewall regels waar het betrekking op heeft bij elkaar gezet).



Ook als ik vanuit mijn smartphone rechtstreeks inlog naar SRM (zonder gebruikmaking van OpenVPN), lopen die hits op van remote management.
Dus in die zin lijken die hit functionaliteiten wel te werken.



Omat de werking van het een en ander af lijkt te hangen van wat je wel of niet in Firewall regels hebt ingesteld, lijkt het dus per situatie verschillend te kunnen worden afgehandeld. Aangezien ik wel andere (extra) instellingen gebruik dan @Birdy vandaar misschien het verschil in uitwerking?

In de situatie van @Birdy zou ik die poort 1900 blokregel er dan ook beter weer tussen zetten.
Ten slotte heeft hij specifiek met die SSH benadering daarin de oorzaak kunnen vinden.
In dat geval wel alleen poort 1900 als UDP,  het virtuele VPN subnet zou ik laten staan op TCP + UDP.  (Maar dat is een persoonlijke keus).