Today I am working on this issue and I would love your ideas.
There is a network with something like this
LAN 1 -- WAN CHANNEL--- LAN 2
The LAN 1 have two segments.
When I make a ping from LAN 1 segment 1 it works like a charm.
When I make a ping from LAN 1 segment 2 I have no ping, but after about 30 seconds of continues ping (ping -t) it start to work perfect. After some time of no activity with the destination host the issue happens again.
Tracing the route packets stops in the last router before the target. This is the first router in LAN 2 after the WAN channel.
In the next screenshot you can see thie issue, the first ping is before a continuos ping and the second one is while continous ping is running.
Thank you in advance
This can sometimes happen if a ping is crossing a network security device. In some cases, pinging by DNS name will trigger a URL filter in a UTM device. It may take several seconds to get a positive or negative response which cases a delay in ICMP. Once a positive response has been received, then future pings are allowed until a timer expires. That logic depends on how the security policy is set up.
So why would segment 2 be affected and not segment 1? In this theory, it's a rather simple matter of different policies for different segments. Perhaps there is an intentional difference in some kind of security context that is having unintended consequences.
Troubleshooting steps:
Does your WAN channel include a transparent bridge? I've seen this issue when a transparent bridge is unable to pass ARPs. Check out "learning" mode if this is the case. In my case, I was establishing a pfsense transparent bridge connecting servers with rest of the office LAN using pfsense and had to switch learning mode from being on the outside to the server side (or vice versa - hazy memory).
SPANNING-TREE?
If possible check Spanning-tree, if a device in your network is doing spanning-tree it can lead to the fact that the port(s) are put into blocking state. Your switch or router has to follow all the steps: blocking, listening, learning state before it will forward traffic. This is indeed about 30 seconds.
Disable Spanning-tree or configure Portfast on the needed ports can solve the problem.