Synology-Forum.nl
Synology Router => Synology Router => Topic gestart door: Birdy op 01 maart 2018, 11:48:13
-
Het valt mij nu pas op, dat ik in de Firewall zie:
[attachimg=1]
(PS: Alle waarden staan nu laag, na een reboot.)
De OpenVPN Hit, wordt steeds opgehoogd met 2 Hits echter, ik begrijp niet waarom.
Die waarde zou, naar mijn mening, pas kunnen ophogen als er een OpenVPN Client een verbinding heeft gemaakt, toch ?
Is er geen verbinding, dan is er immers ook geen verkeer over een Virtuele IP addres.
Ben overigens de enige die gebruik maakt van OpenVPN.
-
Hier hetzelfde. Dacht eerst iets van een mogelijke "keep alive" controle?? Maar er zit geen vast ritme in.
Andere VPN-server protocollen waar ik tevens ook gebruik van maak, geven geen hits (als er geen verbinding is met het netwerk).
Zou eigenlijk meer consequent moeten zijn, maar is misschien afhankelijk van het OpenVPN protocol zelf??
Overigens zijn er geen hits bij de Firewall regels van de VPN als service als er geen VPN actief is.
Die verschijnen pas als er daadwerkelijk een VPN-verbinding wordt opgezet. Één actieve VPN connectie = 1 hit.
Gaat de verbinding even weg (getest met smartphone, en die even in standby laten vallen), en wordt die weer actief komt er een hit bij.
Zou er misschien een Support ticket aan kunnen wagen.
Overigens kun je de telling van hits verversen door de firewall even een vinkje weg te halen, saven, en weer terug en saven.
Is minder omslachtig dan een reboot.
-
Ah, dus ben niet de enige. 8)
Overigens zijn er geen hits bij de Firewall regels van de VPN als service als er geen VPN actief is.
Die verschijnen pas als er daadwerkelijk een VPN-verbinding wordt opgezet. Één actieve VPN connectie = 1 hit.
Klopt als een bus.
Zou er misschien een Support ticket aan kunnen wagen.
Zal dat eens doen.
Overigens kun je de telling van hits verversen door de firewall even een vinkje weg te halen, saven, en weer terug en saven.
Is minder omslachtig dan een reboot.
Moest toch even rebooten maar, bedankt voor de tip. ;)
-
Mogelijk kan tcpdump er meer licht op werpen.
Zonder verbonden client(s):
tcpdump -n -i tun0Waarbij tun0 de VPN interface is, te vinden met
ip addr show
-
SynologyRouter> tcpdump -n -i tun0
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on tun0, link-type RAW (Raw IP), capture size 262144 bytes
15:51:13.881640 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:51:13.881702 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:51:43.944851 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:51:43.944914 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:52:14.001627 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:52:14.001721 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:52:44.088268 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:52:44.088393 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:53:14.174815 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:53:14.174909 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:53:44.239057 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:53:44.239151 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:54:14.311984 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:54:14.312109 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:54:44.372634 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
15:54:44.372759 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
Elke 30 sec. gebeurt er dus 2x "iets". ;D
-
netstat -atun?
-
SynologyRouter> netstat -atun
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:5440 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:161 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:1195 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:139 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:7787 0.0.0.0:* LISTEN
tcp 0 0 192.168.2.1:5010 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.1:5010 0.0.0.0:* LISTEN
tcp 0 0 192.168.2.1:5011 0.0.0.0:* LISTEN
tcp 0 0 192.168.1.1:5011 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:53 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:445 0.0.0.0:* LISTEN
tcp 0 720 192.168.1.1:22 192.168.1.130:65303 ESTABLISHED
tcp 0 0 <EXT.IP>:52556 50.112.201.23:443 ESTABLISHED
tcp 0 0 <EXT.IP>:52562 50.112.201.23:443 ESTABLISHED
tcp 0 0 <EXT.IP>:52490 50.112.201.23:443 ESTABLISHED
tcp 32 0 <EXT.IP>:42853 34.213.59.192:443 CLOSE_WAIT
tcp 0 0 ::%1:5440 :::* LISTEN
tcp 0 0 ::%2:8000 :::* LISTEN
tcp 0 0 ::%3:8001 :::* LISTEN
tcp 0 0 ::%4:161 :::* LISTEN
tcp 0 0 ::%5:515 :::* LISTEN
tcp 0 0 ::%6:139 :::* LISTEN
tcp 0 0 ::%7:80 :::* LISTEN
tcp 0 0 ::%8:53 :::* LISTEN
tcp 0 0 ::%9:22 :::* LISTEN
tcp 0 0 ::%10:443 :::* LISTEN
tcp 0 0 ::%11:445 :::* LISTEN
tcp 0 0 ::ffff:192.168.1.1%12:8000 ::ffff:192.168.1.130:65299 TIME_WAIT
tcp 0 0 ::ffff:192.168.1.1%13:8000 ::ffff:192.168.1.130:65300 TIME_WAIT
tcp 0 0 ::ffff:192.168.1.1%14:8000 ::ffff:192.168.1.130:65286 TIME_WAIT
tcp 0 0 ::ffff:192.168.1.1%15:8000 ::ffff:192.168.1.130:65302 TIME_WAIT
tcp 0 0 ::ffff:192.168.1.1%16:8000 ::ffff:192.168.1.130:65323 ESTABLISHED
tcp 0 0 ::ffff:192.168.1.1%17:8000 ::ffff:192.168.1.130:65245 ESTABLISHED
tcp 0 0 ::ffff:192.168.1.1%18:8000 ::ffff:192.168.1.130:65311 TIME_WAIT
tcp 0 0 ::ffff:192.168.1.1%19:8000 ::ffff:192.168.1.130:65297 TIME_WAIT
tcp 0 0 ::ffff:192.168.1.1%20:8000 ::ffff:192.168.1.130:65322 TIME_WAIT
tcp 0 0 ::ffff:192.168.1.1%21:8000 ::ffff:192.168.1.130:65310 TIME_WAIT
tcp 0 0 ::ffff:192.168.1.1%22:8000 ::ffff:192.168.1.130:65289 TIME_WAIT
tcp 0 0 ::ffff:192.168.1.1%23:8000 ::ffff:192.168.1.130:65314 TIME_WAIT
udp 0 0 0.0.0.0:9997 0.0.0.0:*
udp 0 0 0.0.0.0:11022 0.0.0.0:*
udp 0 0 0.0.0.0:9998 0.0.0.0:*
udp 0 0 0.0.0.0:9999 0.0.0.0:*
udp 0 0 0.0.0.0:53 0.0.0.0:*
udp 0 0 0.0.0.0:5440 0.0.0.0:*
udp 0 0 0.0.0.0:67 0.0.0.0:*
udp 113088 0 0.0.0.0:68 0.0.0.0:*
udp 0 0 0.0.0.0:53320 0.0.0.0:*
udp 0 0 0.0.0.0:1900 0.0.0.0:*
udp 0 0 10.0.0.1:1900 0.0.0.0:*
udp 0 0 10.8.0.1:1900 0.0.0.0:*
udp 0 0 192.168.1.1:1900 0.0.0.0:*
udp 0 0 192.168.2.1:1900 0.0.0.0:*
udp 0 0 <EXT.IP>:1900 0.0.0.0:*
udp 0 0 10.8.0.1:123 0.0.0.0:*
udp 0 0 192.168.1.1:123 0.0.0.0:*
udp 0 0 <EXT.IP>:123 0.0.0.0:*
udp 0 0 127.0.0.1:123 0.0.0.0:*
udp 0 0 0.0.0.0:123 0.0.0.0:*
udp 0 0 <EXT.IP>255:137 0.0.0.0:*
udp 0 0 <EXT.IP>:137 0.0.0.0:*
udp 0 0 192.168.1.255:137 0.0.0.0:*
udp 0 0 192.168.1.1:137 0.0.0.0:*
udp 0 0 0.0.0.0:137 0.0.0.0:*
udp 0 0 <EXT.IP>.255:138 0.0.0.0:*
udp 0 0 <EXT.IP>:138 0.0.0.0:*
udp 0 0 192.168.1.255:138 0.0.0.0:*
udp 0 0 192.168.1.1:138 0.0.0.0:*
udp 0 0 0.0.0.0:138 0.0.0.0:*
udp 0 0 0.0.0.0:161 0.0.0.0:*
udp 0 0 0.0.0.0:47790 0.0.0.0:*
udp 0 0 127.0.0.1:31689 0.0.0.0:*
udp 0 0 127.0.0.1:31690 0.0.0.0:*
udp 0 0 0.0.0.0:5353 0.0.0.0:*
udp 0 0 ::%1:53 :::*
udp 0 0 ::%2:5440 :::*
udp 0 0 fe80::211:32ff:fe76:4c4c%eth0:123 :::*
udp 0 0 fe80::211:32ff:fe76:4c4f%eth1:123 :::*
udp 0 0 fe80::211:32ff:fe76:4c4e%eth2:123 :::*
udp 0 0 fe80::211:32ff:fe76:4c4d%qca-nss-dev0:123 :::*
udp 0 0 fe80::211:32ff:fe76:4c4c%qca-nss-dev1:123 :::*
udp 0 0 fe80::211:32ff:fe76:4c4b%qca-nss-dev2:123 :::*
udp 0 0 ::1%9:123 :::*
udp 0 0 ::%10:123 :::*
udp 0 0 ::%11:161 :::*
udp 0 0 ::%12:1194 :::*
udp 0 0 ::1%13:31689 :::*
udp 0 0 ::1%14:31690 :::*
SynologyRouter>
-
udp 0 0 0.0.0.0:1900 0.0.0.0:*
udp 0 0 10.0.0.1:1900 0.0.0.0:*
udp 0 0 10.8.0.1:1900 0.0.0.0:*
udp 0 0 192.168.1.1:1900 0.0.0.0:*
udp 0 0 192.168.2.1:1900 0.0.0.0:*
udp 0 0 <EXT.IP>:1900 0.0.0.0:*
UPnP aan staan?
-
Nope en nooit aangehad (natuurlijk) ;)
Wat je laat zien, is dat UPnP gericht dan ?
-
Yup,
https://wiki.wireshark.org/SSDP
https://en.wikipedia.org/wiki/Simple_Service_Discovery_Protocol
Doelpoort 1900 blokkeren op alle interfaces en geen hits meer?
Deze info bij het ticket doen en wachten wat ze er van zeggen.
-
Poort 1900 is "media-server" gerelateerd.
Die staat bij mij in ieder geval wel als package op de Synology router geïnstalleerd (en op de NAS). Zie Synology poort-lijstje < HIER > (https://www.synology.com/nl-nl/knowledgebase/DSM/tutorial/General/What_network_ports_are_used_by_Synology_services).
-
Je zou ook nog
tcpdump -n -i any port 1900kunnen doen.
Dat laat dan poort 1900 van alle interfaces zien.
-
Wordt interessant ;D
SynologyRouter> tcpdump port 1900
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:45:34.028696 IP xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: UDP, length 1024
16:45:34.028759 IP xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: UDP, length 1024
16:46:04.099717 IP xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: UDP, length 1024
16:46:04.099811 IP xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: UDP, length 1024
16:46:34.151089 IP xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: UDP, length 1024
16:46:34.151151 IP xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: UDP, length 1024
^C
6 packets captured
9 packets received by filter
0 packets dropped by kernel
SynologyRouter>
-
-v :
SynologyRouter>
SynologyRouter> tcpdump -v port 1900
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:48:04.373117 IP (tos 0x0, ttl 1, id 14910, offset 0, flags [DF], proto UDP (17), length 1052)
xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: UDP, length 1024
16:48:04.373211 IP (tos 0x0, ttl 1, id 15205, offset 0, flags [DF], proto UDP (17), length 1052)
xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: UDP, length 1024
16:48:34.424739 IP (tos 0x0, ttl 1, id 16994, offset 0, flags [DF], proto UDP (17), length 1052)
xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: UDP, length 1024
16:48:34.424801 IP (tos 0x0, ttl 1, id 16995, offset 0, flags [DF], proto UDP (17), length 1052)
xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: UDP, length 1024
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
SynologyRouter>
-vv :
SynologyRouter> tcpdump -vv port 1900
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
16:50:04.619148 IP (tos 0x0, ttl 1, id 20722, offset 0, flags [DF], proto UDP (17), length 1052)
xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: [bad udp cksum 0xf1e8 -> 0xab1c!] UDP, length 1024
16:50:04.619211 IP (tos 0x0, ttl 1, id 13292, offset 0, flags [DF], proto UDP (17), length 1052)
xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: [bad udp cksum 0xf1e8 -> 0x33c8!] UDP, length 1024
16:50:34.673049 IP (tos 0x0, ttl 1, id 3359, offset 0, flags [DF], proto UDP (17), length 1052)
xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: [bad udp cksum 0xf1e8 -> 0xab1c!] UDP, length 1024
16:50:34.673112 IP (tos 0x0, ttl 1, id 62998, offset 0, flags [DF], proto UDP (17), length 1052)
xxxxx.ftth.telfortglasvezel.nl.ssdp > 239.255.255.250.ssdp: [bad udp cksum 0xf1e8 -> 0x33c8!] UDP, length 1024
^C
4 packets captured
4 packets received by filter
0 packets dropped by kernel
SynologyRouter>
-
Poort 1900 is "media-server" gerelateerd.
Die staat bij mij in ieder geval wel als package op de Synology router geïnstalleerd (en op de NAS). Zie Synology poort-lijstje < HIER > (https://www.synology.com/nl-nl/knowledgebase/DSM/tutorial/General/What_network_ports_are_used_by_Synology_services).
Media Server is bij mij niet geïnstalleerd.
[attach=1]
-
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 (https://www.synology-forum.nl/synology-router/firewall-openvpn-hits-blijft-oplopen-zonder-een-verbinding-te-hebben/msg245694/#msg245694) @MMD ook bij mij die nummertjes maar even vervangen door xxxx en yyyy.
-
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 :lol:
[attachimg=1]
Blokkeren werkt in ieder geval 8)
( SSH is weer uit ;D )
-
Die meldingen zeggen mij ook niets. Ik wachtte eigenlijk een beetje af met wat jij vond. :geek:
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").
-
xxxxx.ftth.telfortglasvezel.nlis je externe adres, ff weghalen uit de berichten.
Beter dan
tcpdump port 1900is
tcpdump -n -i any port 1900Foutje van mij, het is mogelijk dat andere apparaten in je netwerk SSDP doen.
-
Doelpoort 1900 blokkeren op alle interfaces en geen hits meer?
Nog geprobeerd?
-
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).
[attach=1]
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.
-
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.
-
xxxxx.ftth.telfortglasvezel.nlis je externe adres, ff weghalen uit de berichten.
Beter dan
tcpdump port 1900is
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 !
-
tcpdump -n -i any port 1900
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
[attachimg=1]
-
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> (https://forum.synology.com/enu/viewtopic.php?f=265&t=121572&start=15#p520042)).
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).
[attach=1]
[attach=2]
-
@Babylonia
Bovenstaande, voegt, volgens mij, niet zoveel toe aan mijn Topic, of ik zie het niet helemaal. ;)
Echter, wat ik wel zie bij jou:
[attachimg=1]
En zie bij mij (waar dit Topic overgaat):
[attachimg=2]
Jij hebt geen hits, komt dat soms omdat jij VLAN hebt/gebruikt ?
-
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?
-
Omdat ik die Firewall regels zelf heb aangemaakt, heb ik er die benaming aan gegeven. ;)
Ah....vandaar VLAN (waarvan ik de betekenis wel wist) :lol:
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:
[attach=1]
Blijf hits krijgen.
Wat zou ik meer moeten wijzigen dan ?
-
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.
-
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 . (https://www.synology-forum.nl/synology-router/firewall-openvpn-hits-blijft-oplopen-zonder-een-verbinding-te-hebben/)
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 (https://play.google.com/store/apps/details?id=com.synology.DSfile&hl=nl)mijn router benader. Dus echt alleen "remote" afhankelijk.
(Een deel van mijn Firewall regels waar het betrekking op heeft bij elkaar gezet).
[attach=1]
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.
[attach=2]
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 (https://www.synology-forum.nl/synology-router/firewall-openvpn-hits-blijft-oplopen-zonder-een-verbinding-te-hebben/msg245725/#msg245725) 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).
-
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.
192.168.1.7 is mijn PC.
En ja, ik had die blok regel (udp 1900) weer weggehaald, omdat het maar een test was. ;D
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).
Done, ziet er nu zo uit:
[attachimg=1]
Dus samenvattend, mijn PC wil kennelijk iets via UDP 1900 over 10.8.0.* ?
Zou echt niet weten wat.
-
Bij elkaar is er nu een redelijk overzicht, ook voor andere gebruikers als ze er vragen over hebben, in de functionaliteit van die hits. ;)
-
Dat wel ;)
Echter, het blijft toch vreemd in mijn ogen m.n., dat mij PC kennelijk iets doet met UDP 1900 over 10.8.0.* ;D
@MMD Ik heb op m'n PC gekeken met netstat echter, ik kom poort 1900 en IP 10.8.0.* helemaal niet tegen.
Heb jij soms nog een hint ?
-
ik kom poort 1900 en IP 10.8.0.* helemaal niet tegenDe bronpoort is willekeurig, de doelpoort is 1900.
De normale regel is dat een bronpoort willekeurig is en een doelpoort wordt toegewezen.
Dat zie je ook terug in de dump, bronpoort 60531, doelpoort 1900
IP 192.168.1.7.60531 > 239.255.255.250.1900: UDP, length 97
Het is verder niet zo`n probleem maar je zou SSDP Discovery in Services (Start, services.msc, enter onder Windows) uit kunnen zetten.
-
Het is verder niet zo`n probleem maar je zou SSDP Discovery in Services (Start, services.msc, enter onder Windows) uit kunnen zetten.
Done + reboot voor de zekerheid:
[attachimg=1]
En die udp block even uit, echter:
[attachimg=2]
Nu zie ik dat m'n interne netwerk geen hits krijgt.
Ik zet die SSDP maar weer aan (standaard) en block 1900 want in feite, moet ik me er niet verder druk over te maken, begrijp ik. ;D
O ja, nog ff " tcpdump -n -i any port 1900" gedaan:
(sniped)
13:42:00.701628 IP 10.8.0.1.1900 > 239.255.255.250.1900: UDP, length 1024
13:42:11.621185 IP 192.168.1.7.61431 > 239.255.255.250.1900: UDP, length 174
13:42:16.296237 IP 192.168.1.15.4996 > 239.255.255.250.1900: UDP, length 140
7 = PC (met SSDP uit)
15 = Denon receiver
-
Ik hou het maar zo:
[attachimg=1]