Having a little bit of an issue. Cisco got damaged and had to replace it with RB2011 laying around. My issue I’m having is that I have to connect to office network via L2TP.
My main internet WAN connection is via PPPoE. Up to the Mikrotik, everything works and I can ping local ranges at the office etc.
Issue I’m having is my client device such as my workstation and other client device cannot see these ranges or ping. See picture attached of what I mean.
Assistance will be appreciated.
The quality of an answer depends on the quality of the question. So to get any useful advice, post your configuration in text form, following the anonymisation hint in my automatic signature right below. Screenshots are useless for any analysis, and yours in particular just show that it doesn’t work, nothing else.
I’ve added the config. The 192.168.0.0/24 range randomly started working on client devices such as 192.168.0.102 in the office. The 192.168.80.0/24 ranges till not reachable by client devices. I’m using the default config and firewall of MT for now. Let me know what else you require.
It’s strange, as everything looks fine in your configuration. The routes are there, the masquerade rule is there (it could be more selective but it doesn’t cause any trouble as-is given the rest of the configuration). So try pinging something in the 192.168.80.0/24 range that you know to respond, from a client device in 192.168.10.0/24, and run /tool sniffer quick interface=l2tp-out1 ip-protocol=icmp ip-address=192.168.80.x
(change the x accordingly). What can you see?
There is one minor mistake, the own address of the Mikrotik, 192.168.10.1/24, should not be attached to ether2 but to bridge, but it doesn’t explain the issue. To fix that part, use /ip address set [find interface=ether2] interface=bridge
I fixed the “ether2” issue. Thank you for noticing. Yeah, I can ping the main router over in the one NDC on 80.1.
I can even open the NMS on 80.3 without an issue but cannot ping it. The 80 range is a VSAT 550ms+ range. Still don’t explain it.
The other ranges just started pinging and became accessible randomly without intervention half an hour after creating this post.
Sniffer also get response from 80.3
Think I’m getting high.
Do I read you right that the sniffer shows an ICMP response from the 80.3 but the client cannot see it? I.e. the response doesn’t make it through the Mikrotik to the client?
Yeah you did read that right. I know you don’t like screenshots, but see attached. To the right is the client pc that can’t ping it but can access the NMS. The screenshot also shows the response of the sniffer.
The sniffer says the response from the 80.3 arrives 40-60 ms after the request is sent in the opposite direction. But as you mention there’s a VSAT link in the path, 40-60 ms is mission impossible, so could it actually be 1040-1060 ms (i.e. response to request N arriving after request N+1)? In that case, pinging from the Windows with -w 1500 might give better results?
Everything works great now. However, did found something Saturday evening after a lot of reading that caused this “anomaly” even though I was a bit skeptical about it, it seem though that it was the route table cache in the background. Did test it yesterday quite a bit by disabling “route-cache” and all routes establish instantly but then losing the fast path functionality and when enabling it as it is on default, it “hangs” the route for a time again before responding. Can’t say for sure that this was the issue.
