Problém VPN na RB1100AHx2 vs telefon Grandstream

Model toho Grandstream telefonu?

Je to čistý IPsec tunel nebo něco stylu GRE obalený IPsec transportem?
Že ti nejde ten ping, to je divný, kdyby ti nešel samotný VoIP (chápu, že telefon se registruje skrz VPN na ústřednu v centrále a nejde přes internet), tak bych šel na té RB1100 prvně hledat, co je nastaveno pod /ip/firewall/service port+
tracking, jak moc se to liší od funkčních poboček. Mohlo by ti to rozbít pokud si telefon přes stun něco najde a bude dle toho prznit VoIP hlavičky dopředu, podobně by ti to mohl prznit SIP helper v tom RBčku.
IMHO bych si pustil ping z centrály a paket snifferem se podíval, zda ti na té pobočce chodí správně pakety do lan s tím pingem a co případně chodí v odpovědi a takhle prvně najít, kde se to ztrácí.

No my jednou řešili u Grandstream telefonů, že nefungovali kvůli tomu, že se připojovali na nějaký Grandstream server, který byl v tu dobu nefunkční. Nefungovalo volání a asi ani ping, ani web interface. Ta služba se musela přes telefon vypnout a potom to šlapalo. Bohužel si nevzpomenu, co a jak jsme udělali. Vidí ty telefony do internetu?

Ještě otázka, z lokální sítě se na ně dá pingnout?

Ano, ty řádky 5 a 6 v tom prvním je odezva toho RB1100, kdy samo vyrobil nějaký icmp jako reakci na tu první icmp echo odpověď od telefonu, který ti ještě dojde do cíle. Po tom icmp, po kterým ti telefon přestane odpovídat, jak kdyby RB poslal něco stylu, že ten cíl je nedostupný, redirect atd.
Můžeš zkusit power off/on telefonu, zda až se začne snažit spojovat na ústřednu, zda uvidíš také nějakou takovou icmp odezvu na jeho snahu. A pak se podívat, co to je vlastně za ICMP zprávu a co obsahuje. Dle toho pak můžeš špekulovat dál.

MTU problém na krátkém pingu by být neměl.
V tom paket snifferu můžeš paket rozkliknout a pak tam máš jeho obsah, pravda, pokud se ti nechce luštit hex dump ručně, tak si do /ip/firewall/raw dej pravidlo na output, ať loguje icmp pakety a uvidíš to "lidsky" v logu.

Nu, posílá to telefonu redirect, že ta IP 172.16.64.120 leží na stejné LAN (bridge-local), jak ten telefon, takže ji má kontaktovat přímo. Telefon to vyslyší a bude přes ARP hledat přímo cílovou IP a nenajde. A dokud ten naučený redirect v něm nevychcípá, tak je to z dálky dále nekontaktovatelné. Udivuje, proč ten redirect posílá jen telefonu a ne všem... Pokud by to posílal natvrdo všem (a ostatní fungovalo proto, že redirect ignorují), tak je to o:
Podívej se i na další pobočky, jak máš tne redirect povolen, je to v /ip/settings "send-redirects". Podívej se, co máš nastaveno kde v routách, bude pod /ip/route něco, co tu 172.16.xxx pošle d LAN. To tam máš kvůli IPsec, když lehne, aby pakety neutíkaly ze sítě? Normálně IPsec ignoruje routy, ale potřebuješ někam nasměrovat provoz, co pak skončí v IPsec, router si to musí někam úspěšně nasměrovat, když se mu to povede, tak IPsec to pak následně ukradne. Je vhodné i NAT řešit, aby se neuplatnil NAT na provoz, co jde do/z IPsec tunelu. A proti tomu redirectu jsem to dělával tak, že si udělám prázný bridge-dira a do něj nasměruji to, co má jít do IPsecu, to se routeru jeví, že má routovat z bridge-local do bridge-dira a nepošle tak redirect. IPsec, když jede, tak to ukradne routingu pod rukama.

chtelo by to videt aspon cast cfg. nemas tam neajky HW-offloading ktery dokazde prznit UDP?

jika Asi ten redirect klidně můžeš vypnout. Nemělo by to nic rozbít, pokud tma máš jen jeden router a vše na pobočce má jít přes něj. Minimálně ověříš, že problém je vázán komplet na toto. Někde bude nějaká bota, co způsobuje jeho generování.
Ten bridge musí mát manuálně MAC adresu i nějakou IP adresu a pak route na ni. A nezapomeŇ případně na firewall, ž emusí povolit routing tím směrem, pak by to mělo jet.

k3ny Tak záleží kde má LAN a WAN, pokud lan je někde na ether1-10 a wan ether11 a výše, tak by k HW ogloadingu nemělo dojít. A RB1100AHx2 ho stejně moc nedávala? A przní se mu evidentně i základní routing tím redirectem.