Model toho Grandstream telefonu?

Několik ruznych, starsich i novych, celkem asi 5ks. gxp1620, gxp1625 a gxp1628 vsechny se chovaji stejne. Odezva na ping jen jednou, pak neodpovidaji. V lokalni siti odpovidaji. Jako by v nich byl nejaky firewall, ale neni. Jo a upgrade firmware jednoho grandstreamu jsem take zkousel. Posledni verze a beze zmeny.
Techto grandstreamu mame desitky a nikde zadny problem.

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 to čistý ipsec tunel. v /ip/firewall/service port je sip vypnutý. Connection tracking je default a stejný jako na jiných pobočkách. S packet snifferem jsem ještě nedělal, budu na to muset kouknout.
Ještě jeden rozdíl je na této pobočce a to poskytovatel internetu, ale když to jde v ipsec tunelu, tak by to nemělo mít vůbec vliv předpokládám, když ostatní zařízení fungují na 100%.
To nastavení Grandstreamu vypadalo slibně, ale všechny nastavení kde se objevuje nějaký server grandstreamu jsem smazal a stejně to nejde.
Do internetu telefony vidí. Teď jsem zkusil pronatovat port z veřejky na sip server a zaregistrovat telefon skrz internet mimo VPN a to funguje, ale nechci mít SIP server v internetu. Také chci mít na telefony přístup skrz VPN.
Další nápady uvítám, jdu zkoušet ten sniffer

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

Ano lokální síť bez problémů. Pokud vytočím vytáčenou VPN na pobočku tak tudy také ping funguje.
Zde packet sniffer:

a tohle je na funkční telefon Planet:

Chybí tam ty řádky 5 a 6 u první odezvy.
Takže u nefunkčního telefonu se po první odezvě vrátí na telefon něco z RB1100(GW-192.168.101.1) proč? co to je? A jakto že se tohle děje jen u Grandstream telefonů a vše ostatní funguje?

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.

po power off/on telefonu zase půjde jeden packet, asi i spojení s ústřednou, protože občas se zaregistroval, ale volat nešlo, pravděpodobně projde jeden packet každého typu...
jak se podívám na obsah ICMP zprávy?
Je to celé divné protože ostatní telefony i zařízení normálně fungují skrz tu VPN

Nemůže být problémem MTU přes tu VPN? Nějaké zařízení projde, jiné ne?

MTU by problém být něměl, projevilo by se to na více službách, vše tam funguje bez problémů. Obě strany WAN mají MTU 1500. Ping na jiné zařízení projde malý i velký, i velký fragmentovaný. S DF projde max 1438, stejně jako jiná pobočka.

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.

stáhnul jsem wireshark a exportoval jsem si soubor. ta neočekávaná odezva od RB1100 po které už grandstream neodpovídá je redirect, co s tím?

Kde hledat dál?

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.

Děkuji za vaši trpělivost a rady.
/ip/settings:

default a stejně na všech pobočkách.
redirect je opravdu posílán jen grandstreamům. Zkoušel jsem sniffovat ten funkční Planet a ten redirect nedostal a tudíž funguje.
V /ip/route mám opravdu že 172.16.0.0/16 je na bridge-local, ale to mám na všech pobočkách, bez toho mi komunikace skrz ipsec nefunguje, ani když jsem zkusil vytvořit ten bridge-dira a smrovat to tam
Jak tedy správně routovat do ipsecu?
Když vypnu to send redirects, rozbiju něco jiného?

    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.

      Vypnul jsem send redirects a pro jistotu i secure redirects.(je k tomu potřeba reboot mikrotiku?) reboot telefonu a redirecty stále chodí...
      Bridge má nastavenou pevně Admin MAC address a na tomto bridgi je ta 192.168.101.1
      firewall routing povolen má oběmi směry jak ve filter, tak accept pravidlo v NAT záložce před maškarádou
      HW offloading jsem už také zkoušel vypínat. WAN je na portu 1, bridge jsou porty 1-5, aktivní jen jeden, za ním je switch HP.
      bridge je proxy-arp, ale to jsem také zkoušel vypínat.

      📡 Telekomunikace.cz