Ahoj všem,

řeším problém po výměně routeru za nový Vodafone Ultra Hub 7. Na zařízeních připojených přes Wi-Fi (iPhone, Mac) mi přestal v lokální síti správně fungovat PLEX server běžící na Synology NAS. Aplikace PLEX vyhodnocuje Wi-Fi klienty jako „vzdálené / nepřímé spojení“ a vyžaduje předplatné za vzdálený přístup, případně se lokálně vůbec nespojí.

Srovnání starého a nového routeru:

• Původní router (Vodafone Station WiFi 6): PLEX server na Synology NAS (192.168.0.44). Všechna zařízení na kabelu i na Wi-Fi fungovala bez jediného problému v přímém lokálním režimu (šifrovaně přes HTTPS).

• Nový router (Ultra Hub 7): Ponechal jsem identický IP rozsah (192.168.0.x/24), masku, bránu (192.168.0.1) i statickou IP pro NAS (192.168.0.44). Zařízení na kabelu (PC, TV) fungují dál bezchybně. Problém se týká výhradně klientů na Wi-Fi.

Identifikace problému a co jsem ověřil:

1. Fyzická konektivita LAN–WLAN je v pořádku: Z Wi-Fi se na NAS bez problému dostanu – webové rozhraní Synology DSM ([http://192.168.0.44:5000](http://192.168.0.44:5000)) i síťové disky přes SMB reagují okamžitě.

2. Blokování DNS Rebindingu: PLEX pro přímé zabezpečené lokální spojení používá domény ve tvaru *.plex.direct, které překládají veřejný požadavek zpět na lokální IP (192.168.0.44). Ultra Hub 7 vystupuje pro klienty jako výchozí DNS server (192.168.0.1) a tyto DNS dotazy blokuje z důvodu ochrany proti DNS Rebind.

3. Nemožnost změny DNS v DHCP: V administraci Ultra Hubu 7 v sekci Nastavení sítě chybí možnost nastavit vlastní DNS servery pro DHCP (změnu na 1.1.1.1 nebo 8.8.8.8). Router natvrdo všem zařízením v síti podstrkuje jako DNS sám sebe.

Pokud na konkrétním zařízení na Wi-Fi přenastavím DNS ručně nebo v PLEXu vynuťte nezabezpečené nešifrované HTTP spojení na portu 32400, komunikace projde. Není to ale systémové řešení pro celou domácnost a všechna zařízení.

Moje dotazy na komunitu:

1. Existuje v administraci Ultra Hubu 7 možnost vypnout ochranu proti DNS Rebindingu nebo povolit výjimku pro doménu plex.direct?

2. Lze nějakým způsobem přinutit DHCP server v routeru, aby klientům distribuoval vlastní DNS servery namísto IP adresy routeru?

Předem díky za jakékoliv tipy a rady!

Hele tak nakonec vyřešeno způsobem, který se mi upřímně moc nelíbí, ale uvidíme.

V DSM


V Plex


A funguje i aplikaci například pro MacOS...

UPDATE:

Na iOS to ale zprovoznit nelze...

Hele jelikož mi Ultra HUB 7 neposkytne primární benefit a to WiFi7, protože to reálně neumí a ještě mi doma totálně rozbil "PLEX" ekosystém na lokální síti, bude možné si zažádat zpět o Vodafone Station WiFi 6 byť mám 2Gbit tarif?

Vlastně nevidím v tomto zařízení žádný benefit (ten 2Gbit na LAN nutně nepotrebuji). Neumí ani bridge a nechci další zařízení, co bude ročně žrát 200kWh+.

Zkus se u Vodafonu zeptat zda by ti ho nevyměnili za modem AVM Fritzbox, umí také 2 Gbit a má mnohem širší možnosti nastavení, naopak Ultra hub je na tomto docela bídně.

Návrat k Vodafone stationu by byl možný zřejmě jedině pokud bys přešel zpět na pomalejší tarif.

Hele upřímně? Zavolám na linku, jestli se s tímto dá v rámci HUB 7 něco dělat a pokud ne, tak raději původní router klidně na 2Gbit tarifu... Já bych to teoreticky klidně řešil tím workaroundem, kdyby alespoň ta "marketovaná" Wi-Fi 7 fungovala, ale vlastně to neumí nic jiného 2,5Gbit port vs Vodafone Station WIFI 6 a jen s tím mám větší problémy.

Četl jsem něco o Secure Net? Neví jestli to může být tím a jestli to lze nějak deaktivovat per user....

Zkusil bych na chvilku vypnout FW na tom routeru. Mně takto blokoval automatické občerstvování certifikátů na webech, které za ním provozuji na RPI.

Jako dočasně, jestli to bude fungovat, nebo napořád? Já nemám nikde další FW, který by mě chránil....

Tak jsem strávil skoro 60 minut na lince technické podpory. Ještě jednou bych chtěl moc poděkovat operátorovi, který mé dotazy ochotně tlumočil na vyšší level IT a aktivně se snažil vše prověřit a vyzkoušet. Nakonec se ale potvrdilo to, k čemu jsem dospěl sám – problém bude pravděpodobně ve firmwaru samotného Vodafone Ultra HUB 7.

Jsem zřejmě první, kdo tohle řeší. Důvody jsou nejspíš dva: Ultra HUB 7 zatím mezi lidmi moc rozšířený není a ti, co mají podobně specifické požadavky, většinou používají vlastní router za modemem a řeší si síť po svém.

Jelikož IT podpora tato fóra sleduje, budu sem průběžně psát výsledky dalších pokusů. Je ale dost možné, že se v dohledné době dočasně vrátím k Vodafone Station WiFi 6, kde s tím žádný problém nebyl.

Pokud by měl někdo další stejný problém, tak budu rád, když se podělí o svoje zkušenosti. Pokud nás bude hodně, tak se to třeba bude řešit v rámci FW update někdy v budoucnu.

Díky

před 19 hodinami, tomus napsal:

Zkus se u Vodafonu zeptat zda by ti ho nevyměnili za modem AVM Fritzbox, umí také 2 Gbit a má mnohem širší možnosti nastavení, naopak Ultra hub je na tomto docela bídně.

Návrat k Vodafone stationu by byl možný zřejmě jedině pokud bys přešel zpět na pomalejší tarif.

Jen ještě info - toto taky na zákaznické lince padlo, ale už jich asi moc nebude a není to pro mě "systémové" řešení.

BTW jsem se ptal, jestli je možné si sehnat vlastní zařízení a vlastně to možné je, jen je potřeba najít takové, které splňuje cca 9 stránkové požadavky a to se samotnému Vodafone povedlo vlastně právě jen s tím AVM Fritzbox, který fungoval jako přechodné řešení než byl ready Vodafone Ultra HUB 7.

Mám Fritzbox a Plex na Synology a všetko mi funguje úplne v pohode.

Technický report: Nežádoucí filtrace paketů na WLAN rozhraní (Vodafone Ultra Hub 7)

Základní shrnutí problému:

Po přechodu na 2Gbit tarif a výměně routeru za Vodafone Ultra Hub 7 dochází k systematickému blokování specifických TCP portů (konkrétně portu 32400) při vnitřním směrování provozu z bezdrátových klientů (WLAN) na kabelově připojený server (LAN). Komunikace LAN–LAN funguje bezchybně.

1. Topologie sítě a HW vybavení

• Router / Gateway: Vodafone Ultra Hub 7 (výchozí brána, DHCP a DNS server: 192.168.0.1).
  

• Server: Synology NAS DS124, připojený fyzicky přes 1Gbit ethernet port přímo do routeru.
  

  • Přiřazena statická lokální IP adresa: 192.168.0.44.
    

  • Běžící služby: DSM (port 5000), SMB (port 445), Plex Media Server (port 32400), lokální VPN server.
    

• Klienti: Apple Mac a iPhone, připojeni výhradně přes Wi-Fi (WLAN).
  

2. Detailní popis závady

Plex Media Server naslouchající na lokální adrese 192.168.0.44:32400 je z Wi-Fi klientů absolutně nedostupný. Prohlížeč i nativní aplikace hlásí timeout (spojení selhalo). Kvůli nedostupnosti přímého lokálního spojení se aplikace (např. iOS Plex App) pokouší o asymetrický obchvat přes internetové servery (Plex Relay), což vede ke stavu „Remote Connection“, degradaci kvality streamu a vynucování předplatného, ačkoliv se klient i server nacházejí ve stejné podsíti (192.168.0.0/24).

3. Provedená diagnostika a vyloučení chyb na straně uživatele

K izolování problému na stranu routeru byly provedeny následující testy:

A. Testy fyzické vrstvy a základní konektivity:

• NAS byl přepojen do jiného LAN portu (z portu 4 do portu 2) – bez změny.
  

• Standardní AP izolace (Client Isolation) byla vyloučena: Z Wi-Fi klientů lze NAS bez problému pingnout, funguje přístup do webové administrace (port 5000) i mapování síťových disků přes SMB (port 445).
  

• Byl proveden test klientského PC připojeného ethernetovým kabelem – připojení na port 32400 funguje okamžitě a bez problému.
  

• Závěr: Závada se projevuje výhradně při průchodu paketů mezi WLAN čipem a LAN switchem uvnitř routeru na nestandardních portech.
  

B. Testy na straně klienta (macOS / iOS):

• Vypnuto skrývání MAC adresy („Soukromá adresa Wi-Fi“) pro vyloučení chyb při IP bindingu.
  

• Vypnuto Apple Private Relay (Soukromý přenos) a „Omezit sledování IP adresy“, aby nedocházelo k maskování lokálních DNS požadavků a směrování přes Apple proxy.
  

• Proveden test přes mobilní data s aktivním VPN připojením do domácí sítě. Jakmile je vynecháno WLAN rozhraní routeru, Plex aplikace na iOS se okamžitě lokálně spojí se serverem.
  

C. Testy bezdrátové sítě routeru (Band Steering):

• Sloučená Wi-Fi síť (Smart Wi-Fi / Band Steering) byla manuálně rozdělena na samostatná 2.4 GHz a 5 GHz SSID.
  

• Při exkluzivním připojení klienta pouze na 2.4 GHz síť zůstává port 32400 nadále blokován.
  

D. Testy na straně serveru (Synology NAS):

• Kompletně deaktivován firewall v Synology DSM – bez změny.
  

• Zkontrolován Auto-Block list v Synology, žádná lokální IP adresa není blokována.
  

• Ověřeno naslouchání služby Plex na všech síťových rozhraních (rozhraní nastaveno na „Any“).
  

E. Vyloučení vlivu směrování (Port Forwarding / NAT) a potvrzení veřejné IP:

• Pravidlo Port Forwarding pro port 32400 (TCP) směrem na lokální IP 192.168.0.44 je na routeru nastaveno a plně aktivní.
  

• Vzdálený přístup z internetu (z WAN do LAN) funguje naprosto bezchybně. To je plně umožněno tím, že disponuji plnohodnotnou veřejnou IPv4 adresou a funkce Vzdálený přístup (Remote Access) je v Plex Media Serveru korektně aktivována.
  

• Při lokální komunikaci (z WLAN do LAN) ovšem provoz vůbec nedosáhne k NAT/Firewall vrstvě routeru. Komunikace probíhá výhradně na interním mostě (bridge) mezi Wi-Fi čipem a integrovaným LAN switchem.
  

• Závěr: Diagnostika potvrzuje, že k cílenému zahazování paketů dochází přímo na vnitřním WLAN–LAN mostě. Veřejná IP adresa a nastavení vzdáleného přístupu potvrzují správný chod serveru, zatímco uživatelská pravidla pro přesměrování portů na interní lokální blokaci logicky nemají žádný vliv.
  

F. Absolutní vyloučení chyb v síti klienta/serveru (Test přes lokální VPN tunel):

• Test: Na Wi-Fi klientovi bylo aktivováno připojení do VPN tunelu (OpenVPN), jehož server běží přímo na totožném NASu (192.168.0.44). Po připojení do VPN Plex z Wi-Fi okamžitě a plnohodnotně funguje.
  

• Vysvětlení: Tento jev 100% potvrzuje nežádoucí filtraci na routeru. VPN tunel zapouzdří (enkapsuluje) veškerou síťovou komunikaci (včetně požadavků na port 32400) do šifrovaného spojení pod standardním VPN portem. Firmware Ultra Hubu 7 na Wi-Fi rozhraní vidí pouze povolený zapouzdřený provoz, který na LAN propustí. Jakmile NAS tento paket přijme a lokálně dešifruje, požadavek na vnitřní port 32400 se bez problému zpracuje.
  

• Závěr: Router prokazatelně a cíleně provádí inspekci paketů a zahazuje specificky nezapouzdřený provoz na portu 32400 při přechodu z Wi-Fi na kabel.
  

4. „Ultimátní důkaz“ chybné inspekce paketů (Reverzní proxy test)

K finálnímu potvrzení, že router na Wi-Fi provádí nežádoucí L4/L7 filtraci, byl na Synology NAS spuštěn webový server Nginx (Reverse Proxy).

• Nastavení: Příchozí provoz na portu 8443 (HTTP) byl interně v NASu přesměrován na localhost:32400.
  

• Výsledek: Jakmile byl k přístupu z Wi-Fi klienta použit běžnější port 8443, router spojení propustil a webové rozhraní služby běžící na 32400 se okamžitě načetlo.
  

• Tento obchvat však nelze využívat trvale, jelikož mobilní operační systémy (iOS App Transport Security) z bezpečnostních důvodů blokují nešifrovaný HTTP provoz na nestandardních portech u aplikací, které nemají možnost akceptovat self-signed certifikát.
  

5. Závěr a požadavky na L2/L3 podporu

Na základě výše uvedené komplexní diagnostiky je zcela zřejmé, že NAS, klienti i lokální síťová logika fungují naprosto správně. Problém tkví v agresivním blokování nestandardních portů na Wi-Fi rozhraní (WLAN) firmwarem Vodafone Ultra Hub 7.

Hele kdybych si ten AVM Fritz!Box koupil sám za plnou cenu, což dle dnešního infa z linky by mělo být možné, ví někdo proces registrace v rámci Vodafone, DOCSIS 3.1 atp.?

Jelikož na lince se dostanu většinou na paní, co vůbec neví, co AVM Fritz!Box je :-(

UPDATE:
Tak prý to vyzkouší a kdyby ten FritzBox nebyl volný, tak mi budou volat. Alternativně si ho možná koupím sám za těch skoro 8k :D

PS.: Vím, dát si pozor na to, aby nebyl vázaný na nějakou předešlou smlouvu u Vodafone v DOCSIS

Edited August 10Aug 10 by royal198
dodatek

Co test tcpdumpem? Je mozne na synology spustit tcpdump a podivat se, jestli dorazi z wifi klientu SYN pakety na tento (blokovany) port? Pokud nedorazi, je to jasny a neodvratitelny dukaz, ze VF router filtruje provoz.