classic.ISPforum.cz

pc - 10.10.10.10/24
eth1 - 10.10.10.1/24
fw - action=accept chain=forward out-interface=WIFI src-address=10.10.10.0/24
fw - action=drop chain=forward out-interface=WIFI
masquerade
wifi - 192.168.100.200/24
net...

proste klasicke zapojeni u klienta doma, po nahodnych casech (hodina - den) prestane klientovi fungovat internet. Do MK se pripojim, pingnu si do netu OK, pingnu si do vnitrni site OK, ale z vnitrni site to ven neprojde. Po restartu to zase chvili bezi.
Tak nejak me dosly napady co by mohlo zapricinit takove chovani. Jedno zarizeni uz jsem vymenil a zatim bezi, tak jsem to neresil, ale ted mam dalsi 2
RB411 a RB711 ve v5.21 , doted jsem s ni nemel problemy, tak doufam, ze to bude necim jinym

tak se k tomu pridala dalsi RB411 v3.20

Neběží ping z vnitrní sítě na veřejnou IP ( třeba 8.8.8., nebo nefunguje google.com? Mohl by to být problém s dns. Těch tu poslední dobou bylo dost.

Není problém v Max UDP Packet Size?

ping na 8.8.8.8 i na google.com bezi v poho, DNS to neni
jedna jednotka je klasicke CPE, tzn. 10...../24 nat 192... ale druha i v ramci bridge kde klient sdili stejny rozsah jako AP bez NATu
co jsem vysledoval, tak v Connections je videt provoz z vnitrni site 10..../24 ven na ruzne IP, kdy zadam cokoliv, tak src=10.10.10.2 na dst=12.34.56.78 ALE ani jedna connection neni naopak, tzn. ze by src byl verejny na dst vnitrni. Takze spojeni ven se otevre, ale nic se nevrati zpet.
timpadem ping z PC na cokoli = timeout, ale ping z MK projde bez problemu
Jeden z klientu tvrdi, ze mu staci vytahnout kabel z WAN routeru, vratit zpet a jede to zase chvili (tzn. bez rebootu)... u jine jednotky je treba rebootnout jak antenu (RB) tak router, pak to zase chvili jede, kdyz se rebootne jen RB nebo jen router, tak to nepomaha.

Konexe je jenom jedna ... není důvod, abys ji viděl dvakrát. src je to, kde vznikl první paket. Spíš to sleduj dle příznaků. Nebo torchem.

Jenom nechápu:
v jedné větě "ping na 8.8.8.8 i na google.com bezi v poho" a ve druhé "timpadem ping z PC na cokoli = timeout". Trochu si protiřečíš.

Klidně by to ovšem mohlo být omezením počtu konexí. Běžně se omezuje TCP a UDP, ale na ostatní protokoly se kašle (pokud to vůbec MK umí - UDP také dlouho neuměl). Takže ping jde, ale zbytek se někde zařízne. Dle tvého popisu bych si tipnul, že u poskytovatele.

A taková konexe, to je mrcha ... timeout je 1 den! Ve starších MK dokonce 5 dnů. Takže pokud si to ten někdo nezmění, jsi po překročení docela v loji. Nějakým rebootem totiž ty konexe neuzavřeš a visí tam do alelůja.

spatne jsem to napsal, ping z MK (anteny) na cokoli projde, dovnitr i ven, ale z PC (z vnitrni site) ven neprojde, stejne tak, mam port forward na vnitrni router a pres verejku se na nej nedostanu

poskytovatel jsem ja, takze vim, ze pocet connections neomezuji ostatni klienti na stejnem AP slapou v pohode

Možná jsem to blbě pochopil, ale není problém v tom, že právě vidíš tu komunikaci z ip 10.../24 ?
Pokud tam je nat, mělo by to přece být z 192... Takže vlastně ten nat přestane fungovat a odpověď se nemá kam vrátit?

nat funguje,
src je 10... dst je internet
src je internet, dst je 192...
z internetu se normalne pripojim na RB, ale port forward do vnitrni (10...) uz neprojde

U nás som sa stretol s tým že zákazník zavolá, že mu nejde net. Bez problémov sa pripojím na jeho zariadenie, ale on sa na net nedostane. Ostatný zákazníci na tom AP idú bez problémov. Potom vypnem a zapnem vo firewall/filter posledné drop pravidlo na AP a zase všetko pekne beží.
Tento problém nastáva náhodne, ale primárne keď zákazník pozerá nejake streamy z netu (nie youtube) alebo som zaregistroval, že zákazníkovi to spravilo pri aktualizácii wot, wop, keď mal zapnutú v klientovy podporu torenta. ALE NIE JE PLNÁ ROUTE CACHE.