Po pádu VPN ping nejede, ostatní ano?

[czatlantis]

Zdravím,
mám tu takovou zajímavou věc u které bych rád pochopil, proč se to takhle chová.

Mám dvě sítě propojený jednoduchým PPTP tunelem. Ze sítě A se dostanu na jakejkoliv PC v síti B a naopak. Tuhle jsem pingal vzdálenej PC a něco tam kopíroval a spadlo mi spojení. To se pak hned obnovilo, ale pingy píšou "vypršel časový limit žádosti". Tracert ukáže jen můj router a dál nic. Co nechápu, tak když se třeba pokusím dostat na sdílený disky toho PC, tak to normálně jde - takže spojení je, ale proč proboha neprojde ten ping? Na jiný PC/router na té vzdálené síti pingat jde. A taky jde pingat na ten konkrétní vzdálenej PC z jiných lokálních strojů nebo routeru - co kde zůstane v tom PC (win7) viset, že to směruje ty pingy pro tu konkrétní IP někam do háje? Když na nějakou dobu zavřu pingání a pak to zase spustím, tak to začne chodit.

[sub_zero]

Přesně tohle se nám děje taky. A ne jen mezi Mikrotikama, ale i mezi Ciscem a Fortigatem. Vypadá to tak, jako by se ICMP požadavky nesměrovaly do toho tunelu, ale lezly někam do WANu. Ale jak říkáš, normální provoz jde.
Taky jsem z toho na větvi...

[Majklik]

Protože následek provedeného NATu po pádu VPNka, connection tracking a nevhodně nastavené routy?
Pokud používám v mé vnitřní síti a v těch VPNkách bloky z 192.168...., tak bych na každém routeru očekával i toto:
/ip route add distance=250 dst-address=192.168.0.0/16 type=unreachable
Třeba to pak tuto podivnost přestane dělat. A podobně znějicích rout na slušně nastaveném routeru by mělo být mnohem víc (pro inspiraci viz RFC6890).

EDIT: Takže to vypadá, že i ten Fortigate má stejný problém, kdy po pádu tunelu začne původně tunelovaná spojení posílat přes WAN ven a zprzní je NAT, protože s ena ně uplantí defualt routa. Takže po obnově tunelu už neprojdou... Opět řeší blokační routa, co nedovolí útěk přes WAN při nejedoucím tunelu. Takže v nářečí Fortigate:
config router static
edit 123
set blackhole enable
set dst 192.168.0.0/16
set priority 250
next
end