MK jede, ale traffic nepropusti

aliney

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

aliney

tak se k tomu pridala dalsi RB411 v3.20

kysa

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

goblajz

Není problém v Max UDP Packet Size?

aliney

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. :

ludvik

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.

aliney

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

kysa

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?

aliney

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

roberthalak

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.